Cloud Native

Cloud Native

火热的云原生到底是什么?一文了解云原生四要素!

阿娇 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-30 18:33 • 来自相关话题

所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
#云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
1.jpg

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
##云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
2.jpg

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
##云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
3.jpg

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
* 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
#云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
4.jpg

##持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
5.jpg

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
6.jpg

蓝绿(Blue-Green)部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
##微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
7.jpg

Going Agile - Breaking the monolith Conway's Law and Microservices

这样按照组织架构划分的优势在于:

  1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
  2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

  1. 有HA(High Available)的需求需要微服务。
  2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
  3. 经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
##容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
8.jpg

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
9.jpg

容器生态图

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
##DevOps——以终为始,运维合一

10.png

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
#总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

云原生之下的Java

尼古拉斯 发表了文章 • 0 个评论 • 188 次浏览 • 2019-05-30 10:22 • 来自相关话题

自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

华为云PaaS首席科学家:Cloud Native +AI,企业数字化转型的最佳拍档

CCE_SWR 发表了文章 • 0 个评论 • 369 次浏览 • 2019-04-23 15:29 • 来自相关话题

近日,在2019华为全球分析师大会期间,华为云PaaS首席科学家熊英博士在+智能,见未来(华为云&大数据)的分论坛上,从云计算行业发展谈起,深入云原生发展趋势,对华为云智能应用平台做了深度解读。 熊英博士为大家分享了云原生技术和平台发 ...查看全部
近日,在2019华为全球分析师大会期间,华为云PaaS首席科学家熊英博士在+智能,见未来(华为云&大数据)的分论坛上,从云计算行业发展谈起,深入云原生发展趋势,对华为云智能应用平台做了深度解读。

熊英博士为大家分享了云原生技术和平台发展的新趋势,重点介绍了华为云智能应用平台。熊英博士提出云原生技术使能企业数字化转型的三个关键点:多云解决方案、泛在的容器和智能边缘。

IT投资投资趋势

数字化转型取代传统应用

云原生技术成为技术驱动力


0423_2.jpg


根据市场调查和预测,企业近些年来在传统应用程序方面的投资正在下降,取而代之的是对云原生应用的投资。现阶段大部分企业已经开始新一轮的数字化转型,即由传统IT应用时代进入云原生应用时代。

开源社区洞悉

云原生技术惠及企业数字化转型

关注度骤升


0423_3.jpg


云原生计算基金会(Cloud Native Computing Foudation,CNCF)2018年报数据显示:

• 2018年,云原生技术在生产中的使用翻了一番;

• 2018年,正评估及准备使用云原生的企业用户增长了3倍以上;

• 从2016年到2018年,CNCF主办的云原生技术大会KubeCon + CloudNativeCon的出席人数,增长了近3倍。

熊英博士表示:在我20余年的IT从业经验中,以上这种增长无疑是少见的,由此可见云原生技术受企业的欢迎程度。

另一份来自CNCF的调查数据表明,企业得益于云原生技术带来的TOP3红利包括:

更快的部署

更高的可扩展性

更好的可移植性

这与华为从客户侧获取的反馈高度一致。


0423_4.jpg


熊英博士表示:

云原生是需要深耕的技术。华为云在2015年就将其列入战略技术投资范围,如今在这方面已经取得了大量成果,成为了云原生技术的领导者。

技术趋势分析

关键词:多云&混合云、边缘、异构计算


0423_5.jpg


如今,云原生技术虽然已经在多个行业和领域规模商用,并充分发挥其架构优势。但面向应用更高性能,更可靠的诉求,云原生技术仍需要不断发展并扩展其架构。

华为云通过持续参与到技术社区、深入到商业客户群,并与生态伙伴在云原生领域进行合作与探讨,提出云原生技术与商业结合的三大发展趋势:

多云和混合云正成为企业的常态,云原生技术将加速该进程。据中国信通院最新的混合云市场调研,半数以上的企业正在积极投入混合云的建设。云原生的可移植性从根本上解决了多云混合云实施的技术难题,有效加速企业多云混合云战略的落地进程。

计算能力应“推”至边缘。下一代云计算的形态并不会是集中式的超算中心,而是由成千上万个边缘节点连成的泛在式、分布式的边缘网络,形成泛在的云。而云原生技术将成为该模式中不可或缺的技术支撑。

云原生技术必须支持异构计算。随着AI和机器学习的规模使用,云原生技术必须支持以GPU,FPGA和ARM为代表的异构计算,为云上和边缘提供更高性能的计算资源,使能云原生应用更高效运行。

在某种程度上,华为正在引领云原生技术的趋势:这不仅是因为华为在云原生技术的投资比中国甚至是部分国外企业都要早,还因为在这个领域继续的创新,不断推出贴近客户需求的、领先于其它企业的产品。

华为云智能应用平台

应用上云更简单

数字化转型更智能


0423_6.jpg


上面提到的三点,华为云已在新推出了智能应用平台3.0中尽数包含。面向未来企业更多智能应用的场景和更高的数字化转型要求,华为云站在云原生的肩膀上,在更专注于智能应用的同时,为数字化转型提供可集成传统应用的ROMA平台以及区块链解决方案,更契合现今的IT发展阶段。

AI容器

软硬全栈优化

为规模AI训练提供云计算基础


0423_7.jpg


在AI领域,目前对算力的需求越来越高,开源组织OpenAI提出:AI领域对GPU的使用已经从单机多卡、多机多卡演进到AI专用芯片。云计算领域对FPGA和异构计算的支持在下一阶段显得尤为重要。预测采用128 GPU并行计算将会是机器学习的常态,跨集群的GPU调度能力将显著地影响计算的整体效率。

华为云容器服务面向上述场景做深度优化:更早的以容器的方式支持GPU以及专用AI芯片,让GPU和Ascend芯片的异构算力服务于大规模AI训练成为可能;借助自身硬件优势,华为云采用硬件感知的NUMA裸金属架构,IB高速网络进行深度的软硬件全栈优化,在资源池组网上保证100Gb大带宽,满足分布式训练的海量参数同步要求;在K8S调度上,针对AI场景进行深度优化,利用排队、亲和性、Gang Scheduling,对接AI分布式训练框架,使能高效的AI分布式训练,大幅度提升了计算效率。

基于以上优化,华为云在Stanford DAWN测试中,表现遥遥领先,深度学习训练对比传统GPU加速方式能够提升3-5倍,在128块GPU时线性加速比高达0.8,超出行业水平50%以上。

KubeEdge

将AI 延伸到边缘

形成泛在智能边缘网络


0423_8.jpg


据IDC研究显示,到2020年将产生500亿的终端与设备联网,其中50%的数据将会在网络边缘侧分析处理,其中90%的需求来源于AI计算。常见的边缘计算方案,没有更多考虑对智能应用的支持。边缘计算应当聚焦于支持智能应用,并增强对智能芯片兼容性。面向在边缘进行的AI推理,边缘侧资源、监控、调度的复杂性将随规模的扩大成倍增长,直接影响整体计算效率,因此提升边缘的管理能力迫在眉睫。

华为云贡献给CNCF的开源项目KubeEdge,是完全基于云原生技术的:KubeEdge首先解决了智能应用的移植性问题,为构造泛在的智能边缘网络提供可能性。

KubeEdge还是CNCF社区接纳的首个边缘计算项目,并已成为智能边缘计算领域的架构标准。

多云&混合云管理

实现跨多云&混合云智能治理


0423_9.jpg


使用多云&混合云已经成为企业上云的共识,快速实现云原生应用跨云管理、部署、运营也是企业上云的关键诉求。华为云作为全行业首发容器多云混合云管理平台的云服务提供商,在今年3月已实现:

多云多活应用、秒级流量接管:云单点宕机故障发生时,应用实例和流量可以秒级完成迁移。

自定义流量策略实现自动跨云弹性:用户通过在跨云部署应用时提前定义流量策略,可应对未知流量高峰。私有云或某个公有云上的服务无法负担时,可以根据流量策略,将服务弹性扩容到其它云集群上,分担流量负载,避免因流量冲击而造成系统瘫痪。

地域亲和性策略优化客户访问体验。应用跨区域部署时,使用自定义的流量管理亲和性策略,能更合理的根据地域对流量进行分配。降低业务访问时延,提升业务响应速度。

华为云多云混合云容器解决方案实施云原生技术领域首个商用的多云&混合云的管理平台,比上周Google刚刚发布的Anthos早了近一个月。

云原生时代已至

行业数字化转型

【Cloud Native BEST】


0423_10.jpg


华为云智能应用平台用户遍布互联网、教育、金融、生物医药等行业,在已经到来的云原生时代,全面使能各行业的数字化转型。

最后,熊英博士提出Cloud Native BEST:我们正处在IT转型期,人工智能和云原生技术是推动企业数字化转型的最佳搭档, 华为很早就看到了这一趋势,并构建了智能应用平台,提供Between Clouds, Edge Intelligence, Strongest Container and enable Transformation,旨在帮助更多的企业实现云原生和数字化转型。

Cloud Native Weekly |面对云平台宕机,企业如何止损

CCE_SWR 发表了文章 • 0 个评论 • 324 次浏览 • 2019-03-12 09:36 • 来自相关话题

KubeEdge v0.2发布 KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目,旨在依托K8S的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。 Kube ...查看全部
KubeEdge v0.2发布

KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目,旨在依托K8S的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。

KubeEdge脱胎于华为云IEF服务,是第一个具备在生产环境部署能力的边缘计算领域开源项目。前几天K8S IOT/Edge工作组发布了关于边缘计算的白皮书,并将KubeEdge作为K8S在IOT/Edge场景下的参考架构。

KubeEdge架构上包含两部分,分别是云端和边缘侧。云端负责应用和配置的下发,边缘侧则负责运行边缘应用和管理接入设备。

在v0.2版本中,KubeEdge团队决定开放云端代码,这样KubeEdge v0.1和v0.2的发布分别创造了两个记录:

全球首个开源的支持容器部署的边缘计算平台;

全球首个开放云边协同能力的边缘计算平台;

KubeEdge v0.2 的发布意味着任何人都可以在自己的环境中部署一个完整的涵盖云、边、设备的边缘计算解决方案。另外本次更新还在 v0.1 的基础上新增了云上两个重要组件,分别是:CloudHub和EdgeController,架构如下所示:

1.png



其中:

Cloudhub负责接收EdgeHub同步到云端的信息;

EdgeController用于控制K8S API Server与边缘的节点、应用和配置的状态同步;

用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用,使用习惯与K8S原生的完全一致,无需重新适应。

Rancher发布轻量级Kubernetes发行版 K3s

2.png



近期,容器管理软件提供商 Rancher Labs宣布推出轻量级的 Kubernetes 发行版 K3s,这款产品专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计。

根据Rancher描述,为了减少运行Kubernetes所需内存,k3s主要专注于以下三个方向的变化:

删除旧的、非必须的代码

整合正在运行的打包进程

使用 containerd 代替 Docker 作为运行时的容器引擎

除了 etcd 之外,引入 SQLite 作为可选的数据存储

k3s官方描述的主要使用场景为:

边缘计算

与应用程序绑定使用

嵌入式设备

整体来看,k3s相当于kubernetes针对边缘计算等特殊场景的裁剪和优化,而并非专门专门边缘计算场景的解决方案,未来可能还需要长足的演进和适配过程。

阿里宣布开源 Flutter 应用框架Fish Redux

3 月 5 日,闲鱼宣布在 GitHub 上开源 Fish Redux,Fish Redux 是一个基于 Redux 数据管理的组装式 flutter 应用框架, 特别适用于构建中大型的复杂应用,它最显著的特征是 函数式的编程模型、可预测的状态管理、可插拔的组件体系、最佳的性能表现。

Redux 是来自前端社区的一个用来做 可预测易调试 的数据管理的框架,所有对数据的增删改查等操作都由 Redux 来集中负责。Redux 核心仅仅关心数据管理,不关心具体什么场景来使用它,这是它的优点同时也是它的缺点。在实际使用 Redux 中可能面临两个具体问题:

Redux 的集中和 Component 的分治之间的矛盾;

Redux 的 Reducer 需要一层层手动组装,带来的繁琐性和易错性;

Fish Redux 通过 Redux 做集中化的可观察的数据管理,并且针对传统 Redux 在使用层面上的缺点,在面向端侧 flutter 页面纬度开发的场景中,通过更好更高的抽象,做了改良。

开源之后,闲鱼打算通过以下方式来维护 Fish Redux:

通过后续的一系列的对外宣传,吸引更多的开发者加入或者使用。

配合后续的一系列的闲鱼 Flutter 移动中间件矩阵做开源;

进一步提供,一系列的配套的开发辅助调试工具,提升上层 Flutter 开发效率和体验;

又现云平台宕机企业应如何尽量避免损失

北京时间2019年3月2日23:55分左右开始,监控发现华北2地域部分ECS实例及部分EMR、RDS on ECS、DTS、DBS实例及服务状态异常,事后于3月3日阿里云工程师紧急排查处理,并且逐步恢复异常实例。

细数这两年,国际主流云厂商在安全性和可靠性层面做了不少努力,但所有服务都不可能百分百稳定,尽管云平台会发生故障,但企业对云的信赖度依然很高。Gartner 研究主管 Sid Nag 曾表示,云服务市场的增长速度比几乎所有 IT 市场都要快,其中大部分增长是以传统非云服务为代价,尤其是基于云计算的 IaaS 需求在继续增长,预计将在未来 5 年呈现最快增长趋势。

在云计算出现之前,企业内部自建数据中心依旧会出现很多问题,不少问题甚至是致命的。上云之后,公有云厂商至少可以帮助技术能力有限的企业进行合理范围内的监控、预警和备份。不可否认,云的出现确实解决了现阶段企业在计算、存储等方面的很多问题。但作为企业而言,完全依靠云计算厂商提供安全性的做法是不可取的。

云环境的同城双活、异地灾备等方案基本就绪,尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群,采用异地灾备方案可以在最快时间切换到另一个集群,从而保持系统可用。虽然还是会有中断,但是可以最快时间恢复。

按照此模式,云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员,日常做到以下四点可以尽可能避免云故障带来的损失。

•备份、备份,还是备份,要异机异地;

•数据容灾;

•业务双活;

•定期对灾备和双活进行演练。

从统计上看,中小企业的运维水平远低于主流云平台,故障概率要高得多,损失更不可控。因此,不必对云服务故障抱有恐惧,只需要保持正常的认知和高度灾备意识即可。


相关服务请访问:
https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

灵雀云CTO陈恺:从“鸿沟理论”看云原生,哪些技术能够跨越鸿沟?

灵雀云 发表了文章 • 0 个评论 • 822 次浏览 • 2019-03-11 11:38 • 来自相关话题

历史进入2019年,放眼望去,今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节,我们来梳理和展望一下整个云原生技术趋势的发展,是一件很有意义的事情,这其中有些变化在不可避免地影响着我们身处其中的每一家企业。 ...查看全部
历史进入2019年,放眼望去,今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节,我们来梳理和展望一下整个云原生技术趋势的发展,是一件很有意义的事情,这其中有些变化在不可避免地影响着我们身处其中的每一家企业。

如果说云原生在2017年还仅仅是冒出了一些苗头,那么2018可以说是普及之年,云原生变成了一个成熟的、被普遍接受的理念。

早在1991年Jeffery Moore针对高科技行业和高科技企业生命周期的特点,提出了著名的“鸿沟理论”。这个理论基于“创新传播学”,将创新性技术和产品的生命周期分为五个阶段:创新者(Innovator)、早期使用者(Early adopters)、早期大众(Early majority)、晚期大众(Late majority)、落后者(Laggard)。
01.png

在Early adopters和Early majority之间有个巨大的鸿沟(Chasm),每个新技术都会经历鸿沟,大多数失败的产品也都是在鸿沟里结束了其整个生命周期,能否顺利跨越“鸿沟”,决定了创新性技术的成败。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。
#“Kubernetes is Boring”,边缘创新有亮点
Kubernetes在2017年底成为容器编排事实标准,之后以其为核心的生态持续爆发,在传播周期上可以说已经跨过鸿沟了,进入Early majority早期大众阶段,开始占领潜力巨大的主流市场。
02.png

根据CNCF在2018年8月进行的第六次测量容器管理市场的温度,83%的受访者更喜欢Kubernetes的容器管理工具,58%的受访者在生产中使用Kubernetes,42%的受访者正在进行评估以备将来使用,40%的企业(员工规模在5000+)正在使用Kubernetes。Kubernetes在开发人员中已经变得非常流行。
03.png

进入主流市场的Kubernetes开始变得“Boring”,这很正常,甚至是一个好的现象。核心项目的创新速度会减慢,最新的版本中主要关注点聚焦在稳定性、可扩展性这些方面,尽可能把代码从主库往外推,让它的主库变得干净,其他功能通过一些扩展机制来做,同时开始关注安全性。

Kubernetes项目本身已经过了现象级创新爆发的阶段,但由Kubernetes独特的架构属性催生出的周边生态的二次创新仍然在高速发展,例如诸多与Kubernetes集成或者基于Kubernetes框架开发的上层服务与平台。这个话题我们下次讨论,今天还是主要关注与Kubernetes项目关联最紧密的创新亮点:

早期容器化workload大多聚焦在无状态服务,跑的最多的是Nginx,而对有状态应用避讳不谈。现在Kubernetes进入主流市场,显然需要对“现实中的应用”,包括有状态服务提供良好的支持。2019年,对于复杂应用的管理以及Kubernetes本身的自动化运维将会更多的表现为Operator。

Operator是基于Kubernetes扩展机制,将运维知识编写成“面向应用的Kubernetes原生控制器“,从而将一个应用的整体状态作为API对象通过Kubernetes进行自动化管理。这个应用通常来说是比较复杂的有状态应用,如MySQL数据库、Redis集群、Prometheus等等。现在基本上常见的有状态应用都有自己相对应的Operator,这是一种更为有效的管理分布式应用的方式。

其次是应用跨集群部署与管理。早期社区里有Federation联邦集群的方案。不少大金融客户都有跨集群部署、管理业务的需求。当时深入研究Federation v1之后,觉得这个方案复杂度高,观点性强,对于实际的需求灵活度不足而又不够成熟。所以最终选择自研跨集群部署。后来出现的Federation v2在设计方向上有不小改观,是需要持续关注的项目。

早期采用容器技术的用户都会尽可能兼容企业原有的IT基础设施,比如底层物理机,保留物理机之上的虚拟层,虚拟机之上再跑容器。当然,面向资源管理的硬件虚拟化和面向应用的容器化本质上没有冲突。随着Kubernetes的普及并且在应用上超越了容器编排的范畴,后Kubernetes时代如何搭建管理基础设施是值得思考的。我们也观察到一些有意思的趋势,比如在Kubernetes上同时管理容器和虚拟机(所谓的“容器原生虚拟化”),或是使用Kubernetes来管理OpenStack。

总之,Kubernetes在云计算领域成为既定标准,会越来越多的往下管理所有种类的基础设施,往上管理所有种类的应用。这类标准的形成对于技术社区有很大的益处,会大大降低围绕Kubernetes技术投入的风险。因此,我们会看到越来越多的周边技术向它靠拢,在Kubernetes之上催化出一个庞大的云原生技术生态。

#DevOps:开放式工具链集成与编排
DevOps理念、方法论和实践已经走到了Early Majority早期大众阶段,是已被实践证实的高效开发运维方法。做容器的厂商都经历过用容器搞CI/CD,CI/CD是容易发挥容器优势的显而易见的使用场景。

