Browsed by
标签:阿里云

这多年来我一直在钻研的技术

这多年来我一直在钻研的技术

閱讀本文約花費: 15 (分鐘)因为我是看到tinyfool 《那些年我赶过的时髦技术趋势》(微博原文链接已失效,现更改为Google搜索的内容),在赞叹的时候,也让我对我有好些回忆,所以想写一篇回忆贴,本来觉得回忆是件挺让人沮喪的事,因为是老了的表现,但我写着写着,就歪了楼。看来,我还不老,还在拼博。下面是很多我的唠叨,你喜欢就读读,不喜欢就TLDR – Too Long, Don’t Read! 自从98年毕业,到今天,参加工作有18个年头了,加上在大三的时候就为两个在外面接活的老师程序,到今天,写的程序被用到生产线也有18个年头了。 背景经历 要说明我技术上的“性取向”,还得我说说的我的一些背景和经历。 我这18年,大约分三个阶段: 1996年-2000年:入门乱来期,大三大四加在银行工作的两年。 用Powerbuilder/Delphi在WindowsNT/SQL Server上做了好多个MIS管理软件,有酒店的,有送水的,有OA的。  用Java的Applet做了一个Web的教学课件,用于在Win95/IE3.0中演示操作系统中的各种调度和算法的动画,得了个全国大学生挑战者杯的鼓励奖。  用Delphi的ISAPI技术以及PHP/ASP给一些公司和大学做过几个网站。 2000年-2010年:技术学习期,这十年,我主要的编程语言是C/C++。 前两年在银…

Read More Read More

为什么我不在微信公众号上写文章

为什么我不在微信公众号上写文章

閱讀本文約花費: 11 (分鐘)很多朋友问我为什么不在微信公众号上写文章。我都没有直接回答,老实说,我也是扭扭捏捏的,才去开了个个人的微信的公众号,而且还只是为了使用微服小程序,和文章的发布通知,我承认现在的阅读都在移动端,而且微信的公众号是国内移动端的文章流量及分享的入口,但是我还是更愿意使用blog这样的方式分享文章,最多也是在blog这边写好文章后,再去微信公众号那边通知一下。这个原因,不是因为我是一个老顽固,有习惯思维,而是,我不觉得微信公众号是一个好的信息传播和交流的平台。 我下面的言论仅仅代表我的个人观点,我不想强加给别人,我只是想说明一下为什么我不把我的blog迁移到微信公众号上。 首先,互联网是开放和共享的,不是封闭的。信息的传播更是需要开放的,大家可以看看互联网之子。 我希望我的文章能够被rss feed到各种阅读器中。 我希望我的文章能有更长的生命周期,长到十几年前的文章都会有人来读。 我希望我的文章可以被搜索引擎所检索到。 我希望我的文章能被别人整理,与其它人的文章放在一起互补并引用。 我希望我的文章能被修改,因为文章会有错误,也会需要时常更新。 然而,微信公众号都不能很好的支持。我希望我的文章能成为生态圈的里的一部份。所谓生态圈是相互融合,不是唯我独尊。这个和做开源软件的道理一样,开源软件不是把源代码开出来就好了,而是要去和已有的其它软件互相融合,互相兼容,…

Read More Read More

如何对 ElasticSearch 集群进行压力测试

如何对 ElasticSearch 集群进行压力测试

閱讀本文約花費: 14 (分鐘)当 ElasticSearch 的业务量足够大,比如每天都会产生数百 GB 数据的时候,你就会自然而然的需要一个性能更强的 ElasticSearch 集群。特别是当你使用的场景是一些典型的大量数据进入的场景,比如网站日志、用户行为记录、大型电商网站的站内搜索时,一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下,如何找到一组合适的 ElasticSearch 集群?如何评估 ElasticSearch 集群的性能,就成为了一个十分重要的因素。 用什么 ElasticSearch 进行压力测试? 对于 ElasticSearch 性能测试和压力测试方面,其实有很多不同的方案,比如: Rally:Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。 ESPerf:一个基于 Golang 编写的 ElasticSerch 性能测试工具 Elasticsearch Stress Test:由著名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具 除了这些定制化的工具意外以外,ElasticSearch 也可以借由其 Restful API 来使用Load Runner、JMeter等老牌工具进行测试,这些工具零零散散,各有各的用法和用途,不过,对于广大开发者而言,还是官方出…

Read More Read More

上 Kubernetes 到底有什么业务价值?

上 Kubernetes 到底有什么业务价值?

閱讀本文約花費: 13 (分鐘)开篇,我们先思考这样一个问题:“为什么要基于 Kubernetes 去构建一个应用管理平台?” 上图是一个本质的问题,我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题,我们上 Kubernetes 有什么业务价值?这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢?实际上这跟 K8s 的定位是相关的。K8s 这个项目呢,如果去做一个分析的话,我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢?大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API,这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象,而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口,实际上是对集群基础设施:网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD(也就是 Custom Resource)的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身,是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