DevOps包含好几层概念,首先是组织文化的转变,然后涉及到一系列最佳实践,最终这些最佳实践需要用工具去落地。我们在帮助很多大型企业客户落地DevOps的过程中发现:

  1. 在DevOps的整个流程里涉及到很多类别的工具,每一个类别都会有大量的选择;
  2. 每个客户的工具选型多少会有些不同,并不存在一个固定的、完全标准的工具组合;
  3. 随着时间的推移工具选择会发生变化,多数客户意识到目前使用中的工具在未来很可能会被替代。

基于这些观察,DevOps有一种做法是,打造开放式的DevOps工具链集成与编排平台。这个平台可以灵活的兼容客户的工具选型,通过集成将各类工具串联起来,形成一套工具链,通过编排让DevOps工具链与容器平台联动,形成一个完整系统。同时,不断结合自身的经验,提炼DevOps落地的最佳实践,平台将这些最佳实践自动化,作为服务进行输出。

同时,DevOps工具链的编排也最好基于Kubernetes来实现。Kubernetes不仅是出色的容器编排工具,扩展之后也很适合编排DevOps工具。换句话说,可以打造一套“Kubernetes原生的DevOps平台”。
#微服务:落地需要一套完整的基础设施
提起微服务治理,很多人会条件反射般的联想到某些特定的技术,例如Spring Cloud,或者Service Mesh。我们不妨先退后一步,系统考虑下企业微服务架构改造和落地所需要的完整的基础设施。
04.png

首先,在微服务应用的底层需要一个应用管理平台,这在今天毋庸置疑是一个基于Kubernetes的容器平台。
 微服务本质上是分布式应用,在我们获取敏捷性的同时不可避免的增加了运维和管理的难度。微服务对自动化运维,尤其是可观测性的要求很高。支持微服务架构的基础设施必须具备完善的监控、告警、日志、分布式追踪等能力。

在微服务应用的前方,通常需要一个API网关,来管理对外暴露的API。API治理策略,包括安全、路由、流控、遥测、集成等对于任何应用平台都重要,但在微服务架构下尤为关键。我们需要通过定义、封装对外API来屏蔽应用内微服务组件结构细节,将客户端与微服务解耦,甚至为不同客户端提供个性化的API。

云原生应用的一大准则是应用与状态分离。在微服务架构下,每个微服务组件更是应该完全掌控自己的数据。所以,云原生应用通常依赖外部数据服务(Backing Services),而在微服务架构下,多元化持久性(Polyglot Persistence)是常态,也就是说一个微服务架构的应用会依赖非常多种类的 Backing Services。面向微服务架构的基础设施需要将这些外部服务暴露给微服务应用消费,甚至直接支撑各类Backing Services 的部署和管理。

一个团队之所以采用微服务架构,一定有敏捷性的诉求。所以通常微服务团队也会拥抱DevOps理念。一个完善的面向微服务架构的基础设施需要考虑 DevOps 流程以及工具链的自动化。

最后,我们回到狭义的微服务治理,这里关注的是微服务组件之间的连接与通讯,例如服务注册发现、东西向路由流控、负载均衡、熔断降级、遥测追踪等。现在有个时髦的术语来描述这类功能,就是大家熟悉的Service Mesh。其实早期 Sping Cloud 之类的框架解决的是类似的问题,但在实现的方式上,尤其是mesh 和业务代码的耦合度上,有本质的区别。

当我们考虑一个平台如何支撑微服务架构的时候,需要涵盖上述提及的方方面面,从产品的角度我们会保持一个开放的态度。这其中一部分需要我们自己去做,其他一些可以借助生态合作伙伴的能力去补全完善。
此外,微服务架构也进入到了后Kubernetes时代,早期基本上是微服务作为用例推动容器技术的发展。今天已经反过来了,成为标准的Kubernetes其实在驱动和重新定义微服务的最佳实践。容器和Kubernetes为微服务架构的落地提供了绝佳的客观条件。
#Service Mesh:下一个亟待爆发的现象级技术创新
业界对于Service Mesh的布道已经持续了一段时间,我们今天不再重复基本的概念。当我们把Service Mesh和上一代以Spring Cloud为代表的微服务治理框架以及更早的Service Oriented Architecture(SOA)作比较的时候,会看到一个有意思的演化。

我们知道,SOA有企业服务总线(ESB)的概念,ESB重且复杂,其实会混杂很多业务逻辑。SOA架构下,ESB最终容易变成架构以及敏捷性的瓶颈。早期推广微服务架构的时候,一个重要的概念就是“Smart Endpoints and Dumb Pipes”,针对的就是SOA下ESB的痛点,从而每个微服务能够独立、自治、松耦合。

但是仔细去想的话,就会发现它其实走到了另一个极端:它把一些基础设施提供的能力放到微服务的业务组件里面了,通常每个组件需要加载一些治理框架提供的库,或是调用特定的API,其实就是在业务组件里内置了基础设施的功能。到了Service Mesh其实又把它们分开了,从架构角度这样也比较合理,应用是纯业务的东西,里面没有任何基础设施,而提供微服务治理的基础设施,要么在Mesh里面,要么由底层的Kubernetes平台来提供,对应用是透明的。

Istio的出现促使业界对于Service Mesh的架构有了新的共识:控制平面(Control Plane)与数据平面(Data Plane)解耦。通过独立的控制平面可以对Mesh获得全局性的可观测性(Observability)和可控制性(Controllability),让Service Mesh有机会上升到平台的高度。相对于需要在业务代码层面使用的上一代微服务治理框架,这点对于希望提供面向微服务架构基础设施的厂商,或是企业内部需要赋能业务团队的平台部门都具有相当大的吸引力。

在Data Plane,Envoy的领导者地位毫无争议。Envoy使用C++开发,在资源使用效率和性能上(尤其是长尾性能差异)相较早期主要竞争对手Linkerd有明显优势。Envoy提供基于filter chain的扩展机制,从Kubernetes的成功当中我们已经学习到,可扩展性对于大规模采用十分关键。

Envoy定义了一套“通用数据平面API”(Universal Data Plane API),也就是它的xDS协议。不仅确保了Envoy本身的动态可配置性,更重要的是为Service Mesh中Control Plane和Data Plane解耦提供了一个标准的接口。由于主流Control Plane(例如Istio)对Envoy以及xDS的采纳,xDS成为Service Mesh Data Plane API的事实标准,Envoy也成为无可争议的Data Plane领导者。
05.png

在Control Plane,Istio是最具光环的明星级项目。它正在引领Service Mesh创造出一个全新的市场,不过从传播周期看现在还没有跨过技术鸿沟,处于Early adopters阶段。

过去一年中,Istio项目在技术上的表现并不完全令人满意,主要体现在对其复杂度的诟病,以及稳定性和性能的质疑。1.0版本的推出并没有完全令人信服。不过,这些似乎并不影响Istio在社区获得的巨大成功。在开源领域,并不存在对Istio有实质性威胁的竞品。可能在经历了Kubernetes之后,以及Istio早期迅猛的发展和在社区中巨大的影响力之下,很少有开源项目愿意在Control Plane和Istio正面交锋。

长远来讲,Data Plane会慢慢变成commodity,尤其在有了Universal Data Plane API之后。我们有理由相信成熟稳健的Envoy会保持领先,但最终多数用户会越来越少去关心具体的Data Plane技术。这个情境似曾相识,和当初Docker与Kubernetes的关系有点类似。

下个阶段Service Mesh的赋能和创新会更多聚焦在Control Plane。AWS在Data Plane选择成熟的Envoy,而自己开发App Mesh的Control Plane,就很容易理解。灵雀云已经在ACE/ACP两条产品线中集成了Istio,提供企业就绪的Service Mesh。
#云原生为机器学习输出工程化最佳实践
云原生的理念与相关技术对于应用开发与交付的巨大价值已经被普遍接受。但云原生不仅仅可以作用在普通的应用开发上。站在容器平台的角度看,机器学习毫无疑问是一类极为重要新兴工作负载。在未来,可能所有的公司都会是AI公司,所有的应用都会是智能应用,使用算法、模型就像今天应用会依赖数据库一样普遍。

如果我们分析数据科学家的工作流,会发现和传统应用开发有很多相似的挑战。如何方便的获取实验环境;如何让实验可重复;如何将数据处理、特征提取、模型训练、模型验证、模型发布这些步骤自动化,并且可重复;如何让研究和生产环境保持一致;如何在生产环境做模型变更、AB测试、灰度发布;如何在生产环境运维模型服务;如何将模型服务化,等等。

在软件工程领域,云原生的理念、方法论和最佳实践已经为类似问题找到了良好的解决方案。这些方案其实非常适合应用在机器学习场景。换句话说,我们需要“云原生机器学习”。这仍然是一个相对早期的概念,从鸿沟理论的周期来看,云原生机器学习大致还处在Innovators创新者尝鲜的阶段。

进入2019年,巨大的增长空间和发展势头等待着已成事实标准的Kubernetes和容器技术继续开疆拓土,落地到各种业务场景中;DevOps一片蓬勃人气不减,通过打造开放式DevOps工具链集成与编排平台,形成完整的工具链,将最佳实践输出给客户;微服务进入到后Kubernetes时代,Service Mesh技术日渐成熟,落地将成为新的重点。

云原生技术不再曲高和寡,高处不胜寒,成为业内主流标准取舍的关键。今天我们提到的上述云原生技术都是有创新性、颠覆性的技术,有希望顺利跨越鸿沟(Chasm)进入主流市场。2019年的云原生技术将实现实实在在的升级、成熟与落地。

为什么 Service Meshes,容器编排工具是云原生部署的必然选择?

samzhang 发表了文章 • 0 个评论 • 563 次浏览 • 2019-03-11 09:31 • 来自相关话题

【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝 ...查看全部
【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。

独立,短暂的微服务过程带来了一些重大好处,但是保持跟踪每一个单独的微服务是一个挑战,特别是尝试去弄清楚当一个微服务下线后,剩下的服务会受到什么样的影响。最终的结果是,如果你正在一个微服务架构下运营或开发,那么你的一部分时间将会被消耗在搞清楚你的服务到底是什么上。

随着微服务的采用,大型系统中存在大量服务,因此出现问题不可避免。诸如,安全,负载均衡,监控和限速这些问题,过去不得不同意解决,而现在,不得不单独为每个服务一一解决。

幸好工程师乐于这样的挑战。而且每当微服务产生新的问题时,他们都会通过新兴的微服务工具和技术来定位这些问题。也许微服务的出现只是工程师确保饭碗的智能游戏。

如今Cloud Native的宠儿Kubernetes,缓解了微服务带来的许多挑战。自动调度,横向扩展和服务发现,解决了大多在微服务中构建和部署服务将遇到的问题。

Kubernetes 留下了一些尚未解决的容器化应用环境的问题。这就是 Service Mesh 的介入点。让我们看一下 Kubernetes 提供了什么,和 Istio 如何增强 Kubernetes 解决微服务运行环境的问题。
#Kubernetes 解决了构建和部署的挑战
容器编排工具,诸如 Kubernetes,解决了许多来自于容器化应用的构建和部署的挑战。

Kubernetes 支持微服务架构,使开发者能够抽象出一组 Pod 的功能,并且通过明确的 API 来曝露服务给其他开发者。Kubernetes 支持四层负载均衡,但是不能解决更高层的问题,例如,七层指标、流量分流、限速和断路。
#Service Mesh 解决了运行时管理流量的挑战
Service Mesh 有助于解决最终用户使用应用程序时出现的许多挑战。能够监控哪些服务相互通信,他们的通信是否安全和是否能够控制你的集群中服务和服务间的通信,这是确保你的应用安全和弹性运行的关键。

通过在整个过程中生成统一的度量标准,Istio 可以在微服务架构中提供一致的视图。它消除了协调各种运行时代理发出的不同类型的度量标准的需要,或添加任意代理来收集旧的未检测应用程序的度量标准。它在您的多语言服务和集群中增加了一定程度的可观察性,这在任何其他工具的细粒度水平上是无法实现的。

Istio 还增加了更深层次的安全性。Kubernetes 仅提供基本的秘密分发和控制平面证书管理,但是 Istio 提供 mTLS 功能,因此您可以对线路流量进行加密,以确保您的服务间通信是安全的。
#完美的匹配
将 Kubernetes 与 Istio 配对可以为您提供两全其美的优势,而且由于 Istio 是在 Kubernetes 上运行的,因此两者可以无缝协作。您可以使用 Kubernetes 来管理所有构建和部署需求,Istio 负责处理重要的运行时问题。

Kubernetes 已经成熟到大多数企业都将其用于集装箱编排。目前,有 74 家 CNCF 认证的服务提供商,这证明了市场规模庞大且不断增长。我认为 Istio 是 Kubernetes 的延伸,为了解决更多挑战。

Istio 已经快速成熟,并开始在企业中更多地采用。可能在 2019 年,我们将看到 Istio 成为企业的服务网格标准,就像 Kubernetes 作为集装箱编排的标准一样。

原文链接:Why Service Meshes, Orchestrators Are Do or Die for Cloud Native Deployments(翻译:Sam)

云原生DevOps工程师的角色和职责

dummy 发表了文章 • 0 个评论 • 805 次浏览 • 2019-01-15 21:26 • 来自相关话题

云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基 ...查看全部
云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基础包含有四个主要概念:微服务、容器、CI/CD和DevOps。

微服务是一种将应用程序开发为一系列小型专用服务的方法,这些服务组合在一起形成一个完整的产品。这些功能被打包到像Docker这样的容器中,然后通过持续集成/持续部署管道进行推送。微服务的模块化使不同的团队能够在产品的不同部分上并行工作而不会相互干扰,并且还通过减少任何这些服务的失败对其他服务的影响来增强产品。

使用容器来托管微服务是非常有效的,因为容器比传统虚拟机更有效地使用系统资源。它们只需要运行与它们托管的应用程序相关的服务,而不是整个客户操作系统及其相应的进程。容器对于云原生应用程序的敏捷部署至关重要,尤其是与Kubernetes等管理软件配合使用时。所有这些都是使CI/CD成为可能的基础。如果没有这些工具提供的灵活性,那么这些允许更改,修复或将功能推到生产环境,从开发到自动代码审查和测试的CI流程将非常困难。

DevOps使用所有这些乃至其他更多工具来解决所谓孤岛问题,就是当开发人员编写代码然后将其扔到Ops部门时会发生什么。开发人员从头到尾不拥有他们的代码的结果就是,Ops部门经常需要负责维护未考虑基础架构的代码。这里的解决方案不仅仅是创建出第三个结合开发和运维角色的闭塞的环境。

DevOps不仅仅是一个流程或工作岗位,它更是一种所有权文化。



DevOps工程师试图培养“谁开发谁维护”的理念,这意味着他们需要从软件开发过程一开始就评估可能困扰应用程序生产的瓶颈。云原生DevOps工程师需要能够通过CI/CD流程获取应用程序,以确保代码可以构建,通过测试并在不破坏生产环境的情况下进行部署。这因此激励他们思考应用程序在创建之前的运行方式,并编写脚本来创建持续的集成管道,以确保产品的上市时间更快,用户体验更好。

最优秀的DevOps工程师将能够使用或学习各种开源技术,并且熟悉大量用于编写脚本的编程语言。他们在IT系统,操作和数据管理方面拥有一些经验,能够将这些知识集成到CI/CD开发模型中。至关重要的是,DevOps工程师不仅需要编写代码,还要考虑他们开发的产品的实际业务成果。像这样的全局思考还需要强大的软技能,以实现跨团队以及客户和技术团队之间的沟通。

当然,没有谁是一座孤岛。DevOps团队虽然在同一个组织覆盖下运作,但是需要各类不同的角色才能胜任。这些团队成员的实际头衔可能会因地而异,但一般职责仍然相同:

  • 产品负责人(负责团队的工作):此人担任客户团队联络人。他们需要特别强大的软技能和有效沟通技术概念的能力,以便与客户合作,提出满足期望的产品。他们了解全局,可以告诉团队应该如何运行应用程序以及使用什么基础架构。
  • 团队领导(负责团队的工作方式):此人是技术团队的管理类型角色。他们根据团队成员的个人优势和技能集来委派职责。他们也贡献代码,但是在短期发展冲刺背景下,他们使团队与产品所有者的全局观保持一致。他们通常对技术决策有最终决定权。
  • 自动化架构师/站点可靠性工程师(SRE):此人在构建云基础架构方面经验丰富,并了解在生产中支持应用程序所需的内容。他们开发自动化系统,以确保持续部署顺利运行。他们专注于确保基础架构在大规模环境中的稳定性能,并了解如何随着公司的发展扩展基础架构。
  • 软件开发人员:软件开发人员将与之前列出的所有团队成员一起工作,并根据客户的要求创造出代码,然后进行测试,部署和监控。

随着团队的发展,这些角色可能会分成几个其他更细粒度的职位,以便利用增加的人力资源。UX工程师,测试工程师和安全工程师就是一些例子,它们会从列出的其他一些人那里承担重要的责任并对其进行扩展。

原文链接:Roles and Responsibilities of Cloud Native DevOps Engineers(翻译:fengxsong)

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 855 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

微服务浪潮中,程序猿如何让自己 Be Cloud Native

李颖杰 发表了文章 • 0 个评论 • 649 次浏览 • 2018-12-26 10:08 • 来自相关话题

# 前言 CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等 ...查看全部
# 前言
CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等于我们自己的软件就已经是 Cloud Native,在使用哑铃和成为肌肉男之间还隔着科学使用和自律锻炼两道工序;在此,笔者想根跟大家聊聊让我们的应用真正变得 Cloud Native 时的理论依据:微服务的十二要素。这篇文章也是先从作者自身项目的角度(一个基于 EDAS 的微服务架构),来阐述对这十二条要素的前两条 —— 仓库(Code Base)与依赖(Dependency)的理解。

Code Base 的原文释义是:"一份基准代码,多份部署,基准代码和应用之间总是保持一一对应的关系;不同环境中的相同应用,应该来源于同一份代码"。我的理解有两个:

  1. 一个应用,产生自同一个仓库。
  2. 一个仓库,只产生一个应用。

为什么推演出这么两个结论呢?让我们先看一个实际的项目。
# 为什么是一个应用?
给大家举一个一个仓库包含多个应用的反例,笔者自己的一个项目是一个微服务架构,和大部分的微服务架构一样,一开始是由一个单体的应用拆解而来,拆解之后,大致简化成四个服务:微服务网关(Gateway),两个后台服务(UserService, OrderService),后台管理控制台服务(Admin),简单的架构示意图如下:
arch.png

在拆分的过程一开始为了项目上线减少风险,将拆分之后的应用都放在了一个 Git 仓库中进行管理,同时也共用了同一个库。重构之后仓库的目录如下:
~/workspace/java/app/ $ tree -L 2
.
├── README.md
├── service-api # 通用的 API 接口定义
│ ├── userservice-api # 服务 UserService 的声明
│ ├── orderservice-api # 服务 OrderService 的声明
│ ├── rpc-api # 远程服务调用相关的接口声明
│ ├── common-api # UserService 与 OrderService 都依赖的声明
| .....
├── service-impl # 对应 API 的相关具体业务实现
│ ├── userservice-impl
│ ├── orderservice-impl
│ ├── common-impl
| .....
├── web-app # Web 应用工程
│ ├── admin
│ ├── userservice
│ ├── orderservice
│ ├── gateway

一开始这些服务之间的发布和改动彼此都不受影响,这一过程持续了大约两个迭代,随着迭代的不断进行和新人的加入,后来我们线上发现一个很奇怪的现象,每次用户进入刷新订单的地址列表的时候,会伴随这一次用户 Token 的刷新而导致用户被踢出,线上的排查过程在 EDAS 的分布式链路跟踪系统 EagleEye 的帮助下,马上就定位到了出问题的代码:
java
// User Service 中
public class User {
public void refresh() {
// 刷新登录 token
}
}

// Order Service 中
public class OrderUser extends User {
// 函数少了一个字母,导致 refresh 调用了父类的 refresh
public void refesh() {
// 刷新地址列表
}
}

​这个故障,我先邀请大家一起思考一下几个问题:

  1. 从编码角度,如何避免上述重写的方法因为名字误写造成故障?
  2. 从设计角度,OrderUser 和 User,是否是继承关系?
  3. 这个问题的根因是什么?

以上的几个问题中,第一个问题的答案,很多同学都知道,就是使用 Java 自带的 Annotation `@Override`,他会自动强制去检查所修饰的方法签名在父子类中是否一致。第二个问题,需要从领域边界来说,这是一个典型的边界划分的问题,即:订单中的用户,和会员登录中的用户,是不是相同的“用户”?会员中的用户,其实只需要关心用户名密码,其他都是这个用户的属性;而订单中的用户,最重要的肯定是联系方式,即一个联系方式,确定一个人。虽然他们都叫做用户,但是在彼此的上下文中,肯定是不一样的概念。所以这里的 `OrderUser` 和 `User` 是不能用继承关系的,因为他们就不是一个 "IS A" 的关系。

仓库共享,加上没有多加思考的模型,导致依赖混乱;如果两个 `User` 对象之间代码上能做到隔离,不是那么轻易的产生“关系”,这一切或许可以避免。
# 为什么是一个仓库?
严格意义上说,一个应用的所有代码都肯定来源于不同的仓库?我们所依赖的三方库如(fastjson,edas-sdk 等)肯定是来源于其他的仓库;这些类库是有确切的名称和版本号,且已经构建好的"制品",这里所说的一个仓库,是指源码级别的“在制品”。可能在很多的项目中不会存在这样的情况,以 Git 为例,他一般发生在 Submodule 为组织结构的工程中,场景一般是啥呢?在我们这个工程中确实是有一个这样的例子:

为了解掉第一个问题,我们决定拆仓库,仓库的粒度按照应用粒度分,同时把 common 相关的都拆到一个叫做 common 仓库中去;业务服务都好说,这里特殊处理的是 admin 应用,admin 是一个后台管理应用,变化频度特别大,需要依赖 UserService 和 OrderService 一大堆的接口。关于和其他仓库接口依赖的处理,这里除了常见的 Maven 依赖方式之外,还有另外一个解决方案就是 git submodule,关于两个方案的对比,我简单罗列在了下表之中:
B.png

我觉得如果这个项目组只有一两个人的时候,不会带来协作的问题;上面的方案随便哪一个都是不需要花太多时间做特殊讨论,挑自己最熟悉最拿手的方案肯定不会有错,所谓小团队靠技术吗,说的就是这么个道理;我们当时是一个小团队,同时团队中也有同学对 Submodule 处理过类似的情况,所以方案的选择上就很自然了。

后来随着时间的推移,团队慢慢变大,就发现需要制定一些流程和和规范来约束一些行为,以此保障团队的协作关系的时候;这时候发现之前靠一己之力打拼下来的地盘在多人写作下变得脆弱不堪,尤其是另外一个 Submodule 变成一个团队进行维护的时候,Submodule 的版本管理几乎不可预期,而且他的接口变动和改动是完全不会理会被依赖方的感受的,因为他也不知道是否被依赖;久而久之,你就会明白什么叫做你的项目被腐化了。简单理解腐化这个词就是,你已经开始害怕你所做的一切改动,因为你不知道你的改动是否会引来额外的麻烦。从这个角度也可以去理解为什么一门语言设计出来为什么要有 privatepublic这些表示范围的修饰词。正因为有这些词的存在,才让你的业务代码的高内聚成为的有可能,小到设计一个方法一个类、再引申到一个接口一个服务、再到一个系统一个仓库,这个原则始终不变。

上述问题带来的解法很简单,就是变成显示依赖的关系,所谓显示依赖是指的两个依赖之间是确定的。什么是确定的?确定 == No Supprise !对,不管什么时候,线上还是线下,我依赖你测试环境的接口返回是一个整数,到了线上,返回的也必须是一个整数、不能变成浮点数。而让确定性变得可行的,不是君子协定;只能是一个版本依赖工具。比如说 Java 中的 Maven 正式的版本依赖。
# 结语
职责内聚、依赖确定,是我们的应用变得真正 Cloud Native 的前提。没有了这些基本的内功,懂的开源软件再多、对微服务栈再熟悉,也会有各种意想不到的事情出来,试想一下,如果应用的职责到处分散,那到时候扩容到底扩谁呢?如果依赖方变得及其不确定,谁又来为每次发版的不确定的成本买单?Be Cloud Native,请从应用代码托管的住所开始。

作者:阿里巴巴高级技术专家 孤弋

灵雀云重磅发布3大云原生产品 顺应传统IT云原生转型需求

灵雀云 发表了文章 • 0 个评论 • 907 次浏览 • 2018-10-10 11:10 • 来自相关话题

近日由云原生技术实践联盟(CNBPA)和灵雀云联合主办的首届云原生技术实践峰会正式召开,灵雀云创始人兼CTO陈恺在会上发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、云原生机器学习赋能平台Alauda Machine ...查看全部

近日由云原生技术实践联盟(CNBPA)和灵雀云联合主办的首届云原生技术实践峰会正式召开,灵雀云创始人兼CTO陈恺在会上发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、云原生机器学习赋能平台Alauda Machine Learning(AML)和企业级容器PaaS平台Alauda Cloud Enterprise(ACE)三大产品。

pic1.jpg


灵雀云创始人兼CTO 陈恺
灵雀云成立于2014年, 是一家专注于容器服务和企业级PaaS的云服务商,在西雅图和北京都设有研发中心,其CEO左玥、CTO陈恺均出自原微软Azure云平台的核心创始团队,公司75%以上的后端开发工程师均拥有Kubernetes代码级的熟练掌握能力。
灵雀云于2017年11月获得由腾讯云战略领投,高榕资本、宽带资本跟投的超亿元人民币B轮融资;2018年5月又获得由英特尔投资领投,明照资本等战略投资人跟投的新一轮融资,是目前国内容器PaaS领域融资轮次最高、估值最高、总融资额最大的IT服务企业,客户覆盖了银行、证券、保险、运营商、制造、能源、航空、汽车等领域的诸多五百强企业。
2018年:云计算的后Kubernetes时代
“自Kubernetes在2017年底成为容器编排标准以来,其对技术社区和行业的影响力正在迅速爆发,2018年云计算已进入后Kubernetes时代。”陈恺在题为《云原生助力企业持续创新》的演讲中提到:“未来,Kubernetes或将向下管理所有基础设施,向上支撑所有应用,成为真正意义上的‘云操作系统’以及新一代的‘应用服务器’,Kubernetes还有可能成为绝大多数应用的唯一交互方式。”
陈恺坦言,因Kubernetes扩展机制的灵活性,越来越多的开发者将Kubernetes作为开发框架使用,去扩展Kubernetes的功能,通过Kubernetes提供与容器编排并不相关的各种服务,技术社区中流行的各种花式玩法,甚至远远超出了Kubernetes设计者的预料之外。
云原生的概念在早期非常小众,在云原生技术实践联盟(CNBPA)的推动下,2018年进入云原生的爆发期,开发交互方式正在向云原生的方向改变,云原生的概念迎来了实际的落脚点。
未来传统企业将逐渐演变成软件公司,但是只在商业模式中包含软件,并不能带来竞争力的优势,而云原生能够最大化释放云计算生产力的应用设计、开发、交付和管理方式,其容器化、动态调度和快速交付的特点能够快速将价值传递给客户,这是传统企业关注云原生技术的根本原因。

pic2.jpg


ACP:一站式云原生应用赋能平台
云原生由容器、DevOps 和微服务为代表的敏捷基础架构组成,灵雀云本次发布的一站式云原生应用赋能平台(Alauda Container Platform,ACP),包括Alauda Kubernetes、ACP DevOps和ACP Service Framework三大标准化产品,是灵雀云云原生技术经过实践沉淀出的全新产品套件,实现了对云原生三大领域的完整覆盖。

Alauda Kubernetes是灵雀云提供的企业级Kubernetes发行版,据介绍,该版本在过去两年里已被100余家企业客户运用在生产环境当中,并通过了CNCF官方一致性认证,支持一键安装和升级,用户体系可以灵活打通,权限和决策参照了企业中实际的使用习惯,从网络到存储皆可开箱即用,针对运维人员提供从监控到日志的完整解决方案。
在DevOps方面,灵雀云在2017年提供了支持CICD流水线和容器流水线能力的版本,受客户使用工具和流程的需求驱动,本次发布的ACP DevOps采用开放式工具链的集成和编排,实现了对生态合作伙伴解决方案的完整集成,让企业客户感觉是一个整体,贯穿应用的全生命周期管理。

ACP本身也是依托于DevOps开发,陈恺在现场进行了用例演示,从现场演示可以看出,运用ACP DevOps,开发者进行代码开发,会激发一条流水线跑单元测试和自动化测试,之后在预发布的环境中跑更完整的测试,全部通过后工程师会正式推入到生产环境,发布成功后机器人将自动推送消息。客户可以在生产环境中无限次的模仿真实用户的行为,产生大量监控数据,通过监控指标分析对比各应用版本之间的质量,有问题系统会自动报警,最后企业选择哪一版本发布就变成了纯业务的决定,由于前期的反复测试,大大降低了正式版本发布流程的工作量。
ACP Service Framework是基于微服务的治理平台,已帮助诸多大型企业客户实现微服务落地。ASF平台全面集成了 SpringCloud框架,用户可以在ASF平台上一键创建微服务环境,只需将环境分配给每个项目,项目里的开发人员就有了API网关、服务注册、发现、配置中心、熔断监控、全链路追踪等完整的微服务治理功能。
AML:云原生机器学习赋能平台
“近两年,在Kubernetes集群上做机器学习和深度学习的客户越来越多,未来,采用算法模型的应用将像使用数据库一样常见。”陈恺提到。云原生机器学习赋能平台Alauda Machine Learning(AML)是灵雀云用云原生的思想落地机器学习工程化的最佳实践,该平台集成了数据科学家的常用工具,可以用AML创建分布式的环境并方便地展开实验。AML可与ACP联动,实现从模型的开发、训练、验证、发布到再训练的整个流程自动化,也可将ACP用于模型发布时的测试,陈恺希望通过AML与ACP等产品线的集成,最终实现模型持续训练、优化、验证的完整闭环。

pic3.jpg


ACE:企业级容器PaaS平台
最后发布的产品是Alauda EE的2.0升级版——企业级容器PaaS平台Alauda Cloud Enterprise(ACE),ACE包含了ACP的所有功能,支持多集群、多租户,并进行了大量的生态集成。
ACE的第一个特性是多集群,除了支持默认的Kubernetes集群,用户还可以自己导入集群,或使用第三方厂商的集群,例如将腾讯、微软的软件集成到用户的PaaS平台上来;ACE跨集群的部署和管理方式,能帮助金融客户实现两地三中心的管理。
ACE的第二个特性是多租户,ACE的大多数客户均来自大企业的平台部门,他们运用ACE为整个企业提供完整的PaaS平台,灵雀云在租户模型的灵活性方面有着相当大的优势。
ACE的第三个特性是生态集成,从产品的设计理念来看,陈恺表示客户可以很容易的替换成灵雀云生态当中的其他合作伙伴,不会被某一云厂商锁定。
灵雀云的产品演进方向 满足各类上云需求
从以上三大产品的发布可以看出,灵雀云的产品演进方向十分明确,ACE主要支持大客户搭建统一的PaaS平台,用于支持各类基础设施、内外部环境以及更多相对复杂的场景。而ACP和ACE的设计目标不同,其功能更通用、更简单,灵雀云希望总结从头部客户中积累下来的经验,将那些通用的提炼出来,变成高度标准化的产品交付给更广阔的市场,从而满足中小企业的云化需求。从集成的角度来看,ACP很容易被其他系统集成,ACE很容易集成其他系统,二者从产品的角度来看是一个互补。大客户可以用ACE作为底座去集成灵雀云生态合作伙伴的各类解决方案,而中小客户可以让ACP独立的集成到其他各个合作伙伴的生态中去,而其他相应功能也将按照这一思路逐渐在平台上实现产品化。

传统业务迁移需求会逐渐转向云原生
““传统企业做数字化转型,不仅需要软件,更要具备软件快速交付能力,能够自给自足开发软件。云原生、DevOps、微服务等理念,都是围绕着这一目标去实现的。”



灵雀云提供行业容器PaaS解决方案的出发点正是基于企业的数字化转型需求。针对企业软件开发迭代慢、资源利用率低等问题,灵雀云为企业搭建统一的PaaS容器云平台,基于容器技术帮助企业取得持续的创新能力。



从目前来看,企业上云需求来自两方面,一是传统业务的迁移需求,二是云原生技术新能力的推动。陈恺表示,这两类需求会逐渐重合,而且在DevOps、容器化编排、微服务这些领域的需求已然重合,传统业务迁移需求会逐渐转向云原生。

火热的云原生到底是什么?一文了解云原生四要素!

阿娇 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-30 18:33 • 来自相关话题

所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
#云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
1.jpg

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
##云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
2.jpg

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
##云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
3.jpg

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
* 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
#云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
4.jpg

##持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
5.jpg

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
6.jpg

蓝绿(Blue-Green)部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
##微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
7.jpg

Going Agile - Breaking the monolith Conway's Law and Microservices

这样按照组织架构划分的优势在于:

  1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
  2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

  1. 有HA(High Available)的需求需要微服务。
  2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
  3. 经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
##容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
8.jpg

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
9.jpg

容器生态图

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
##DevOps——以终为始,运维合一

10.png

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
#总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

云原生之下的Java

尼古拉斯 发表了文章 • 0 个评论 • 188 次浏览 • 2019-05-30 10:22 • 来自相关话题

自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

为什么 Service Meshes,容器编排工具是云原生部署的必然选择?

samzhang 发表了文章 • 0 个评论 • 563 次浏览 • 2019-03-11 09:31 • 来自相关话题

【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝 ...查看全部
【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。

独立,短暂的微服务过程带来了一些重大好处,但是保持跟踪每一个单独的微服务是一个挑战,特别是尝试去弄清楚当一个微服务下线后,剩下的服务会受到什么样的影响。最终的结果是,如果你正在一个微服务架构下运营或开发,那么你的一部分时间将会被消耗在搞清楚你的服务到底是什么上。

随着微服务的采用,大型系统中存在大量服务,因此出现问题不可避免。诸如,安全,负载均衡,监控和限速这些问题,过去不得不同意解决,而现在,不得不单独为每个服务一一解决。

幸好工程师乐于这样的挑战。而且每当微服务产生新的问题时,他们都会通过新兴的微服务工具和技术来定位这些问题。也许微服务的出现只是工程师确保饭碗的智能游戏。

如今Cloud Native的宠儿Kubernetes,缓解了微服务带来的许多挑战。自动调度,横向扩展和服务发现,解决了大多在微服务中构建和部署服务将遇到的问题。

Kubernetes 留下了一些尚未解决的容器化应用环境的问题。这就是 Service Mesh 的介入点。让我们看一下 Kubernetes 提供了什么,和 Istio 如何增强 Kubernetes 解决微服务运行环境的问题。
#Kubernetes 解决了构建和部署的挑战
容器编排工具,诸如 Kubernetes,解决了许多来自于容器化应用的构建和部署的挑战。

Kubernetes 支持微服务架构,使开发者能够抽象出一组 Pod 的功能,并且通过明确的 API 来曝露服务给其他开发者。Kubernetes 支持四层负载均衡,但是不能解决更高层的问题,例如,七层指标、流量分流、限速和断路。
#Service Mesh 解决了运行时管理流量的挑战
Service Mesh 有助于解决最终用户使用应用程序时出现的许多挑战。能够监控哪些服务相互通信,他们的通信是否安全和是否能够控制你的集群中服务和服务间的通信,这是确保你的应用安全和弹性运行的关键。

通过在整个过程中生成统一的度量标准,Istio 可以在微服务架构中提供一致的视图。它消除了协调各种运行时代理发出的不同类型的度量标准的需要,或添加任意代理来收集旧的未检测应用程序的度量标准。它在您的多语言服务和集群中增加了一定程度的可观察性,这在任何其他工具的细粒度水平上是无法实现的。

Istio 还增加了更深层次的安全性。Kubernetes 仅提供基本的秘密分发和控制平面证书管理,但是 Istio 提供 mTLS 功能,因此您可以对线路流量进行加密,以确保您的服务间通信是安全的。
#完美的匹配
将 Kubernetes 与 Istio 配对可以为您提供两全其美的优势,而且由于 Istio 是在 Kubernetes 上运行的,因此两者可以无缝协作。您可以使用 Kubernetes 来管理所有构建和部署需求,Istio 负责处理重要的运行时问题。

Kubernetes 已经成熟到大多数企业都将其用于集装箱编排。目前,有 74 家 CNCF 认证的服务提供商,这证明了市场规模庞大且不断增长。我认为 Istio 是 Kubernetes 的延伸,为了解决更多挑战。

Istio 已经快速成熟,并开始在企业中更多地采用。可能在 2019 年,我们将看到 Istio 成为企业的服务网格标准,就像 Kubernetes 作为集装箱编排的标准一样。

原文链接:Why Service Meshes, Orchestrators Are Do or Die for Cloud Native Deployments(翻译:Sam)

云原生DevOps工程师的角色和职责

dummy 发表了文章 • 0 个评论 • 805 次浏览 • 2019-01-15 21:26 • 来自相关话题

云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基 ...查看全部
云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基础包含有四个主要概念:微服务、容器、CI/CD和DevOps。

微服务是一种将应用程序开发为一系列小型专用服务的方法,这些服务组合在一起形成一个完整的产品。这些功能被打包到像Docker这样的容器中,然后通过持续集成/持续部署管道进行推送。微服务的模块化使不同的团队能够在产品的不同部分上并行工作而不会相互干扰,并且还通过减少任何这些服务的失败对其他服务的影响来增强产品。

使用容器来托管微服务是非常有效的,因为容器比传统虚拟机更有效地使用系统资源。它们只需要运行与它们托管的应用程序相关的服务,而不是整个客户操作系统及其相应的进程。容器对于云原生应用程序的敏捷部署至关重要,尤其是与Kubernetes等管理软件配合使用时。所有这些都是使CI/CD成为可能的基础。如果没有这些工具提供的灵活性,那么这些允许更改,修复或将功能推到生产环境,从开发到自动代码审查和测试的CI流程将非常困难。

DevOps使用所有这些乃至其他更多工具来解决所谓孤岛问题,就是当开发人员编写代码然后将其扔到Ops部门时会发生什么。开发人员从头到尾不拥有他们的代码的结果就是,Ops部门经常需要负责维护未考虑基础架构的代码。这里的解决方案不仅仅是创建出第三个结合开发和运维角色的闭塞的环境。

DevOps不仅仅是一个流程或工作岗位,它更是一种所有权文化。