閱讀本文約花費: 8 (分鐘)ACL 访问控制列表 规定资源可以被哪些主体进行哪些操作 场景:部门隔离 适用资源:客户页面、人事页面 在ACL权限模型下,权限管理是围绕资源来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下: ACL配置表 资源: 客户页面 主体: 销售部(组) 操作:增删改查 主体: 王总(用户) 操作: 增删改查 资源: 人事页面 主体: 王总(组) 操作: 增删改查 注:主体可以是用户,也可以是组。 在维护性上,一般在粗粒度和相对静态的情况下,比较容易维护。 在细粒度情况下,比如将不同的客户视为不同的资源,1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的,那么就要对每种资源做相同的操作;如果权限配置是无规律的,那么ACL不妨也是一种恰当的解决方案。 在动态情况下,权限经常变动,每添加一名员工,都需要配置所有他需要访问的资源,这在频繁变动的大型系统里,也是很难维护的。 在一些情况下,ACL也可应用于细粒度场景,接下来将介绍两种ACL的拓展。 DAC 自主访问控制 规定资源可以被哪些主体进行哪些操作 同时,主体可以将资源、操作的权限,授予其他主体 场景:文件系统 适用资源:人事培训文档 DAC是ACL的一种实现,强调灵活性。纯粹的ACL,权限由中心管理员统一分配,缺乏灵活性。为了加强灵活性,在ACL的基础…

Read More Read More

云原生:「落地」最重要

云原生:「落地」最重要

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了,但到底怎么去理解它,还是需要一段过程。提到云原生,很多人会联想到另一个词:「互联网原住民」,这个词代表了一群出生在互联网时代的人,他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统,不再是原来的那套思考方式,不是把云当成一个工具来使用,而是系统本身就生长于云,并在云上爆发,因此需要我们从根本上转换思考方式,重新定义业务系统。云原生和云计算也不一样,云计算的主角是计算、机器、资源,而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事: 在 2004 年那个缺电的夏天,淘宝网全都挤在华星二楼:正是在那里,开始了我的淘宝生涯。我的位置在一个角落里,边上是一堆开着的服务器,吹出的风比七月烈阳下的风更热:因为限电,空调基本上只能看。刚到一个新环境,不知道该做什么,眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的,我记得小宝有一次说,当时网站如果要改点什么,只要跑到多隆那儿说一下,等他接杯水回到座位打开页面时,需求就已经上线了。 那是 2004 年,基于当时的技术架构,任何需求只要改一下代码,就能够立刻交付。而在现在这样复杂的技术架构下,很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来,我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

语雀的技术架构演进之路

语雀的技术架构演进之路

閱讀本文約花費: 21 (分鐘)每个技术人心中或多或少都有一个「产品梦」,好的技术需要搭配好的产品,才能让用户爱不释手,尤其是做一款知识服务型产品。 作者何翊宇(花名:不四)是蚂蚁金服体验技术部高级前端技术专家,语雀产品技术负责人。本文从技术架构的视角,回顾了语雀的原型、内部服务和对外商业化的全过程,并对函数计算在语雀架构演进过程中所扮演的角色做了详细的介绍。 语雀是一个专业的云端知识库,用于团队的文档协作。现在已是阿里员工进行文档编写和知识沉淀的标配,并于 2018 年开始对外提供服务。 1 原型阶段 回到故事的开始。 2016 年,语雀孵化自蚂蚁科技,当时,蚂蚁金融云需要一个工具来承载它的文档,负责的技术同学利用业余时间,搭建了这个文档工具。项目的初期,没有任何人员和资源支持,同时也是为了快速验证原型,技术选型上选择了最低成本的方案。 底层服务完全基于体验技术部内部提供的 BaaS 服务和容器托管平台: Object 服务:一个类 MongoDB 的数据存储服务; File 服务:阿里云 OSS 的基础上封装的一个文件存储服务; DockerLab:一个容器托管平台; 这些服务和平台都是基于 Node.js 实现的,专门给内部创新型应用使用,也正是由于有这些降低创新成本的内部服务,才给工程师们提供了更好的创新环境。 语雀的应用层服务端,自然而然的选用了蚂蚁体验技术部开源的 No…

Read More Read More

上 Kubernetes 到底有什么业务价值?

上 Kubernetes 到底有什么业务价值?

閱讀本文約花費: 13 (分鐘)开篇,我们先思考这样一个问题:“为什么要基于 Kubernetes 去构建一个应用管理平台?” 上图是一个本质的问题,我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题,我们上 Kubernetes 有什么业务价值?这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢?实际上这跟 K8s 的定位是相关的。K8s 这个项目呢,如果去做一个分析的话,我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢?大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API,这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象,而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口,实际上是对集群基础设施:网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD(也就是 Custom Resource)的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身,是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