DevOps工程师试图培养“谁开发谁维护”的理念,这意味着他们需要从软件开发过程一开始就评估可能困扰应用程序生产的瓶颈。云原生DevOps工程师需要能够通过CI/CD流程获取应用程序,以确保代码可以构建,通过测试并在不破坏生产环境的情况下进行部署。这因此激励他们思考应用程序在创建之前的运行方式,并编写脚本来创建持续的集成管道,以确保产品的上市时间更快,用户体验更好。

最优秀的DevOps工程师将能够使用或学习各种开源技术,并且熟悉大量用于编写脚本的编程语言。他们在IT系统,操作和数据管理方面拥有一些经验,能够将这些知识集成到CI/CD开发模型中。至关重要的是,DevOps工程师不仅需要编写代码,还要考虑他们开发的产品的实际业务成果。像这样的全局思考还需要强大的软技能,以实现跨团队以及客户和技术团队之间的沟通。

当然,没有谁是一座孤岛。DevOps团队虽然在同一个组织覆盖下运作,但是需要各类不同的角色才能胜任。这些团队成员的实际头衔可能会因地而异,但一般职责仍然相同:

  • 产品负责人(负责团队的工作):此人担任客户团队联络人。他们需要特别强大的软技能和有效沟通技术概念的能力,以便与客户合作,提出满足期望的产品。他们了解全局,可以告诉团队应该如何运行应用程序以及使用什么基础架构。
  • 团队领导(负责团队的工作方式):此人是技术团队的管理类型角色。他们根据团队成员的个人优势和技能集来委派职责。他们也贡献代码,但是在短期发展冲刺背景下,他们使团队与产品所有者的全局观保持一致。他们通常对技术决策有最终决定权。
  • 自动化架构师/站点可靠性工程师(SRE):此人在构建云基础架构方面经验丰富,并了解在生产中支持应用程序所需的内容。他们开发自动化系统,以确保持续部署顺利运行。他们专注于确保基础架构在大规模环境中的稳定性能,并了解如何随着公司的发展扩展基础架构。
  • 软件开发人员:软件开发人员将与之前列出的所有团队成员一起工作,并根据客户的要求创造出代码,然后进行测试,部署和监控。

随着团队的发展,这些角色可能会分成几个其他更细粒度的职位,以便利用增加的人力资源。UX工程师,测试工程师和安全工程师就是一些例子,它们会从列出的其他一些人那里承担重要的责任并对其进行扩展。

原文链接:Roles and Responsibilities of Cloud Native DevOps Engineers(翻译:fengxsong)

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 855 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

微服务浪潮中,程序猿如何让自己 Be Cloud Native

李颖杰 发表了文章 • 0 个评论 • 649 次浏览 • 2018-12-26 10:08 • 来自相关话题

# 前言 CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等 ...查看全部
# 前言
CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等于我们自己的软件就已经是 Cloud Native,在使用哑铃和成为肌肉男之间还隔着科学使用和自律锻炼两道工序;在此,笔者想根跟大家聊聊让我们的应用真正变得 Cloud Native 时的理论依据:微服务的十二要素。这篇文章也是先从作者自身项目的角度(一个基于 EDAS 的微服务架构),来阐述对这十二条要素的前两条 —— 仓库(Code Base)与依赖(Dependency)的理解。

Code Base 的原文释义是:"一份基准代码,多份部署,基准代码和应用之间总是保持一一对应的关系;不同环境中的相同应用,应该来源于同一份代码"。我的理解有两个:

  1. 一个应用,产生自同一个仓库。
  2. 一个仓库,只产生一个应用。

为什么推演出这么两个结论呢?让我们先看一个实际的项目。
# 为什么是一个应用?
给大家举一个一个仓库包含多个应用的反例,笔者自己的一个项目是一个微服务架构,和大部分的微服务架构一样,一开始是由一个单体的应用拆解而来,拆解之后,大致简化成四个服务:微服务网关(Gateway),两个后台服务(UserService, OrderService),后台管理控制台服务(Admin),简单的架构示意图如下:
arch.png

在拆分的过程一开始为了项目上线减少风险,将拆分之后的应用都放在了一个 Git 仓库中进行管理,同时也共用了同一个库。重构之后仓库的目录如下:
~/workspace/java/app/ $ tree -L 2
.
├── README.md
├── service-api # 通用的 API 接口定义
│ ├── userservice-api # 服务 UserService 的声明
│ ├── orderservice-api # 服务 OrderService 的声明
│ ├── rpc-api # 远程服务调用相关的接口声明
│ ├── common-api # UserService 与 OrderService 都依赖的声明
| .....
├── service-impl # 对应 API 的相关具体业务实现
│ ├── userservice-impl
│ ├── orderservice-impl
│ ├── common-impl
| .....
├── web-app # Web 应用工程
│ ├── admin
│ ├── userservice
│ ├── orderservice
│ ├── gateway

一开始这些服务之间的发布和改动彼此都不受影响,这一过程持续了大约两个迭代,随着迭代的不断进行和新人的加入,后来我们线上发现一个很奇怪的现象,每次用户进入刷新订单的地址列表的时候,会伴随这一次用户 Token 的刷新而导致用户被踢出,线上的排查过程在 EDAS 的分布式链路跟踪系统 EagleEye 的帮助下,马上就定位到了出问题的代码:
java
// User Service 中
public class User {
public void refresh() {
// 刷新登录 token
}
}

// Order Service 中
public class OrderUser extends User {
// 函数少了一个字母,导致 refresh 调用了父类的 refresh
public void refesh() {
// 刷新地址列表
}
}

​这个故障,我先邀请大家一起思考一下几个问题:

  1. 从编码角度,如何避免上述重写的方法因为名字误写造成故障?
  2. 从设计角度,OrderUser 和 User,是否是继承关系?
  3. 这个问题的根因是什么?

以上的几个问题中,第一个问题的答案,很多同学都知道,就是使用 Java 自带的 Annotation `@Override`,他会自动强制去检查所修饰的方法签名在父子类中是否一致。第二个问题,需要从领域边界来说,这是一个典型的边界划分的问题,即:订单中的用户,和会员登录中的用户,是不是相同的“用户”?会员中的用户,其实只需要关心用户名密码,其他都是这个用户的属性;而订单中的用户,最重要的肯定是联系方式,即一个联系方式,确定一个人。虽然他们都叫做用户,但是在彼此的上下文中,肯定是不一样的概念。所以这里的 `OrderUser` 和 `User` 是不能用继承关系的,因为他们就不是一个 "IS A" 的关系。

仓库共享,加上没有多加思考的模型,导致依赖混乱;如果两个 `User` 对象之间代码上能做到隔离,不是那么轻易的产生“关系”,这一切或许可以避免。
# 为什么是一个仓库?
严格意义上说,一个应用的所有代码都肯定来源于不同的仓库?我们所依赖的三方库如(fastjson,edas-sdk 等)肯定是来源于其他的仓库;这些类库是有确切的名称和版本号,且已经构建好的"制品",这里所说的一个仓库,是指源码级别的“在制品”。可能在很多的项目中不会存在这样的情况,以 Git 为例,他一般发生在 Submodule 为组织结构的工程中,场景一般是啥呢?在我们这个工程中确实是有一个这样的例子:

为了解掉第一个问题,我们决定拆仓库,仓库的粒度按照应用粒度分,同时把 common 相关的都拆到一个叫做 common 仓库中去;业务服务都好说,这里特殊处理的是 admin 应用,admin 是一个后台管理应用,变化频度特别大,需要依赖 UserService 和 OrderService 一大堆的接口。关于和其他仓库接口依赖的处理,这里除了常见的 Maven 依赖方式之外,还有另外一个解决方案就是 git submodule,关于两个方案的对比,我简单罗列在了下表之中:
B.png

我觉得如果这个项目组只有一两个人的时候,不会带来协作的问题;上面的方案随便哪一个都是不需要花太多时间做特殊讨论,挑自己最熟悉最拿手的方案肯定不会有错,所谓小团队靠技术吗,说的就是这么个道理;我们当时是一个小团队,同时团队中也有同学对 Submodule 处理过类似的情况,所以方案的选择上就很自然了。

后来随着时间的推移,团队慢慢变大,就发现需要制定一些流程和和规范来约束一些行为,以此保障团队的协作关系的时候;这时候发现之前靠一己之力打拼下来的地盘在多人写作下变得脆弱不堪,尤其是另外一个 Submodule 变成一个团队进行维护的时候,Submodule 的版本管理几乎不可预期,而且他的接口变动和改动是完全不会理会被依赖方的感受的,因为他也不知道是否被依赖;久而久之,你就会明白什么叫做你的项目被腐化了。简单理解腐化这个词就是,你已经开始害怕你所做的一切改动,因为你不知道你的改动是否会引来额外的麻烦。从这个角度也可以去理解为什么一门语言设计出来为什么要有 privatepublic这些表示范围的修饰词。正因为有这些词的存在,才让你的业务代码的高内聚成为的有可能,小到设计一个方法一个类、再引申到一个接口一个服务、再到一个系统一个仓库,这个原则始终不变。

上述问题带来的解法很简单,就是变成显示依赖的关系,所谓显示依赖是指的两个依赖之间是确定的。什么是确定的?确定 == No Supprise !对,不管什么时候,线上还是线下,我依赖你测试环境的接口返回是一个整数,到了线上,返回的也必须是一个整数、不能变成浮点数。而让确定性变得可行的,不是君子协定;只能是一个版本依赖工具。比如说 Java 中的 Maven 正式的版本依赖。
# 结语
职责内聚、依赖确定,是我们的应用变得真正 Cloud Native 的前提。没有了这些基本的内功,懂的开源软件再多、对微服务栈再熟悉,也会有各种意想不到的事情出来,试想一下,如果应用的职责到处分散,那到时候扩容到底扩谁呢?如果依赖方变得及其不确定,谁又来为每次发版的不确定的成本买单?Be Cloud Native,请从应用代码托管的住所开始。

作者:阿里巴巴高级技术专家 孤弋

超越Kubernetes:值得关注的5大云原生技术

ScofieldDM 发表了文章 • 0 个评论 • 3345 次浏览 • 2018-09-07 20:03 • 来自相关话题

【编者的话】随着Kubernetes的出现,容器化技术和服务网格等各种技术已经飞速发展,其中有些平台目前发展迅速,下列几种云原生技术是值得我们持续关注的。 Kubernetes是一个开源容器管理平台,它现在已经成为了云原生的中流砥柱。 ...查看全部
【编者的话】随着Kubernetes的出现,容器化技术和服务网格等各种技术已经飞速发展,其中有些平台目前发展迅速,下列几种云原生技术是值得我们持续关注的。

Kubernetes是一个开源容器管理平台,它现在已经成为了云原生的中流砥柱。自从把它移交给Cloud Native Compute Foundation(云原生计算基金)后,该项目在业界上取得了史无前例的关注,目前没有一个公有云环境不提供Kubernetes托管服务。

Kubernetes正迅速成为现代容器化应用运行的管理平台。

随着Kubernetes的崛起,它带来了一个全新的生态系统的形成。目前有各种各样的ISV和SaaS提供商为构建云原生环境提供了构建工具。这个蓬勃的生态可以和当时微软和VMware在Windows和VSphere鼎盛时代相媲美。但他们最大的区别就是云原生的产品大多数都是开源的,但在云上提供一个可用的商业版本。

下面是业界五个值得关注的开源项目,这些项目在Kubernetes的基础上进行大幅度扩展,使得其成为运行Web规模和企业应用的强大平台。
# 1. Istio
在Kubernetes之后,Istio是最受欢迎的云原生技术。它就是一种服务网格,能够安全的连接一个应用程序之间的多个微服务。你也可以将它视为内部和外部的负载均衡器,具有策略驱动的防火墙,支持各种全面指标。开发者和使用者倾向于Istio的原因是因为它具有无侵入式的部署模式,而且任何Kubernetes的服务都能够在不需要改动代码和配置的情况下和Istio进行无缝连接。

Google最近宣布在GCP上管理Istio服务,除此之外IBM,Pivotal,Red Hat,Tigera和Weaveworkds都是支持这个项目的活跃贡献者。

Istio为ISV提供了向企业提供定制化解决方案和工具的绝佳机会,这个项目有望成为建设云原生平台的项目,我希望每一个托管Kubernetes服务的平台都能够都能够托管Istio服务。
# 2. Prometheus
Prometheus是一个部署在Kubernetes上用于观察工作负载的云原生监控工具。它通过全面的指标和丰富的DashBoard填补了云原生世界中存在的重要空白。在Kubernetes之后,它是唯一从云原生计算基金中毕业的项目。Prometheus通过聚合可通过集中式DashBoard的指标来填充Istio的空白。从核心指标中可以反映Kubernetes集群中特殊应用的指标的健康状态,可以说它几乎可以监控到一切。它整合了像Grafana这样主流的数据可视化工具,Kubernetes接下来推出的有关于扩展和监控的功能都依赖于Prometheus,这使得它成为云原生平台建设中的不可或缺的一项。
# 3. Helm
如果说Kubernetes是新型的操作系统的话,Helm 就是应用程序安装程序。根据Debian安装包和Red Hat Linux RMPS设计,Helm通过执行单个命令,提供了更简洁和更强大的部署云原生工作负载能力。

Kubernetes应用暴露了大量的像deployments(部署),services(服务),ingress controllers(入口控制器),persistant volumes(持久化挂载目录)等更多的元素。Helm则通过提供统一安装工具,将云原生应用程序所有依赖关系聚合到称之为图表的部署单元中。

由于被CNCF进行管理,Helm项目的积极参与者目前有Bitnami,Google,Microsoft,CodeFresh和Ticketmaster。Helm正朝着成为真正意义上的云原生应用程序安装程序。
# 4. Spinnaker
云原生技术最值得关注之一的是软件的交付速度。Spinnaker是一个最初在Netflix上构建的开源项目,它实现了这一承诺。Spinnaker是一个版本管理工具,它是一种发布管理工具,可以为部署云原生应用程序提高速度。通过对比传统的IaaS环境(像Amazon EC2和当代运行在Kubernetes上的CaaS平台),无缝填补了传统虚拟机和容器之间的空白。其多云功能使得其成为跨不同云平台部署应用程序的理想平台。

Spinnaker可作为当前所有主流的云环境自托管平台,像Armory这样的初创公司目前正在提供SLA下的商业级,企业级Spinnaker。
# 5. KubeLess
事件驱动计算目前已成为当代应用程序结构不可或缺的一部分。功能即服务(FaaS)是当前无服务计算交付模型之一,它通过基于事件的调用来填补容器。现代的应用程序会被当做服务并打包成容器或者是作为方法运行在相同的环境下,随着Kubernetes成为云原生计算的首选平台,运行功能时必须在容器中进行。

在云原生生态系统中,来自于Bitnami的Kubeless项目是当前最流行的无服务项目。它与AWS lambda的兼容性与对主流语言的支持使得它成为理想的选择。

CNCF目前还没有将无服务项目纳入其中,到目前为止最近接的是通过CloudEvent——用一种平常的方法来描述事件数据的规范,如果Kubeless成为CNCF中的一个项目的话,它将会十分有意思。

随着企业开始接受新的范例,一系列支撑当代云原生应用,云原生工作负载的工具和平台也不断快速的演进。

Janakiram MSV是Janakiram & Associates的分析师,高级指导顾问和架构师。

你可以在TwitterFaceBookLinkedIn上关注他。

原文链接:Beyond Kubernetes - 5 Promising Cloud-Native Technologies To Watch(翻译:刘明)

云原生应用的10大关键属性

cleverlzc 发表了文章 • 0 个评论 • 1250 次浏览 • 2018-08-12 10:12 • 来自相关话题

【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。 云原生是一个用于描述基于容器环境的术语。云原生技术用于 ...查看全部
【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。

云原生是一个用于描述基于容器环境的术语。云原生技术用于开发构建应用程序,这些应用程序使用容器打包并且将被部署为微服务,通过敏捷DevOps流程和持续交付工作流,在弹性基础设施上进行管理。

运维团队将手工管理传统应用程序的基础设施资源分配,而云原生应用程序部署在抽象底层计算、存储和网络原语的基础设施上。处理这种新型应用程序的开发人员和运维人员不会直接与基础设施提供者公开的应用程序编程接口(API)交互。相反,编排引擎根据DevOps团队制定的策略自动处理资源分配。控制器和调度器是编制引擎的重要组件,它们处理资源分配和应用程序的生命周期。

像Kubernetes这样的云原生平台暴露了一个扁平网络,该网络覆盖在云提供商的现有网络拓扑和原语上。类似地,通常抽象本地存储层以暴露与容器集成的逻辑卷。运维人员可以分配开发人员和资源管理员访问的存储配额和网络策略。基础架构的抽象不仅解决了跨云环境的可移植性需求,还让开发人员利用新兴模式来构建和部署应用程序。无论基于物理服务器或虚拟机,私有云还是公共云的底层基础架构,业务流程管理器都将成为部署目标。

Kubernetes是当代运行云原生应用程序的工作负载的理想平台。它已经成为云的事实上的操作系统,就像Linux是底层机器的操作系统一样。只要开发人员遵循设计和开发软件作为一组包含云原生应用程序的微服务的最佳实践,DevOps团队就能够在Kubernetes中打包和部署它们。以下是开发人员在设计云原生应用程序时应牢记的云原生应用程序的10个关键属性。


  • 1、打包为轻量级容器:云原生应用程序是打包为轻量级容器的独立自治服务的集合。与虚拟机不同,容器可以快速扩展和缩容。由于扩展单元转移到容器,因此优化了基础架构的利用率。
  • 2、使用最佳语言和框架开发:云原生应用程序的每项服务都是使用最适合该功能的语言和框架开发的。云原生应用程序是多语言的;服务使用各种语言、运行时和框架。例如,开发人员可以构建基于在Node.js中开发的WebSockets的实时流服务,同时选择Python和Flask来公开API。开发微服务的细粒度方法使他们能够为特定工作选择最佳语言和框架。
  • 3、设计为松耦合的微服务:属于同一应用程序的服务通过应用程序运行时相互发现。它们独立于其他服务而存在。当正确集成时,弹性基础架构和应用程序架构可以高效和高性能地进行扩展。
松耦合的服务允许开发人员独立地处理每个服务。通过这种解耦,开发人员可以专注于每项服务的核心功能,以交付细粒度的功能。这种方法可以实现整个应用程序的有效生命周期管理,因为每个服务都是独立维护的,并且拥有明确的所有权。
  • 4、以API为中心进行交互和协作:云原生服务使用轻量级API,这些API基于表述性状态转移(REST)、Google的开源远程过程调用(gRPC)或NATS等协议。REST被用作通过超文本传输协议(HTTP)公开API的基本共识。为了提高性能,gRPC通常用于服务之间的内部通信。NATS具有发布-订阅功能,可在应用程序内实现异步通信。
  • 5、以无状态和有状态服务的清晰分离为架构基础:持久可靠的服务遵循不同的模式,以确保更高的可用性和弹性。无状态服务独立于有状态服务。持久性成为一个必须越来越多地考虑因素,无状态和一些人会争论的微服务存储环境的因素。
  • 6、与服务器和操作系统依赖关系隔离:云原生应用程序与任何特定操作系统或单个计算机没有关联。它们在更高的抽象级别上运行。唯一的例外是微服务需要某些功能,包括固态驱动器(SSD)和图形处理单元(GPU),这些功能可能由一部分机器专门提供。
  • 7、部署在自服务、弹性、云基础架构上:云原生应用程序部署在虚拟的、共享的和弹性的基础架构上。它们可以与底层基础架构保持一致,以动态增长和缩小-根据不同的负载调整自身。
  • 8、通过敏捷DevOps流程进行管理:云原生应用程序的每项服务都经历一个独立的生命周期,它们通过敏捷的DevOps流程进行管理。多个持续集成/连续交付(CI/CD)流水线可以协同工作以部署和管理云原生应用程序。
  • 9、自动化功能:云原生应用程序可以高度自动化。它们与基础设施即代码的概念相得益彰。实际上,仅需要一定程度的自动化来管理这些大型和复杂的应用程序。
  • 10、定义的、策略驱动的资源分配:最后,云原生应用程序与通过一组策略定义的治理模型保持一致。它们遵循诸如中央处理单元(CPU)和存储配额以及将资源分配给服务的网络策略等策略。例如,在企业方案中,中央IT可以定义策略以为每个部门分配资源。每个部门的开发人员和DevOps团队都拥有对共享资源的完全访问权和所有权。

原文地址:10 KEY ATTRIBUTES OF CLOUD-NATIVE APPLICATIONS (翻译:刘志超)

Cloud Native 世界顶级开源项目

尼古拉斯 发表了文章 • 0 个评论 • 1858 次浏览 • 2018-04-19 09:46 • 来自相关话题

#CNCF 是什么? CNCF 是一个开源软件基金会,致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务,将每个部分打包到自己的容器中,并动态编排这些容器以优化资源利用率。 云原生技术使软件开发人员能够更快 ...查看全部
#CNCF 是什么?
CNCF 是一个开源软件基金会,致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务,将每个部分打包到自己的容器中,并动态编排这些容器以优化资源利用率。 云原生技术使软件开发人员能够更快地构建出色的产品。
#CNCF 项目成员
##Kubernetes
kubernetes.png

Kubernetes 是世界上最受欢迎的容器编排平台和第一个 CNCF 项目。Kubernetes 帮助用户构建、扩展和管理应用程序及其动态生命周期。Kubernetes 最初是在谷歌开发的,现在有超过 2,300 名贡献者,并且被世界上许多行业中一些具有创新性的公司所使用。 集群调度功能可让开发人员构建云原生应用,更加关注代码而不是操作。 Kubernetes 面向未来的应用程序开发和基础设施管理可在本地或云端进行,无需供应商或云提供商绑定。
##Prometheus
promethues.png

Prometheus 为云原生应用程序提供实时监控、警报和时间序列数据库功能(包括强大的查询和可视化能力),并与许多流行的开源数据导入、导出工具集成。 它已经成为监控基于容器的基础设施的标准,并且随着用户需求的而不断添加主要功能。 Prometheus为云原生体系结构(包括 Kubernetes 和其他下一代组件)提供了所需的可见性和故障排除。
###OpenTracing
opentracing.png

Tracing 是基于微服务环境的关键部分,用于追踪跨服务请求的行为。OpenTracing 是一种分布式追踪 API,可用于各种流行的开源的和商业的追踪工具。OpenTracing API 使微服务交互监控成为可能,使用 Jaeger、Zipkin、DataDog 等流行工具进行切换。 它是 LightStep、Red Hat、Uber和其他公司的工程师们努力的产物,它为开发人员提供了一种即使在异构环境中也能精确跟踪的简单工具。
##Fluentd
fluentd.png

Fluentd 是一个统一的日志记录工具,可收集来自任何数据源(包括数据库、应用程序服务器、最终用户设备)的数据,并与众多警报、分析和存储工具配合使用。 Fluentd 通过提供一个统一的层来帮助用户更好地了解他们的环境中发生的事情,以便收集、过滤日志数据并将其路由到许多流行的源和目的地。 Fluentd 通过提供统一的平台来收集、构建(如果可能的话,使用JSON)并导出数据,从而使日志分析更加轻松。 它采用可插拔架构,通过统一的平台和可插拔架构,简化了新数据源(例如连接设备)和后端系统(例如云存储和数据库)的上线,并集成到 Atlassian 、 微软等软件提供商。
##gRPC
gRPC.png

gRPC 是由 Google 开发的高性能 RPC(远程过程调用)框架,针对连接跨语言、云和数据中心的服务以及将移动设备连接到后端的云原生计算环境的大规模、多平台性质进行了服务优化。 gRPC 支持 10 种流行语言,并被全球一些领先的企业、技术供应商和大学所使用。 gRPC改善了分布式计算环境中远程调用的延迟性,同时支持多语言编程,并包括 iOS 和 Android 的客户端库以及后端服务器。
##Containerd
containerd.png

Containerd 是由 Docker 开发并基于 Docker Engine 运行时的行业标准容器运行时组件。 作为容器生态系统的选择,Containerd 通过提供运行时,可以将 Docker 和 OCI 容器镜像作为新平台或产品的一部分进行管理。Containerd 旨在直接集成到第三方软件产品和项目(例如Kubernetes)中,提供围绕容器生命周期的基础功能。 它为许多基础容器生命周期流程提供原型,使开发人员可以在更高层次上自由地进行创新。
##Rkt
Rkt.png

Rkt 是 Docker 容器引擎的一个可行的替代方案,最初由 CoreOS 创建,旨在实现最大的可组合性并管理名为 Pod 的容器集合。 Rkt 不使用守护进程来管理容器,而是直接从命令行启动容器。 它针对安全性以及与其他开源容器技术和标准的集成进行了优化。
##CNI
CNI.png

容器网络接口(CNI)项目是由一系列行业组织创建的,目的是为了在云原生环境中标准化容器的基本网络接口。 CNI 为开发人员提供了在多个容器运行时间上构建应用程序的自由,同时体验了一致的网络 API。 CNI 通过对基本功能进行标准化来推进集装箱网络的状态,例如跨公共运行时(包括Kubernetes、Rkt、Mesos 和 Cloud Foundry)添加和删除容器资源,并通过第三方插件主动支持高级网络功能。
##Envoy
envoy.png

Envoy 是最初在 Lyft 创建的 Service Mesh(服务网格),现在用于Google、Apple、Netflix等公司内部。 Envoy 是用 C++ 编写的,旨在最大限度地减少内存和 CPU 占用空间,同时提供诸如负载均衡、网络深度可观察性、微服务环境中的跟踪和数据库活动等功能。
##Jaeger
jaeger.png

Jaeger 是由 Uber 开发的分布式追踪系统,用于监控其大型微服务环境,现在已经被 Red Hat、SeatGeek 和 Under Armour 等公司收集。 Jaeger 被设计为具有高度可扩展性和可用性,并为 OpenTracing 标准和众多存储后端提供本地支持。 它具有现代 UI,旨在与云原生系统(如 OpenTracing、Kubernetes 和 Prometheus)集成。
##Notary
notray.png

Notary 最初由 Docker 创建,是 TUF(另一个CNCF项目)的实现,旨在通过强大的加密技术建立对数字内容的信任。 公证通过确保软件来自预期的来源来做到这一点,并且除了其作者以外没有任何人改变它。 它为开发人员提供了一个加密工具来验证容器及其内容的来源。
##TUF
TUF.png

更新框架(TUF)是用于保护软件更新系统免受更新或初始安装期间发生的攻击的规范。 TUF 最初由纽约大学工程学院开发,并已集成到由 Docker 和 VMware 等开发的企业软件产品中。 TUF 使用加密密钥来防止软件安装或更新期间的已知漏洞,确保用户安装他们打算安装的文件。 TUF 作为软件开发过程的一部分被集成,而不是作为独立的网络安全工具。
##Vitess
Vitess.png

Vitess 是一个用于通过广义分片对 MySQL 进行水平缩放的数据库集群系统。 通过封装分片路由逻辑,Vitess 允许应用程序代码和数据库查询对于将数据分布到多个分片上保持不变。 使用 Vitess,您甚至可以根据您的需求增长来分割和合并碎片,原子切割步骤只需几秒钟。 自 2011 年以来,Vitess 一直是 YouTube 数据库基础架构的核心组件,并且已经发展到包含数以万计的 MySQL 节点。它的架构可以像在专用硬件上一样有效地在公共或私有云架构中运行。 它结合并扩展了许多重要的 MySQL 功能和 NoSQL 数据库的可扩展性。
##CoreDNS
CoreDNS.png

CoreDNS 是针对云原生环境的性能、灵活性和服务发现要求而优化的 DNS 服务器。 CoreDNS 是用 Go 编写的 SkyDNS 的后继者。 它包括各种功能,包括通过 Prometheus 进行 Kubernetes 支持和监控,并强调插件增加新功能或编译简化实施。 DNS 是基于云原生或基于微服务的体系结构的重要组成部分,可以包括数百或数千个单独的服务、容器和其他端点。 CoreDNS 旨在支持这些体系结构,以及在需求成熟时轻松支持新功能。
##Nats
Nats.png

NATS Server 是一个简单、高性能的开源消息系统,用于云原生应用程序、IoT 消息传递和微服务架构。 Synadia 团队的成员创建了NATS Server(用Go编写)、NATS Streaming 以及用 Python、Ruby、Node.js、Elixir、Java、NGINX、C 和 C# 编写的客户端。 该社区贡献了越来越多的库,包括Arduino、Rust、Lua、PHP、Perl等等。
##Linkerd
Linkerd.png

Linkerd 是一种基于云原生的 Service Mesh(服务网格),基于 Netty 和 Finagle 构建,是由 Twitter 构建的工具,用于管理其广阔的微服务环境,使其可以扩展到每秒数以万计的请求。 Linkerd 提供了一个独立的代理层,分布式应用程序服务通过它可以相互通信来处理任务,如负载平衡、路由和 TLS。 它通过管理微服务之间的交互来确保应用程序性能,从而帮助简化向云原生体系结构的转换和操作。

原文链接:https://anoyi.com/p/acb1587e8ccd(作者:Anoyi)

Cloud Foundry与Kubernetes的结合简史

zhanggong1110 发表了文章 • 0 个评论 • 3547 次浏览 • 2018-04-15 12:37 • 来自相关话题

【编者的话】本文翻译自IBM公司Simon Moser(STSM,Senior Technical Staff Member,IBM
 Cloud部门Cloud Foundry方向首席架构师)的一篇技术博客。在这篇博客中,Simon分享了将Cloud Foun ...查看全部
【编者的话】本文翻译自IBM公司Simon Moser(STSM,Senior Technical Staff Member,IBM
 Cloud部门Cloud Foundry方向首席架构师)的一篇技术博客。在这篇博客中,Simon分享了将Cloud Foundry与Kubernetes结合的多种技术选型的探索历程,包括可行性分析、最佳实践、经验总结和价值意义等话题,旨在最大程度上利用和发挥两者的优势,并提升开发者体验。

同时,在即将到来的Cloud Foundry Summit North America 2018(4月18日-4月20日),Simon会在现场与大家分享最新进展Demo Theater: IBM Cloud Foundry Enterprise Environment,敬请关注!

过去中几年中,在云计算领域的开源社区中最有争议的话题莫过于Cloud Foundry(CF)和Kubernetes(K8s)的关系。大家的疑问紧紧围绕着三个问题:“它们会互相取代对方吗?”,“它们是互斥的吗?” ,“还是说它们是可以融合的?”。

放眼望去在目前的商业产品中,两者几乎没什么关联——两个技术栈(stack)是分离的,都可以运行在各种IaaS之上, 几乎没有集成,就算是有也仅仅是在“Cloud Foundry和Kubernetes共享一个服务目录(Service Catalog)”这种级别,而没有更深层的系统级别集成 。

浅显的分析两者的关系并没有特别大的意义。当然了,这两种技术有一定程度的重叠,同时在一些关键领域是互相补充的——下面的表格是一个简单的总结:
Screen_Shot_2018-04-15_at_12.22_.16_PM_.png

表格1:Cloud Foundry和Kubernetes对比

“容器运行时”(Container Runtime)绝对是Cloud Foundry和Kubernetes有巨大重叠的部分,但是它在两者中分别基于不同的实现方式(尽管最终都是基于 runc/containerd实现的)。这导致了一些后果,比如Kubernetes引入了一个新的功能[比如需要容器组(Container Group)的边车(Sidecar)],Cloud Foundry也紧随其后开始实现类似的功能,反之亦然。

但另一方面,开发人员在Kubernetes的体验比较糟糕,毕竟通常Kubernetes被认为更像是“IaaS+”而不是一个“PaaS”。
BlogFigure1.png

图片1:开发者体验

但如果Kubernetes就是“IaaS+”而不是一个“PaaS”,那是不是可以将Cloud Foundry运行在Kubernetes之上?我的意思是Cloud Foundry一个核心主张就是“IaaS”无关,所以这可能是可行的?于是我们进行了一项尝试。

可能很多人已经有所了解,Cloud Foundry通常是由BOSH这个工具来负责部署和生命周期管理的。BOSH通常会负责搭建一个Cloud Foundry的环境,并且它通过CPI(Cloud Provider Interface)的机制屏蔽了底层基础设施的差异。假设您说“我想要一个虚拟机”,这时CPI会将这个请求转换成适用于不同底层基础设施提供商的API调用,比如AWS、IBM、Google或者VMWare等等。

所以我们第一个尝试就是基于这个原则,也就是编写一个支持Kubernetes的CPI。但是最初的尝试却以失败告终。


视频1:使用Kubernetes作为Cloud Foundry的IaaS

具体的细节详见上面视频中Sandy和Monika在Cloud Foundry峰会的演讲,总体可以归结为:CPI认为IaaS层是“无知的”并且CPI掌握最高控制权,但在Kubernetes的世界里并不是这样。Kubernetes是个智能的“IaaS+”,比如Cloud Foundry的一个组件崩溃了并且需要恢复,那么应该谁来负责?BOSH还是Kubernetes?答案并不是显而易见的,我们把这种情形称之为“编排者脑裂”,这也给第一次尝试判了死刑。

幸运的是,我们的合作伙伴SUSE已经开发了两个项目FissileSCF,他们采取了一种更加彻底的方式,将BOSH运行时全部移除了。显然这对Cloud Foundry的部署和运维是有一定影响的,但优点是这种方式是真正的Kubernetes原生部署方式。所以结论是:我们开始了新的尝试,做了一定的调整,尝试部署后效果很满意!如果你想要进一步了解最新进展,比如理想情况下把现有的方案最终与BOSH相集成,请参考这里 (Google doc)。

尽管如此,上面这种方式还是有一定缺陷,正如表格1所示,Cloud Foundry有一个原生的容器运行时叫Garden,Fissile将它转化成为Docker镜像的一部分,所以最终Cloud Foundry的App是运行在Garden容器中,而Garden容器又运行在一个Kubernetes Pod中的Docker容器里,听起来很不优雅,对吧?

如果您有一点虚拟化嵌套的经验,很有可能都不想再读下去了,但请继续坚持一下。确实,从概念上来讲这种情况是“嵌套的容器”,但是事实上情况并没有听起来那么糟。因为“容器的嵌套”并不是真的嵌套,它们更像是同个级别的概念。 根据容器的基本定义,一个容器只是隔离起来的操作系统进程。操作系统进程不可能嵌套, 容器也就不可能嵌套。从调用的层次结构来看,它们的关系是父子关系,但是事实上这两个容器是并列运行的。

尽管刚才我说这种方式不错,但是也并不是那么理想。问题倒不是在性能方面,而是在用户以及运维体验方面。比如我使用“cf push myApp”部署一个应用,之后使用kubectl去查看我的Kubernetes集群,我预期看到的是已经生成一个名为“myApp”的POD 。而以前面这种方式,我只会看到一个名为“garden”的POD,进入“garden”后才能找到我的应用“myApp”。这样是非常冗余的——我们能不能结合Cloud Foundry和Kubernetes两者,并把Kubernetes作为Cloud Foundry里的容器运行时呢?这样不就解决了我们所有的问题并且能够汲取两个平台的精华?道阻且长,但值得一试。

我们进行了新的尝试。本质上,我们想要在部署Cloud Foundry的应用时使用其它的容器调度者。 这种方式利用其它调度者的优势并且可以保留Cloud Foundry的用户体验(“cf push”)和抽象层。如果您想了解的话,我们的Cube代码原型可以在GitHub找到——您也可以通过下面的视频立即体验!


视频2:CF push to Kubernetes

我们称之为“Cube”的原型主要包括四个部分:

* Sink会从CF Cloud Controller拿到目标app并且建立相应的Kubernetes资源。它依赖于Registry来获取droplet需要的OCI镜像,也依赖于OPI来抽象与Kubernetes的交互。
* Registry是一个根据CF droplet来提供镜像的OCI registry。最终这部分会被移到Bits-service。
* St8ge通过运行Kubernetes/OPI一次性的任务实现了Staging。
* OPI或者“orchestrator provider interface”提供了在多个调度者之上的抽象层,灵感来源于Diego的LRP/Task模型以及BOSH CPI的概念。

不言而喻,这个项目仅仅是这段旅程的一个开始,而这段旅程也并不会是一帆风顺的,但是我们相信我们一定可以取得成功并为Cloud Foundry和Kubernetes架起一座桥梁!

如果您会参加即将在波士顿举行的Cloud Foundry峰会,敬请关注以下演讲http://sched.co/DdZl。

希望您能喜欢这篇文章,敬请继续关注!

【译者注】

* CFEE:Cloud Foundry Enterprise Environment。
* IaaS:Infrastructure as a service,即基础设施即服务。
* PaaS:Platform as a service,即平台即服务。
* BOSH:BOSH是一个针对大规模分布式系统的部署和生命周期管理的开源工具。
* CPI:CPI封装了一套IaaS的API,它使得BOSH能够通过对CPI的调用从而实际调用IaaS的API。
* Kubenetes CPI项目: https://github.com/cfibmers/kubernetes-cpi。
* Fissile:可以将BOSH 的release转化为Docker镜像,https://github.com/SUSE/fissile。
* SCF:SUSE Cloud Foundry,https://github.com/SUSE/scf。
* Cube 项目:https://github.com/julz/cube。

原文链接:Cloud Foundry and Kubernetes: A brief history of CF/K8s(翻译:张龚)

=============================================================
译者介绍
张龚,IBM高级软件工程师,参与了文中提及的BOSH、 Kubernetes CPI以及CFEE等相关项目的开发。

火热的云原生到底是什么?一文了解云原生四要素!

阿娇 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-30 18:33 • 来自相关话题

所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应 ...查看全部
所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。
#云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。
1.jpg

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。
##云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。
2.jpg

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。
##云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
3.jpg

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
* 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
#云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!
4.jpg

##持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。
5.jpg

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。
6.jpg

蓝绿(Blue-Green)部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。
##微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。
7.jpg

Going Agile - Breaking the monolith Conway's Law and Microservices

这样按照组织架构划分的优势在于:

  1. 内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。
  2. 服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

  1. 有HA(High Available)的需求需要微服务。
  2. 有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。
  3. 经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?
##容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。
8.jpg

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像Kubernetes、Docker。

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。如果你想和更多 Kubernetes 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
9.jpg

容器生态图

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。
##DevOps——以终为始,运维合一

10.png

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。
#总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

原文链接:https://mp.weixin.qq.com/s/RaAyjfGacHc7xpRahpfv8Q

云原生之下的Java

尼古拉斯 发表了文章 • 0 个评论 • 188 次浏览 • 2019-05-30 10:22 • 来自相关话题

自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。 Cloud Native 在我的理 ...查看全部
自从公司的运行平台全线迁入了 Kubenetes 之后总是觉得 DevOps 变成了一个比以前更困难的事情,反思了一下,这一切的困境居然是从现在所使用的 Java 编程语言而来,那我们先聊聊云原生。