閱讀本文約花費: 16 (分鐘)前言 在高速发展的时候,公司规模越来越大,老师人数越来越多,这时候公司不能铺太多人去做运营与服务,必须提高每个人效,这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司,如果被迫成为一家靠资金驱动的公司就活不下去了。 ——张翼(掌门教育创始人兼 CEO) 掌门教育自 2014 年正式转型在线教育以来,秉承“让教育共享智能,让学习高效快乐”的宗旨和愿景,经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ,一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展,特别是今年的疫情,使在线教育成为了新的风口,也给掌门教育新的机遇。 随着业务规模进一步扩大,流量进一步暴增,微服务数目进一步增长,使老的微服务体系所采用的注册中心 Eureka 不堪重负,同时 Spring Cloud 体系已经演进到第二代,第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模,同时它目前被 Spring Cloud 官方置于维护模式,将不再向前发展。如何选择一个更为优秀和适用的注册中心,这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul 等开源注册中心做了深入的调研和比较,最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 掌门教育微服务面临…

Read More Read More

让开发部署提速8倍,我参与这款的插件的全过程

让开发部署提速8倍,我参与这款的插件的全过程

閱讀本文約花費: 20 (分鐘)如何像参与开源那样,去参与一款 IDE 插件的设计? 作为一款 IDE 插件的使用者,我是否能决定下一个版本的功能? 自从产品经理银时小伙和他的开发小哥们在去年12月发布 Cloud Toolkit(一款 IDE 插件)以来,已帮助数以万计的开发者们提高了业务的部署效率。期间,开发者们不仅是 Cloud Toolkit 的使用者,同时也作为设计者参与了插件的更新迭代。 本文来自开发者徐靖峰,分享了他和 Cloud Toolkit 的故事 遇见 Cloud Toolkit 在与中间件小姐姐的一次聊天中,偶然间了解到这款插件,小姐姐跟我提到自己正在运营一款 IDE 开发者工具,能够使开发部署效率提高 8 倍,出于好奇心,我就上手体验了一下,看看究竟是一个什么样的产品。使用了一段时间之后,便迫不及待地向小姐姐分享了我作为开发者对插件的一些看法。 我对这款产品最直观的感受:这是一款发布工具,帮助用户在 IDE 中直接打包应用并部署到各种终端。一开始看到这款产品位于阿里云的页面中,原本以为是一款和阿里云服务强绑定的产品,但试用过后才发现,即使对于普通的云主机,也非常适用,还可以解决很多开发运维的痛点,非阿里云用户可以放心使用。 在 Cloud Toolkit 出现之前 作为一个 Java 程序员,我们大多数会在 Intellij IDEA 中基于 S…

Read More Read More

Kubernetes 下日志采集、存储与处理技术实践

Kubernetes 下日志采集、存储与处理技术实践

閱讀本文約花費: 25 (分鐘) 本文介绍了“Logtail + 日志服务 + 生态”架构,介绍了:Logtail客户端在Kubernetes日志采集场景下的优势. 日志服务作为基础设施一站式解决实时读写、HTAP两大日志强需求;日志服务数据的开放性以及与云产品、开源社区相结合,在实时计算、可视化、采集上为用户提供的丰富选择。 Kubernetes日志处理的趋势与挑战 Kubernetes的serveless化 Kubernetes容器技术促进了技术栈的去耦合,通过引入栈的分层使得开发者可以更加关注自身的应用程序和业务场景。从Kubernetes本身来看,这个技术解耦也在更进一步发展,容器化的一个发展的趋势是:这些容器都将会在无服务器的基础设施上运行。 谈到基础设施,首先可以联想到云,目前在AWS、阿里云、Azure的云上都提供了无服务器化的Kubernetes服务。在serverless Kubernetes上,我们将不再关心集群与机器,只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。 如上图,左右两边分别是经典Kubernetes、serverless Kubernetes的形态。在从左向右发展的过程中,日志采集也变得复杂: 1.在一个Kubernetes node上,可能会运行更大规模量级的pod,每个pod上都可能有日志或监控指标采集需求,意味着单node上…

Read More Read More

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么? K8S全称是Kubernetes,是一个全新的基于容器技术的分布式架构领先方案,基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想,那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块,都可以使用K8S来管理,我们不必再费心于负载均衡的选型和部署实施问题,不必再考虑引入或自己开发一个复杂的服务治理框架,不必再头疼与服务监控和故障处理模块的开发。总之,使用kubernetes提供的解决方案,会大大减少开发成本,同时可以将精力更加集中于业务本身,而且由于kubernetes提供了强大的自动化机制,所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成必然,而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见,在未来几年内,会有大量的新系统选择它,不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处? 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务,一个微服…

Read More Read More

微服务写的最全的一篇文章

微服务写的最全的一篇文章

閱讀本文約花費: 14 (分鐘) 本文来自于网络,本文主要讲解的是微服务,详细阐述了微服务的利弊、服务分层、微服务的服务发现的三种方式微服务的路由发现体系等相关知识。 今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可) 2)独立的进程(java的tomcat,nodejs等) 3)轻量级的通信(不是soap,是http协议) 4)基于业务能力(类似用户服务,商品服务等等) 5)独立部署(迭代速度快) 6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择) ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。 2. 怎么权衡微服务的利于弊 利: 强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活) 可独立部署。 技术多样性。 弊: 分布式复杂性。 最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题) 运维复杂性。 测试复杂性。 3. 企业在什么时候考虑引入微服务 从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的…

Read More Read More

Scroll Up