Cloud Native 在我的理解是,虚拟化之后企业上云,现在的企业几乎底层设施都已经云化之后,对应用的一种倒逼,Cloud Native 是一个筐,什么都可以往里面扔,但是有些基础是被大家共识的,首先云原生当然和编程语言无关,说的是一个应用如何被创建/部署,后续的就引申出了比如 DevOps 之类的新的理念,但是回到问题的本身,Cloud Native 提出的一个很重要的要求,应用如何部署 这个问题从以前由应用决定,现在变成了,基础设施 决定 应用应该如何部署。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

让我们回到一切的开始,首先云原生亦或者是 DevOps 都有一个基础的要求,当前版本的代码能够在任何一个环境运行,看起来是不是一个很简单的需求,但是这个需求有一个隐喻所有的环境的基础设施是一样的,显然不能你的开发环境是 Windows 测试环境 Debian 生产环境又是 CentOS 那怎么解决呢,从这一环,我们需要一个工具箱然后往这个工具箱里面扔我们需要的工具了。首先我们需要的就是 Cloud Native 工具箱中最为明显的产品 Docker/Continar,经常有 Java 开发者问我,Docker 有什么用,我的回答是,Docker 对 Java 不是必须的,但是对于其他的语言往往是如果伊甸园中的苹果一样的诱人,打个比方,一个随系统打包的二进制发行版本,可以在任何地方运行,是不是让人很激动,对于大部分的 Java 开发者可能无感,对于 C 语言项目的编写者,那些只要不是基于虚拟机的语言,他们都需要系统提供运行环境,而系统千变万化,当然开发者不愿意为了不同的系统进行适配,在以前我们需要交叉编译,现在我们把这个复杂的事情交给了 Docker,让 Docker 如同 Java 一样,一次编写处处运行,这样的事情简直就像是端了 Java 的饭碗,以前我们交付一个复杂的系统,往往连着操作系统一起交付,而客户可能买了一些商业系统,为了适配有可能还要改代码,现在你有了Docker,开发者喜大普奔,而这里的代价呢?C&C++&GO 他们失去的是枷锁,获得全世界,而 Java 如同被革命一般,失去了 Once Code,Everywhere Run,获得的是更大的 Docker Image Size,获得被人诟病的 Big Size Runtime。

当我们从代码构建完成了镜像,Cloud Navtive 的故事才刚刚开始,当你的 Team Leader 要求你的系统架构是 MicroServices 的,你把原来的项目进行拆分了,或者是开发的就拆分的足够小的时候,你发现因为代码拆分开了,出现了一点点的代码的重复,有适合也避免不了的,你的依赖库也变的 xN,隔壁 Go 程序员想了想,不行我们就搞个 .so 共享一部分代码吧,然后看了构建出来的二进制文件才 15MB,运维大手一挥,这点大小有啥要共享的,Java 程序员望了望了自己的 Jar 包,60MB 还行吧,维护镜像仓库的运维同事这个时候跑出来,你的镜像怎么有 150MB 了, 你看看你们把磁盘都塞满了,只能苦笑,运维小哥坑次坑次的给打包机加了一块硬盘,顺便问你马上部署了,你需要多大的配额,你说道 2C4G,运维一脸嫌弃的问你,为什么隔壁 Go 项目组的同事才需要 0.5C512MB。你当然也不用告诉他,SpringBoot 依赖的了 XXX,YYY,ZZZ 的库,虽然一半的功能你都没用到。

部署到线上,刚刚准备喘口气,突然发现新的需求又来了,虽然是一个很小的功能,但是和现在的系统内的任何一个服务都没有什么直接关联性,你提出再新写一个服务,运维主管抱怨道,现在的服务器资源还是很紧张,你尝试着用现在最流行的 Vertx 开发一个简单的 Web 服务,你对构建出来的 jar 只有 10MB 很满意,可是镜像加起来还是有 60 MB,也算一种进步,你找到 QA 主管,准备 Show 一下你用了 Java 社区最酷的框架,最强的性能,QA 主管找了一个台 1C2G 的服务让你压测一下,你发现你怎么也拼不过别人 Go 系统,你研究之后发现,原来协程模型在这样的少核心的情况下性能要更好,你找运维希望能升级下配置,你走到运维门口的时候,你停了下来,醒醒吧,不是你错了,而是时代变了。

云原生压根不是为了 Java 存在的,云原生的时代已经不是 90 年代,那时候的软件是一个技术活,每一个系统都需要精心设计,一个系统数个月才会更新一个版本,每一个功能都需要进行完整的测试,软件也跑在了企业内部的服务器上,软件是IT部分的宝贝,给他最好的环境,而在 9012 年,软件是什么?软件早就爆炸了,IT 从业者已经到达一个峰值,还有源源不断的人输入进来,市场的竞争也变的激烈,软件公司的竞争力也早就不是质量高,而是如何更快的应对市场的变化,Java 就如同一个身披无数荣光的二战将军,你让他去打21世纪的信息战,哪里还跟着上时代。

云原生需要的是,More Fast & More Fast 的交付系统,一个系统开发很快的系统,那天生就和精心设计是违背的,一个精心设计又能很快开发完的系统实在少见,所以我们从 Spring Boot 上直接堆砌业务代码,最多按照 MVC 进行一个简单的分层,那些优秀的 OOP 理念都活在哪里,那些底层框架,而你突然有一天对 Go 来了兴趣,你按照学 juc 的包的姿势,想要学习下 Go 的优雅源码,你发现,天呐,那些底层库原来可以设计的如此简单,Cache 只需要使用简单的 Map 加上一个 Lock 就可以获得很好的性能了,你开始怀疑了,随着你了解的越深入,你发现 Go 这个语言真是充满了各种各样的缺点,但是足够简单这个优势简直让你羡慕到不行,你回想起来,Executors 的用法你学了好几天,看了好多文章,才把自己的姿势学完,你发现 go func(){} 就解决你的需求了,你顺手删掉了 JDK,走上了真香之路。虽然你还会怀念 SpringBoot 的方便,你发现 Go 也足够满足你 80% 的需求了,剩下俩的一点点就捏着鼻子就好了。你老婆也不怪你没时间陪孩子了,你的工资也涨了点,偶尔翻开自己充满设计模式的 Old Style 代码,再也没有什么兴趣了。

原文链接:http://blog.yannxia.top/2019/05/29/fxxk-java-in-cloud-native/

华为云PaaS首席科学家:Cloud Native +AI,企业数字化转型的最佳拍档

CCE_SWR 发表了文章 • 0 个评论 • 369 次浏览 • 2019-04-23 15:29 • 来自相关话题

近日,在2019华为全球分析师大会期间,华为云PaaS首席科学家熊英博士在+智能,见未来(华为云&大数据)的分论坛上,从云计算行业发展谈起,深入云原生发展趋势,对华为云智能应用平台做了深度解读。 熊英博士为大家分享了云原生技术和平台发 ...查看全部
近日,在2019华为全球分析师大会期间,华为云PaaS首席科学家熊英博士在+智能,见未来(华为云&大数据)的分论坛上,从云计算行业发展谈起,深入云原生发展趋势,对华为云智能应用平台做了深度解读。

熊英博士为大家分享了云原生技术和平台发展的新趋势,重点介绍了华为云智能应用平台。熊英博士提出云原生技术使能企业数字化转型的三个关键点:多云解决方案、泛在的容器和智能边缘。

IT投资投资趋势

数字化转型取代传统应用

云原生技术成为技术驱动力


0423_2.jpg


根据市场调查和预测,企业近些年来在传统应用程序方面的投资正在下降,取而代之的是对云原生应用的投资。现阶段大部分企业已经开始新一轮的数字化转型,即由传统IT应用时代进入云原生应用时代。

开源社区洞悉

云原生技术惠及企业数字化转型

关注度骤升


0423_3.jpg


云原生计算基金会(Cloud Native Computing Foudation,CNCF)2018年报数据显示:

• 2018年,云原生技术在生产中的使用翻了一番;

• 2018年,正评估及准备使用云原生的企业用户增长了3倍以上;

• 从2016年到2018年,CNCF主办的云原生技术大会KubeCon + CloudNativeCon的出席人数,增长了近3倍。

熊英博士表示:在我20余年的IT从业经验中,以上这种增长无疑是少见的,由此可见云原生技术受企业的欢迎程度。

另一份来自CNCF的调查数据表明,企业得益于云原生技术带来的TOP3红利包括:

更快的部署

更高的可扩展性

更好的可移植性

这与华为从客户侧获取的反馈高度一致。


0423_4.jpg


熊英博士表示:

云原生是需要深耕的技术。华为云在2015年就将其列入战略技术投资范围,如今在这方面已经取得了大量成果,成为了云原生技术的领导者。

技术趋势分析

关键词:多云&混合云、边缘、异构计算


0423_5.jpg


如今,云原生技术虽然已经在多个行业和领域规模商用,并充分发挥其架构优势。但面向应用更高性能,更可靠的诉求,云原生技术仍需要不断发展并扩展其架构。

华为云通过持续参与到技术社区、深入到商业客户群,并与生态伙伴在云原生领域进行合作与探讨,提出云原生技术与商业结合的三大发展趋势:

多云和混合云正成为企业的常态,云原生技术将加速该进程。据中国信通院最新的混合云市场调研,半数以上的企业正在积极投入混合云的建设。云原生的可移植性从根本上解决了多云混合云实施的技术难题,有效加速企业多云混合云战略的落地进程。

计算能力应“推”至边缘。下一代云计算的形态并不会是集中式的超算中心,而是由成千上万个边缘节点连成的泛在式、分布式的边缘网络,形成泛在的云。而云原生技术将成为该模式中不可或缺的技术支撑。

云原生技术必须支持异构计算。随着AI和机器学习的规模使用,云原生技术必须支持以GPU,FPGA和ARM为代表的异构计算,为云上和边缘提供更高性能的计算资源,使能云原生应用更高效运行。

在某种程度上,华为正在引领云原生技术的趋势:这不仅是因为华为在云原生技术的投资比中国甚至是部分国外企业都要早,还因为在这个领域继续的创新,不断推出贴近客户需求的、领先于其它企业的产品。

华为云智能应用平台

应用上云更简单

数字化转型更智能


0423_6.jpg


上面提到的三点,华为云已在新推出了智能应用平台3.0中尽数包含。面向未来企业更多智能应用的场景和更高的数字化转型要求,华为云站在云原生的肩膀上,在更专注于智能应用的同时,为数字化转型提供可集成传统应用的ROMA平台以及区块链解决方案,更契合现今的IT发展阶段。

AI容器

软硬全栈优化

为规模AI训练提供云计算基础


0423_7.jpg


在AI领域,目前对算力的需求越来越高,开源组织OpenAI提出:AI领域对GPU的使用已经从单机多卡、多机多卡演进到AI专用芯片。云计算领域对FPGA和异构计算的支持在下一阶段显得尤为重要。预测采用128 GPU并行计算将会是机器学习的常态,跨集群的GPU调度能力将显著地影响计算的整体效率。

华为云容器服务面向上述场景做深度优化:更早的以容器的方式支持GPU以及专用AI芯片,让GPU和Ascend芯片的异构算力服务于大规模AI训练成为可能;借助自身硬件优势,华为云采用硬件感知的NUMA裸金属架构,IB高速网络进行深度的软硬件全栈优化,在资源池组网上保证100Gb大带宽,满足分布式训练的海量参数同步要求;在K8S调度上,针对AI场景进行深度优化,利用排队、亲和性、Gang Scheduling,对接AI分布式训练框架,使能高效的AI分布式训练,大幅度提升了计算效率。

基于以上优化,华为云在Stanford DAWN测试中,表现遥遥领先,深度学习训练对比传统GPU加速方式能够提升3-5倍,在128块GPU时线性加速比高达0.8,超出行业水平50%以上。

KubeEdge

将AI 延伸到边缘

形成泛在智能边缘网络


0423_8.jpg


据IDC研究显示,到2020年将产生500亿的终端与设备联网,其中50%的数据将会在网络边缘侧分析处理,其中90%的需求来源于AI计算。常见的边缘计算方案,没有更多考虑对智能应用的支持。边缘计算应当聚焦于支持智能应用,并增强对智能芯片兼容性。面向在边缘进行的AI推理,边缘侧资源、监控、调度的复杂性将随规模的扩大成倍增长,直接影响整体计算效率,因此提升边缘的管理能力迫在眉睫。

华为云贡献给CNCF的开源项目KubeEdge,是完全基于云原生技术的:KubeEdge首先解决了智能应用的移植性问题,为构造泛在的智能边缘网络提供可能性。

KubeEdge还是CNCF社区接纳的首个边缘计算项目,并已成为智能边缘计算领域的架构标准。

多云&混合云管理

实现跨多云&混合云智能治理


0423_9.jpg


使用多云&混合云已经成为企业上云的共识,快速实现云原生应用跨云管理、部署、运营也是企业上云的关键诉求。华为云作为全行业首发容器多云混合云管理平台的云服务提供商,在今年3月已实现:

多云多活应用、秒级流量接管:云单点宕机故障发生时,应用实例和流量可以秒级完成迁移。

自定义流量策略实现自动跨云弹性:用户通过在跨云部署应用时提前定义流量策略,可应对未知流量高峰。私有云或某个公有云上的服务无法负担时,可以根据流量策略,将服务弹性扩容到其它云集群上,分担流量负载,避免因流量冲击而造成系统瘫痪。

地域亲和性策略优化客户访问体验。应用跨区域部署时,使用自定义的流量管理亲和性策略,能更合理的根据地域对流量进行分配。降低业务访问时延,提升业务响应速度。

华为云多云混合云容器解决方案实施云原生技术领域首个商用的多云&混合云的管理平台,比上周Google刚刚发布的Anthos早了近一个月。

云原生时代已至

行业数字化转型

【Cloud Native BEST】


0423_10.jpg


华为云智能应用平台用户遍布互联网、教育、金融、生物医药等行业,在已经到来的云原生时代,全面使能各行业的数字化转型。

最后,熊英博士提出Cloud Native BEST:我们正处在IT转型期,人工智能和云原生技术是推动企业数字化转型的最佳搭档, 华为很早就看到了这一趋势,并构建了智能应用平台,提供Between Clouds, Edge Intelligence, Strongest Container and enable Transformation,旨在帮助更多的企业实现云原生和数字化转型。

Cloud Native Weekly |面对云平台宕机,企业如何止损

CCE_SWR 发表了文章 • 0 个评论 • 324 次浏览 • 2019-03-12 09:36 • 来自相关话题

KubeEdge v0.2发布 KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目,旨在依托K8S的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。 Kube ...查看全部
KubeEdge v0.2发布

KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目,旨在依托K8S的容器编排和调度能力,实现云边协同、计算下沉、海量设备的平滑接入。

KubeEdge脱胎于华为云IEF服务,是第一个具备在生产环境部署能力的边缘计算领域开源项目。前几天K8S IOT/Edge工作组发布了关于边缘计算的白皮书,并将KubeEdge作为K8S在IOT/Edge场景下的参考架构。

KubeEdge架构上包含两部分,分别是云端和边缘侧。云端负责应用和配置的下发,边缘侧则负责运行边缘应用和管理接入设备。

在v0.2版本中,KubeEdge团队决定开放云端代码,这样KubeEdge v0.1和v0.2的发布分别创造了两个记录:

全球首个开源的支持容器部署的边缘计算平台;

全球首个开放云边协同能力的边缘计算平台;

KubeEdge v0.2 的发布意味着任何人都可以在自己的环境中部署一个完整的涵盖云、边、设备的边缘计算解决方案。另外本次更新还在 v0.1 的基础上新增了云上两个重要组件,分别是:CloudHub和EdgeController,架构如下所示:

1.png



其中:

Cloudhub负责接收EdgeHub同步到云端的信息;

EdgeController用于控制K8S API Server与边缘的节点、应用和配置的状态同步;

用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用,使用习惯与K8S原生的完全一致,无需重新适应。

Rancher发布轻量级Kubernetes发行版 K3s

2.png



近期,容器管理软件提供商 Rancher Labs宣布推出轻量级的 Kubernetes 发行版 K3s,这款产品专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计。

根据Rancher描述,为了减少运行Kubernetes所需内存,k3s主要专注于以下三个方向的变化:

删除旧的、非必须的代码

整合正在运行的打包进程

使用 containerd 代替 Docker 作为运行时的容器引擎

除了 etcd 之外,引入 SQLite 作为可选的数据存储

k3s官方描述的主要使用场景为:

边缘计算

与应用程序绑定使用

嵌入式设备

整体来看,k3s相当于kubernetes针对边缘计算等特殊场景的裁剪和优化,而并非专门专门边缘计算场景的解决方案,未来可能还需要长足的演进和适配过程。

阿里宣布开源 Flutter 应用框架Fish Redux

3 月 5 日,闲鱼宣布在 GitHub 上开源 Fish Redux,Fish Redux 是一个基于 Redux 数据管理的组装式 flutter 应用框架, 特别适用于构建中大型的复杂应用,它最显著的特征是 函数式的编程模型、可预测的状态管理、可插拔的组件体系、最佳的性能表现。

Redux 是来自前端社区的一个用来做 可预测易调试 的数据管理的框架,所有对数据的增删改查等操作都由 Redux 来集中负责。Redux 核心仅仅关心数据管理,不关心具体什么场景来使用它,这是它的优点同时也是它的缺点。在实际使用 Redux 中可能面临两个具体问题:

Redux 的集中和 Component 的分治之间的矛盾;

Redux 的 Reducer 需要一层层手动组装,带来的繁琐性和易错性;

Fish Redux 通过 Redux 做集中化的可观察的数据管理,并且针对传统 Redux 在使用层面上的缺点,在面向端侧 flutter 页面纬度开发的场景中,通过更好更高的抽象,做了改良。

开源之后,闲鱼打算通过以下方式来维护 Fish Redux:

通过后续的一系列的对外宣传,吸引更多的开发者加入或者使用。

配合后续的一系列的闲鱼 Flutter 移动中间件矩阵做开源;

进一步提供,一系列的配套的开发辅助调试工具,提升上层 Flutter 开发效率和体验;

又现云平台宕机企业应如何尽量避免损失

北京时间2019年3月2日23:55分左右开始,监控发现华北2地域部分ECS实例及部分EMR、RDS on ECS、DTS、DBS实例及服务状态异常,事后于3月3日阿里云工程师紧急排查处理,并且逐步恢复异常实例。

细数这两年,国际主流云厂商在安全性和可靠性层面做了不少努力,但所有服务都不可能百分百稳定,尽管云平台会发生故障,但企业对云的信赖度依然很高。Gartner 研究主管 Sid Nag 曾表示,云服务市场的增长速度比几乎所有 IT 市场都要快,其中大部分增长是以传统非云服务为代价,尤其是基于云计算的 IaaS 需求在继续增长,预计将在未来 5 年呈现最快增长趋势。

在云计算出现之前,企业内部自建数据中心依旧会出现很多问题,不少问题甚至是致命的。上云之后,公有云厂商至少可以帮助技术能力有限的企业进行合理范围内的监控、预警和备份。不可否认,云的出现确实解决了现阶段企业在计算、存储等方面的很多问题。但作为企业而言,完全依靠云计算厂商提供安全性的做法是不可取的。

云环境的同城双活、异地灾备等方案基本就绪,尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群,采用异地灾备方案可以在最快时间切换到另一个集群,从而保持系统可用。虽然还是会有中断,但是可以最快时间恢复。

按照此模式,云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员,日常做到以下四点可以尽可能避免云故障带来的损失。

•备份、备份,还是备份,要异机异地;

•数据容灾;

•业务双活;

•定期对灾备和双活进行演练。

从统计上看,中小企业的运维水平远低于主流云平台,故障概率要高得多,损失更不可控。因此,不必对云服务故障抱有恐惧,只需要保持正常的认知和高度灾备意识即可。


相关服务请访问:
https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

灵雀云CTO陈恺:从“鸿沟理论”看云原生,哪些技术能够跨越鸿沟?

灵雀云 发表了文章 • 0 个评论 • 822 次浏览 • 2019-03-11 11:38 • 来自相关话题

历史进入2019年,放眼望去,今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节,我们来梳理和展望一下整个云原生技术趋势的发展,是一件很有意义的事情,这其中有些变化在不可避免地影响着我们身处其中的每一家企业。 ...查看全部
历史进入2019年,放眼望去,今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节,我们来梳理和展望一下整个云原生技术趋势的发展,是一件很有意义的事情,这其中有些变化在不可避免地影响着我们身处其中的每一家企业。

如果说云原生在2017年还仅仅是冒出了一些苗头,那么2018可以说是普及之年,云原生变成了一个成熟的、被普遍接受的理念。

早在1991年Jeffery Moore针对高科技行业和高科技企业生命周期的特点,提出了著名的“鸿沟理论”。这个理论基于“创新传播学”,将创新性技术和产品的生命周期分为五个阶段:创新者(Innovator)、早期使用者(Early adopters)、早期大众(Early majority)、晚期大众(Late majority)、落后者(Laggard)。
01.png

在Early adopters和Early majority之间有个巨大的鸿沟(Chasm),每个新技术都会经历鸿沟,大多数失败的产品也都是在鸿沟里结束了其整个生命周期,能否顺利跨越“鸿沟”,决定了创新性技术的成败。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。
#“Kubernetes is Boring”,边缘创新有亮点
Kubernetes在2017年底成为容器编排事实标准,之后以其为核心的生态持续爆发,在传播周期上可以说已经跨过鸿沟了,进入Early majority早期大众阶段,开始占领潜力巨大的主流市场。
02.png

根据CNCF在2018年8月进行的第六次测量容器管理市场的温度,83%的受访者更喜欢Kubernetes的容器管理工具,58%的受访者在生产中使用Kubernetes,42%的受访者正在进行评估以备将来使用,40%的企业(员工规模在5000+)正在使用Kubernetes。Kubernetes在开发人员中已经变得非常流行。
03.png

进入主流市场的Kubernetes开始变得“Boring”,这很正常,甚至是一个好的现象。核心项目的创新速度会减慢,最新的版本中主要关注点聚焦在稳定性、可扩展性这些方面,尽可能把代码从主库往外推,让它的主库变得干净,其他功能通过一些扩展机制来做,同时开始关注安全性。

Kubernetes项目本身已经过了现象级创新爆发的阶段,但由Kubernetes独特的架构属性催生出的周边生态的二次创新仍然在高速发展,例如诸多与Kubernetes集成或者基于Kubernetes框架开发的上层服务与平台。这个话题我们下次讨论,今天还是主要关注与Kubernetes项目关联最紧密的创新亮点:

早期容器化workload大多聚焦在无状态服务,跑的最多的是Nginx,而对有状态应用避讳不谈。现在Kubernetes进入主流市场,显然需要对“现实中的应用”,包括有状态服务提供良好的支持。2019年,对于复杂应用的管理以及Kubernetes本身的自动化运维将会更多的表现为Operator。

Operator是基于Kubernetes扩展机制,将运维知识编写成“面向应用的Kubernetes原生控制器“,从而将一个应用的整体状态作为API对象通过Kubernetes进行自动化管理。这个应用通常来说是比较复杂的有状态应用,如MySQL数据库、Redis集群、Prometheus等等。现在基本上常见的有状态应用都有自己相对应的Operator,这是一种更为有效的管理分布式应用的方式。

其次是应用跨集群部署与管理。早期社区里有Federation联邦集群的方案。不少大金融客户都有跨集群部署、管理业务的需求。当时深入研究Federation v1之后,觉得这个方案复杂度高,观点性强,对于实际的需求灵活度不足而又不够成熟。所以最终选择自研跨集群部署。后来出现的Federation v2在设计方向上有不小改观,是需要持续关注的项目。

早期采用容器技术的用户都会尽可能兼容企业原有的IT基础设施,比如底层物理机,保留物理机之上的虚拟层,虚拟机之上再跑容器。当然,面向资源管理的硬件虚拟化和面向应用的容器化本质上没有冲突。随着Kubernetes的普及并且在应用上超越了容器编排的范畴,后Kubernetes时代如何搭建管理基础设施是值得思考的。我们也观察到一些有意思的趋势,比如在Kubernetes上同时管理容器和虚拟机(所谓的“容器原生虚拟化”),或是使用Kubernetes来管理OpenStack。

总之,Kubernetes在云计算领域成为既定标准,会越来越多的往下管理所有种类的基础设施,往上管理所有种类的应用。这类标准的形成对于技术社区有很大的益处,会大大降低围绕Kubernetes技术投入的风险。因此,我们会看到越来越多的周边技术向它靠拢,在Kubernetes之上催化出一个庞大的云原生技术生态。

#DevOps:开放式工具链集成与编排
DevOps理念、方法论和实践已经走到了Early Majority早期大众阶段,是已被实践证实的高效开发运维方法。做容器的厂商都经历过用容器搞CI/CD,CI/CD是容易发挥容器优势的显而易见的使用场景。

DevOps包含好几层概念,首先是组织文化的转变,然后涉及到一系列最佳实践,最终这些最佳实践需要用工具去落地。我们在帮助很多大型企业客户落地DevOps的过程中发现:

  1. 在DevOps的整个流程里涉及到很多类别的工具,每一个类别都会有大量的选择;
  2. 每个客户的工具选型多少会有些不同,并不存在一个固定的、完全标准的工具组合;
  3. 随着时间的推移工具选择会发生变化,多数客户意识到目前使用中的工具在未来很可能会被替代。

基于这些观察,DevOps有一种做法是,打造开放式的DevOps工具链集成与编排平台。这个平台可以灵活的兼容客户的工具选型,通过集成将各类工具串联起来,形成一套工具链,通过编排让DevOps工具链与容器平台联动,形成一个完整系统。同时,不断结合自身的经验,提炼DevOps落地的最佳实践,平台将这些最佳实践自动化,作为服务进行输出。

同时,DevOps工具链的编排也最好基于Kubernetes来实现。Kubernetes不仅是出色的容器编排工具,扩展之后也很适合编排DevOps工具。换句话说,可以打造一套“Kubernetes原生的DevOps平台”。
#微服务:落地需要一套完整的基础设施
提起微服务治理,很多人会条件反射般的联想到某些特定的技术,例如Spring Cloud,或者Service Mesh。我们不妨先退后一步,系统考虑下企业微服务架构改造和落地所需要的完整的基础设施。
04.png

首先,在微服务应用的底层需要一个应用管理平台,这在今天毋庸置疑是一个基于Kubernetes的容器平台。
 微服务本质上是分布式应用,在我们获取敏捷性的同时不可避免的增加了运维和管理的难度。微服务对自动化运维,尤其是可观测性的要求很高。支持微服务架构的基础设施必须具备完善的监控、告警、日志、分布式追踪等能力。

在微服务应用的前方,通常需要一个API网关,来管理对外暴露的API。API治理策略,包括安全、路由、流控、遥测、集成等对于任何应用平台都重要,但在微服务架构下尤为关键。我们需要通过定义、封装对外API来屏蔽应用内微服务组件结构细节,将客户端与微服务解耦,甚至为不同客户端提供个性化的API。

云原生应用的一大准则是应用与状态分离。在微服务架构下,每个微服务组件更是应该完全掌控自己的数据。所以,云原生应用通常依赖外部数据服务(Backing Services),而在微服务架构下,多元化持久性(Polyglot Persistence)是常态,也就是说一个微服务架构的应用会依赖非常多种类的 Backing Services。面向微服务架构的基础设施需要将这些外部服务暴露给微服务应用消费,甚至直接支撑各类Backing Services 的部署和管理。

一个团队之所以采用微服务架构,一定有敏捷性的诉求。所以通常微服务团队也会拥抱DevOps理念。一个完善的面向微服务架构的基础设施需要考虑 DevOps 流程以及工具链的自动化。

最后,我们回到狭义的微服务治理,这里关注的是微服务组件之间的连接与通讯,例如服务注册发现、东西向路由流控、负载均衡、熔断降级、遥测追踪等。现在有个时髦的术语来描述这类功能,就是大家熟悉的Service Mesh。其实早期 Sping Cloud 之类的框架解决的是类似的问题,但在实现的方式上,尤其是mesh 和业务代码的耦合度上,有本质的区别。

当我们考虑一个平台如何支撑微服务架构的时候,需要涵盖上述提及的方方面面,从产品的角度我们会保持一个开放的态度。这其中一部分需要我们自己去做,其他一些可以借助生态合作伙伴的能力去补全完善。
此外,微服务架构也进入到了后Kubernetes时代,早期基本上是微服务作为用例推动容器技术的发展。今天已经反过来了,成为标准的Kubernetes其实在驱动和重新定义微服务的最佳实践。容器和Kubernetes为微服务架构的落地提供了绝佳的客观条件。
#Service Mesh:下一个亟待爆发的现象级技术创新
业界对于Service Mesh的布道已经持续了一段时间,我们今天不再重复基本的概念。当我们把Service Mesh和上一代以Spring Cloud为代表的微服务治理框架以及更早的Service Oriented Architecture(SOA)作比较的时候,会看到一个有意思的演化。

我们知道,SOA有企业服务总线(ESB)的概念,ESB重且复杂,其实会混杂很多业务逻辑。SOA架构下,ESB最终容易变成架构以及敏捷性的瓶颈。早期推广微服务架构的时候,一个重要的概念就是“Smart Endpoints and Dumb Pipes”,针对的就是SOA下ESB的痛点,从而每个微服务能够独立、自治、松耦合。

但是仔细去想的话,就会发现它其实走到了另一个极端:它把一些基础设施提供的能力放到微服务的业务组件里面了,通常每个组件需要加载一些治理框架提供的库,或是调用特定的API,其实就是在业务组件里内置了基础设施的功能。到了Service Mesh其实又把它们分开了,从架构角度这样也比较合理,应用是纯业务的东西,里面没有任何基础设施,而提供微服务治理的基础设施,要么在Mesh里面,要么由底层的Kubernetes平台来提供,对应用是透明的。

Istio的出现促使业界对于Service Mesh的架构有了新的共识:控制平面(Control Plane)与数据平面(Data Plane)解耦。通过独立的控制平面可以对Mesh获得全局性的可观测性(Observability)和可控制性(Controllability),让Service Mesh有机会上升到平台的高度。相对于需要在业务代码层面使用的上一代微服务治理框架,这点对于希望提供面向微服务架构基础设施的厂商,或是企业内部需要赋能业务团队的平台部门都具有相当大的吸引力。

在Data Plane,Envoy的领导者地位毫无争议。Envoy使用C++开发,在资源使用效率和性能上(尤其是长尾性能差异)相较早期主要竞争对手Linkerd有明显优势。Envoy提供基于filter chain的扩展机制,从Kubernetes的成功当中我们已经学习到,可扩展性对于大规模采用十分关键。

Envoy定义了一套“通用数据平面API”(Universal Data Plane API),也就是它的xDS协议。不仅确保了Envoy本身的动态可配置性,更重要的是为Service Mesh中Control Plane和Data Plane解耦提供了一个标准的接口。由于主流Control Plane(例如Istio)对Envoy以及xDS的采纳,xDS成为Service Mesh Data Plane API的事实标准,Envoy也成为无可争议的Data Plane领导者。
05.png

在Control Plane,Istio是最具光环的明星级项目。它正在引领Service Mesh创造出一个全新的市场,不过从传播周期看现在还没有跨过技术鸿沟,处于Early adopters阶段。

过去一年中,Istio项目在技术上的表现并不完全令人满意,主要体现在对其复杂度的诟病,以及稳定性和性能的质疑。1.0版本的推出并没有完全令人信服。不过,这些似乎并不影响Istio在社区获得的巨大成功。在开源领域,并不存在对Istio有实质性威胁的竞品。可能在经历了Kubernetes之后,以及Istio早期迅猛的发展和在社区中巨大的影响力之下,很少有开源项目愿意在Control Plane和Istio正面交锋。

长远来讲,Data Plane会慢慢变成commodity,尤其在有了Universal Data Plane API之后。我们有理由相信成熟稳健的Envoy会保持领先,但最终多数用户会越来越少去关心具体的Data Plane技术。这个情境似曾相识,和当初Docker与Kubernetes的关系有点类似。

下个阶段Service Mesh的赋能和创新会更多聚焦在Control Plane。AWS在Data Plane选择成熟的Envoy,而自己开发App Mesh的Control Plane,就很容易理解。灵雀云已经在ACE/ACP两条产品线中集成了Istio,提供企业就绪的Service Mesh。
#云原生为机器学习输出工程化最佳实践
云原生的理念与相关技术对于应用开发与交付的巨大价值已经被普遍接受。但云原生不仅仅可以作用在普通的应用开发上。站在容器平台的角度看,机器学习毫无疑问是一类极为重要新兴工作负载。在未来,可能所有的公司都会是AI公司,所有的应用都会是智能应用,使用算法、模型就像今天应用会依赖数据库一样普遍。

如果我们分析数据科学家的工作流,会发现和传统应用开发有很多相似的挑战。如何方便的获取实验环境;如何让实验可重复;如何将数据处理、特征提取、模型训练、模型验证、模型发布这些步骤自动化,并且可重复;如何让研究和生产环境保持一致;如何在生产环境做模型变更、AB测试、灰度发布;如何在生产环境运维模型服务;如何将模型服务化,等等。

在软件工程领域,云原生的理念、方法论和最佳实践已经为类似问题找到了良好的解决方案。这些方案其实非常适合应用在机器学习场景。换句话说,我们需要“云原生机器学习”。这仍然是一个相对早期的概念,从鸿沟理论的周期来看,云原生机器学习大致还处在Innovators创新者尝鲜的阶段。

进入2019年,巨大的增长空间和发展势头等待着已成事实标准的Kubernetes和容器技术继续开疆拓土,落地到各种业务场景中;DevOps一片蓬勃人气不减,通过打造开放式DevOps工具链集成与编排平台,形成完整的工具链,将最佳实践输出给客户;微服务进入到后Kubernetes时代,Service Mesh技术日渐成熟,落地将成为新的重点。

云原生技术不再曲高和寡,高处不胜寒,成为业内主流标准取舍的关键。今天我们提到的上述云原生技术都是有创新性、颠覆性的技术,有希望顺利跨越鸿沟(Chasm)进入主流市场。2019年的云原生技术将实现实实在在的升级、成熟与落地。

为什么 Service Meshes,容器编排工具是云原生部署的必然选择?

samzhang 发表了文章 • 0 个评论 • 563 次浏览 • 2019-03-11 09:31 • 来自相关话题

【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝 ...查看全部
【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。

独立,短暂的微服务过程带来了一些重大好处,但是保持跟踪每一个单独的微服务是一个挑战,特别是尝试去弄清楚当一个微服务下线后,剩下的服务会受到什么样的影响。最终的结果是,如果你正在一个微服务架构下运营或开发,那么你的一部分时间将会被消耗在搞清楚你的服务到底是什么上。

随着微服务的采用,大型系统中存在大量服务,因此出现问题不可避免。诸如,安全,负载均衡,监控和限速这些问题,过去不得不同意解决,而现在,不得不单独为每个服务一一解决。

幸好工程师乐于这样的挑战。而且每当微服务产生新的问题时,他们都会通过新兴的微服务工具和技术来定位这些问题。也许微服务的出现只是工程师确保饭碗的智能游戏。

如今Cloud Native的宠儿Kubernetes,缓解了微服务带来的许多挑战。自动调度,横向扩展和服务发现,解决了大多在微服务中构建和部署服务将遇到的问题。

Kubernetes 留下了一些尚未解决的容器化应用环境的问题。这就是 Service Mesh 的介入点。让我们看一下 Kubernetes 提供了什么,和 Istio 如何增强 Kubernetes 解决微服务运行环境的问题。
#Kubernetes 解决了构建和部署的挑战
容器编排工具,诸如 Kubernetes,解决了许多来自于容器化应用的构建和部署的挑战。

Kubernetes 支持微服务架构,使开发者能够抽象出一组 Pod 的功能,并且通过明确的 API 来曝露服务给其他开发者。Kubernetes 支持四层负载均衡,但是不能解决更高层的问题,例如,七层指标、流量分流、限速和断路。
#Service Mesh 解决了运行时管理流量的挑战
Service Mesh 有助于解决最终用户使用应用程序时出现的许多挑战。能够监控哪些服务相互通信,他们的通信是否安全和是否能够控制你的集群中服务和服务间的通信,这是确保你的应用安全和弹性运行的关键。

通过在整个过程中生成统一的度量标准,Istio 可以在微服务架构中提供一致的视图。它消除了协调各种运行时代理发出的不同类型的度量标准的需要,或添加任意代理来收集旧的未检测应用程序的度量标准。它在您的多语言服务和集群中增加了一定程度的可观察性,这在任何其他工具的细粒度水平上是无法实现的。

Istio 还增加了更深层次的安全性。Kubernetes 仅提供基本的秘密分发和控制平面证书管理,但是 Istio 提供 mTLS 功能,因此您可以对线路流量进行加密,以确保您的服务间通信是安全的。
#完美的匹配
将 Kubernetes 与 Istio 配对可以为您提供两全其美的优势,而且由于 Istio 是在 Kubernetes 上运行的,因此两者可以无缝协作。您可以使用 Kubernetes 来管理所有构建和部署需求,Istio 负责处理重要的运行时问题。

Kubernetes 已经成熟到大多数企业都将其用于集装箱编排。目前,有 74 家 CNCF 认证的服务提供商,这证明了市场规模庞大且不断增长。我认为 Istio 是 Kubernetes 的延伸,为了解决更多挑战。

Istio 已经快速成熟,并开始在企业中更多地采用。可能在 2019 年,我们将看到 Istio 成为企业的服务网格标准,就像 Kubernetes 作为集装箱编排的标准一样。

原文链接:Why Service Meshes, Orchestrators Are Do or Die for Cloud Native Deployments(翻译:Sam)

云原生DevOps工程师的角色和职责

dummy 发表了文章 • 0 个评论 • 805 次浏览 • 2019-01-15 21:26 • 来自相关话题

云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基 ...查看全部
云原生DevOps是一个相对较新的又包含了旧概念与想法的集合,它们是由于因解决构建应用程序的旧方法的不足的需求而结合在一起的。要了解云原生DevOps工程师每天所做的工作,需要了解云原生模型的目标是构建利用云工具能轻松实现可适应和弹性的应用程序。云原生计算的基础包含有四个主要概念:微服务、容器、CI/CD和DevOps。

微服务是一种将应用程序开发为一系列小型专用服务的方法,这些服务组合在一起形成一个完整的产品。这些功能被打包到像Docker这样的容器中,然后通过持续集成/持续部署管道进行推送。微服务的模块化使不同的团队能够在产品的不同部分上并行工作而不会相互干扰,并且还通过减少任何这些服务的失败对其他服务的影响来增强产品。

使用容器来托管微服务是非常有效的,因为容器比传统虚拟机更有效地使用系统资源。它们只需要运行与它们托管的应用程序相关的服务,而不是整个客户操作系统及其相应的进程。容器对于云原生应用程序的敏捷部署至关重要,尤其是与Kubernetes等管理软件配合使用时。所有这些都是使CI/CD成为可能的基础。如果没有这些工具提供的灵活性,那么这些允许更改,修复或将功能推到生产环境,从开发到自动代码审查和测试的CI流程将非常困难。

DevOps使用所有这些乃至其他更多工具来解决所谓孤岛问题,就是当开发人员编写代码然后将其扔到Ops部门时会发生什么。开发人员从头到尾不拥有他们的代码的结果就是,Ops部门经常需要负责维护未考虑基础架构的代码。这里的解决方案不仅仅是创建出第三个结合开发和运维角色的闭塞的环境。

DevOps不仅仅是一个流程或工作岗位,它更是一种所有权文化。



DevOps工程师试图培养“谁开发谁维护”的理念,这意味着他们需要从软件开发过程一开始就评估可能困扰应用程序生产的瓶颈。云原生DevOps工程师需要能够通过CI/CD流程获取应用程序,以确保代码可以构建,通过测试并在不破坏生产环境的情况下进行部署。这因此激励他们思考应用程序在创建之前的运行方式,并编写脚本来创建持续的集成管道,以确保产品的上市时间更快,用户体验更好。

最优秀的DevOps工程师将能够使用或学习各种开源技术,并且熟悉大量用于编写脚本的编程语言。他们在IT系统,操作和数据管理方面拥有一些经验,能够将这些知识集成到CI/CD开发模型中。至关重要的是,DevOps工程师不仅需要编写代码,还要考虑他们开发的产品的实际业务成果。像这样的全局思考还需要强大的软技能,以实现跨团队以及客户和技术团队之间的沟通。

当然,没有谁是一座孤岛。DevOps团队虽然在同一个组织覆盖下运作,但是需要各类不同的角色才能胜任。这些团队成员的实际头衔可能会因地而异,但一般职责仍然相同:

  • 产品负责人(负责团队的工作):此人担任客户团队联络人。他们需要特别强大的软技能和有效沟通技术概念的能力,以便与客户合作,提出满足期望的产品。他们了解全局,可以告诉团队应该如何运行应用程序以及使用什么基础架构。
  • 团队领导(负责团队的工作方式):此人是技术团队的管理类型角色。他们根据团队成员的个人优势和技能集来委派职责。他们也贡献代码,但是在短期发展冲刺背景下,他们使团队与产品所有者的全局观保持一致。他们通常对技术决策有最终决定权。
  • 自动化架构师/站点可靠性工程师(SRE):此人在构建云基础架构方面经验丰富,并了解在生产中支持应用程序所需的内容。他们开发自动化系统,以确保持续部署顺利运行。他们专注于确保基础架构在大规模环境中的稳定性能,并了解如何随着公司的发展扩展基础架构。
  • 软件开发人员:软件开发人员将与之前列出的所有团队成员一起工作,并根据客户的要求创造出代码,然后进行测试,部署和监控。

随着团队的发展,这些角色可能会分成几个其他更细粒度的职位,以便利用增加的人力资源。UX工程师,测试工程师和安全工程师就是一些例子,它们会从列出的其他一些人那里承担重要的责任并对其进行扩展。

原文链接:Roles and Responsibilities of Cloud Native DevOps Engineers(翻译:fengxsong)

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 855 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

微服务浪潮中,程序猿如何让自己 Be Cloud Native

李颖杰 发表了文章 • 0 个评论 • 649 次浏览 • 2018-12-26 10:08 • 来自相关话题

# 前言 CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等 ...查看全部
# 前言
CNCF 与 Cloud Native 这两个技术词汇最近频频走进了程序员的视野,一切和它能搭上边的软件意味着标准、开放、时尚,也更能俘获技术哥哥们的心;这篇文章不想去带大家重温这个词汇后面的软件体系,笔者觉得单凭用到了这些开源软件,不等于我们自己的软件就已经是 Cloud Native,在使用哑铃和成为肌肉男之间还隔着科学使用和自律锻炼两道工序;在此,笔者想根跟大家聊聊让我们的应用真正变得 Cloud Native 时的理论依据:微服务的十二要素。这篇文章也是先从作者自身项目的角度(一个基于 EDAS 的微服务架构),来阐述对这十二条要素的前两条 —— 仓库(Code Base)与依赖(Dependency)的理解。

Code Base 的原文释义是:"一份基准代码,多份部署,基准代码和应用之间总是保持一一对应的关系;不同环境中的相同应用,应该来源于同一份代码"。我的理解有两个:

  1. 一个应用,产生自同一个仓库。
  2. 一个仓库,只产生一个应用。

为什么推演出这么两个结论呢?让我们先看一个实际的项目。
# 为什么是一个应用?
给大家举一个一个仓库包含多个应用的反例,笔者自己的一个项目是一个微服务架构,和大部分的微服务架构一样,一开始是由一个单体的应用拆解而来,拆解之后,大致简化成四个服务:微服务网关(Gateway),两个后台服务(UserService, OrderService),后台管理控制台服务(Admin),简单的架构示意图如下:
arch.png

在拆分的过程一开始为了项目上线减少风险,将拆分之后的应用都放在了一个 Git 仓库中进行管理,同时也共用了同一个库。重构之后仓库的目录如下:
~/workspace/java/app/ $ tree -L 2
.
├── README.md
├── service-api # 通用的 API 接口定义
│ ├── userservice-api # 服务 UserService 的声明
│ ├── orderservice-api # 服务 OrderService 的声明
│ ├── rpc-api # 远程服务调用相关的接口声明
│ ├── common-api # UserService 与 OrderService 都依赖的声明
| .....
├── service-impl # 对应 API 的相关具体业务实现
│ ├── userservice-impl
│ ├── orderservice-impl
│ ├── common-impl
| .....
├── web-app # Web 应用工程
│ ├── admin
│ ├── userservice
│ ├── orderservice
│ ├── gateway

一开始这些服务之间的发布和改动彼此都不受影响,这一过程持续了大约两个迭代,随着迭代的不断进行和新人的加入,后来我们线上发现一个很奇怪的现象,每次用户进入刷新订单的地址列表的时候,会伴随这一次用户 Token 的刷新而导致用户被踢出,线上的排查过程在 EDAS 的分布式链路跟踪系统 EagleEye 的帮助下,马上就定位到了出问题的代码:
java
// User Service 中
public class User {
public void refresh() {
// 刷新登录 token
}
}

// Order Service 中
public class OrderUser extends User {
// 函数少了一个字母,导致 refresh 调用了父类的 refresh
public void refesh() {
// 刷新地址列表
}
}

​这个故障,我先邀请大家一起思考一下几个问题:

  1. 从编码角度,如何避免上述重写的方法因为名字误写造成故障?
  2. 从设计角度,OrderUser 和 User,是否是继承关系?
  3. 这个问题的根因是什么?

以上的几个问题中,第一个问题的答案,很多同学都知道,就是使用 Java 自带的 Annotation `@Override`,他会自动强制去检查所修饰的方法签名在父子类中是否一致。第二个问题,需要从领域边界来说,这是一个典型的边界划分的问题,即:订单中的用户,和会员登录中的用户,是不是相同的“用户”?会员中的用户,其实只需要关心用户名密码,其他都是这个用户的属性;而订单中的用户,最重要的肯定是联系方式,即一个联系方式,确定一个人。虽然他们都叫做用户,但是在彼此的上下文中,肯定是不一样的概念。所以这里的 `OrderUser` 和 `User` 是不能用继承关系的,因为他们就不是一个 "IS A" 的关系。

仓库共享,加上没有多加思考的模型,导致依赖混乱;如果两个 `User` 对象之间代码上能做到隔离,不是那么轻易的产生“关系”,这一切或许可以避免。
# 为什么是一个仓库?
严格意义上说,一个应用的所有代码都肯定来源于不同的仓库?我们所依赖的三方库如(fastjson,edas-sdk 等)肯定是来源于其他的仓库;这些类库是有确切的名称和版本号,且已经构建好的"制品",这里所说的一个仓库,是指源码级别的“在制品”。可能在很多的项目中不会存在这样的情况,以 Git 为例,他一般发生在 Submodule 为组织结构的工程中,场景一般是啥呢?在我们这个工程中确实是有一个这样的例子:

为了解掉第一个问题,我们决定拆仓库,仓库的粒度按照应用粒度分,同时把 common 相关的都拆到一个叫做 common 仓库中去;业务服务都好说,这里特殊处理的是 admin 应用,admin 是一个后台管理应用,变化频度特别大,需要依赖 UserService 和 OrderService 一大堆的接口。关于和其他仓库接口依赖的处理,这里除了常见的 Maven 依赖方式之外,还有另外一个解决方案就是 git submodule,关于两个方案的对比,我简单罗列在了下表之中:
B.png

我觉得如果这个项目组只有一两个人的时候,不会带来协作的问题;上面的方案随便哪一个都是不需要花太多时间做特殊讨论,挑自己最熟悉最拿手的方案肯定不会有错,所谓小团队靠技术吗,说的就是这么个道理;我们当时是一个小团队,同时团队中也有同学对 Submodule 处理过类似的情况,所以方案的选择上就很自然了。

后来随着时间的推移,团队慢慢变大,就发现需要制定一些流程和和规范来约束一些行为,以此保障团队的协作关系的时候;这时候发现之前靠一己之力打拼下来的地盘在多人写作下变得脆弱不堪,尤其是另外一个 Submodule 变成一个团队进行维护的时候,Submodule 的版本管理几乎不可预期,而且他的接口变动和改动是完全不会理会被依赖方的感受的,因为他也不知道是否被依赖;久而久之,你就会明白什么叫做你的项目被腐化了。简单理解腐化这个词就是,你已经开始害怕你所做的一切改动,因为你不知道你的改动是否会引来额外的麻烦。从这个角度也可以去理解为什么一门语言设计出来为什么要有 privatepublic这些表示范围的修饰词。正因为有这些词的存在,才让你的业务代码的高内聚成为的有可能,小到设计一个方法一个类、再引申到一个接口一个服务、再到一个系统一个仓库,这个原则始终不变。

上述问题带来的解法很简单,就是变成显示依赖的关系,所谓显示依赖是指的两个依赖之间是确定的。什么是确定的?确定 == No Supprise !对,不管什么时候,线上还是线下,我依赖你测试环境的接口返回是一个整数,到了线上,返回的也必须是一个整数、不能变成浮点数。而让确定性变得可行的,不是君子协定;只能是一个版本依赖工具。比如说 Java 中的 Maven 正式的版本依赖。
# 结语
职责内聚、依赖确定,是我们的应用变得真正 Cloud Native 的前提。没有了这些基本的内功,懂的开源软件再多、对微服务栈再熟悉,也会有各种意想不到的事情出来,试想一下,如果应用的职责到处分散,那到时候扩容到底扩谁呢?如果依赖方变得及其不确定,谁又来为每次发版的不确定的成本买单?Be Cloud Native,请从应用代码托管的住所开始。

作者:阿里巴巴高级技术专家 孤弋

灵雀云重磅发布3大云原生产品 顺应传统IT云原生转型需求

灵雀云 发表了文章 • 0 个评论 • 907 次浏览 • 2018-10-10 11:10 • 来自相关话题

近日由云原生技术实践联盟(CNBPA)和灵雀云联合主办的首届云原生技术实践峰会正式召开,灵雀云创始人兼CTO陈恺在会上发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、云原生机器学习赋能平台Alauda Machine ...查看全部

近日由云原生技术实践联盟(CNBPA)和灵雀云联合主办的首届云原生技术实践峰会正式召开,灵雀云创始人兼CTO陈恺在会上发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、云原生机器学习赋能平台Alauda Machine Learning(AML)和企业级容器PaaS平台Alauda Cloud Enterprise(ACE)三大产品。

pic1.jpg


灵雀云创始人兼CTO 陈恺
灵雀云成立于2014年, 是一家专注于容器服务和企业级PaaS的云服务商,在西雅图和北京都设有研发中心,其CEO左玥、CTO陈恺均出自原微软Azure云平台的核心创始团队,公司75%以上的后端开发工程师均拥有Kubernetes代码级的熟练掌握能力。
灵雀云于2017年11月获得由腾讯云战略领投,高榕资本、宽带资本跟投的超亿元人民币B轮融资;2018年5月又获得由英特尔投资领投,明照资本等战略投资人跟投的新一轮融资,是目前国内容器PaaS领域融资轮次最高、估值最高、总融资额最大的IT服务企业,客户覆盖了银行、证券、保险、运营商、制造、能源、航空、汽车等领域的诸多五百强企业。
2018年:云计算的后Kubernetes时代
“自Kubernetes在2017年底成为容器编排标准以来,其对技术社区和行业的影响力正在迅速爆发,2018年云计算已进入后Kubernetes时代。”陈恺在题为《云原生助力企业持续创新》的演讲中提到:“未来,Kubernetes或将向下管理所有基础设施,向上支撑所有应用,成为真正意义上的‘云操作系统’以及新一代的‘应用服务器’,Kubernetes还有可能成为绝大多数应用的唯一交互方式。”
陈恺坦言,因Kubernetes扩展机制的灵活性,越来越多的开发者将Kubernetes作为开发框架使用,去扩展Kubernetes的功能,通过Kubernetes提供与容器编排并不相关的各种服务,技术社区中流行的各种花式玩法,甚至远远超出了Kubernetes设计者的预料之外。
云原生的概念在早期非常小众,在云原生技术实践联盟(CNBPA)的推动下,2018年进入云原生的爆发期,开发交互方式正在向云原生的方向改变,云原生的概念迎来了实际的落脚点。
未来传统企业将逐渐演变成软件公司,但是只在商业模式中包含软件,并不能带来竞争力的优势,而云原生能够最大化释放云计算生产力的应用设计、开发、交付和管理方式,其容器化、动态调度和快速交付的特点能够快速将价值传递给客户,这是传统企业关注云原生技术的根本原因。

pic2.jpg


ACP:一站式云原生应用赋能平台
云原生由容器、DevOps 和微服务为代表的敏捷基础架构组成,灵雀云本次发布的一站式云原生应用赋能平台(Alauda Container Platform,ACP),包括Alauda Kubernetes、ACP DevOps和ACP Service Framework三大标准化产品,是灵雀云云原生技术经过实践沉淀出的全新产品套件,实现了对云原生三大领域的完整覆盖。

Alauda Kubernetes是灵雀云提供的企业级Kubernetes发行版,据介绍,该版本在过去两年里已被100余家企业客户运用在生产环境当中,并通过了CNCF官方一致性认证,支持一键安装和升级,用户体系可以灵活打通,权限和决策参照了企业中实际的使用习惯,从网络到存储皆可开箱即用,针对运维人员提供从监控到日志的完整解决方案。
在DevOps方面,灵雀云在2017年提供了支持CICD流水线和容器流水线能力的版本,受客户使用工具和流程的需求驱动,本次发布的ACP DevOps采用开放式工具链的集成和编排,实现了对生态合作伙伴解决方案的完整集成,让企业客户感觉是一个整体,贯穿应用的全生命周期管理。

ACP本身也是依托于DevOps开发,陈恺在现场进行了用例演示,从现场演示可以看出,运用ACP DevOps,开发者进行代码开发,会激发一条流水线跑单元测试和自动化测试,之后在预发布的环境中跑更完整的测试,全部通过后工程师会正式推入到生产环境,发布成功后机器人将自动推送消息。客户可以在生产环境中无限次的模仿真实用户的行为,产生大量监控数据,通过监控指标分析对比各应用版本之间的质量,有问题系统会自动报警,最后企业选择哪一版本发布就变成了纯业务的决定,由于前期的反复测试,大大降低了正式版本发布流程的工作量。
ACP Service Framework是基于微服务的治理平台,已帮助诸多大型企业客户实现微服务落地。ASF平台全面集成了 SpringCloud框架,用户可以在ASF平台上一键创建微服务环境,只需将环境分配给每个项目,项目里的开发人员就有了API网关、服务注册、发现、配置中心、熔断监控、全链路追踪等完整的微服务治理功能。
AML:云原生机器学习赋能平台
“近两年,在Kubernetes集群上做机器学习和深度学习的客户越来越多,未来,采用算法模型的应用将像使用数据库一样常见。”陈恺提到。云原生机器学习赋能平台Alauda Machine Learning(AML)是灵雀云用云原生的思想落地机器学习工程化的最佳实践,该平台集成了数据科学家的常用工具,可以用AML创建分布式的环境并方便地展开实验。AML可与ACP联动,实现从模型的开发、训练、验证、发布到再训练的整个流程自动化,也可将ACP用于模型发布时的测试,陈恺希望通过AML与ACP等产品线的集成,最终实现模型持续训练、优化、验证的完整闭环。

pic3.jpg


ACE:企业级容器PaaS平台
最后发布的产品是Alauda EE的2.0升级版——企业级容器PaaS平台Alauda Cloud Enterprise(ACE),ACE包含了ACP的所有功能,支持多集群、多租户,并进行了大量的生态集成。
ACE的第一个特性是多集群,除了支持默认的Kubernetes集群,用户还可以自己导入集群,或使用第三方厂商的集群,例如将腾讯、微软的软件集成到用户的PaaS平台上来;ACE跨集群的部署和管理方式,能帮助金融客户实现两地三中心的管理。
ACE的第二个特性是多租户,ACE的大多数客户均来自大企业的平台部门,他们运用ACE为整个企业提供完整的PaaS平台,灵雀云在租户模型的灵活性方面有着相当大的优势。
ACE的第三个特性是生态集成,从产品的设计理念来看,陈恺表示客户可以很容易的替换成灵雀云生态当中的其他合作伙伴,不会被某一云厂商锁定。
灵雀云的产品演进方向 满足各类上云需求
从以上三大产品的发布可以看出,灵雀云的产品演进方向十分明确,ACE主要支持大客户搭建统一的PaaS平台,用于支持各类基础设施、内外部环境以及更多相对复杂的场景。而ACP和ACE的设计目标不同,其功能更通用、更简单,灵雀云希望总结从头部客户中积累下来的经验,将那些通用的提炼出来,变成高度标准化的产品交付给更广阔的市场,从而满足中小企业的云化需求。从集成的角度来看,ACP很容易被其他系统集成,ACE很容易集成其他系统,二者从产品的角度来看是一个互补。大客户可以用ACE作为底座去集成灵雀云生态合作伙伴的各类解决方案,而中小客户可以让ACP独立的集成到其他各个合作伙伴的生态中去,而其他相应功能也将按照这一思路逐渐在平台上实现产品化。

传统业务迁移需求会逐渐转向云原生
““传统企业做数字化转型,不仅需要软件,更要具备软件快速交付能力,能够自给自足开发软件。云原生、DevOps、微服务等理念,都是围绕着这一目标去实现的。”



灵雀云提供行业容器PaaS解决方案的出发点正是基于企业的数字化转型需求。针对企业软件开发迭代慢、资源利用率低等问题,灵雀云为企业搭建统一的PaaS容器云平台,基于容器技术帮助企业取得持续的创新能力。



从目前来看,企业上云需求来自两方面,一是传统业务的迁移需求,二是云原生技术新能力的推动。陈恺表示,这两类需求会逐渐重合,而且在DevOps、容器化编排、微服务这些领域的需求已然重合,传统业务迁移需求会逐渐转向云原生。