应用上云能够有多快？

1      摘要

本文介绍了为何在一个好的公有云或私有云中必需要有一个编排系统来支持云上自动化，以及实现这个编排系统的困难和各家的努力。同时提供了一套实现编排系统的原型，它包括了理论分析及主体插件框架，还给出一些细节控制的建议。但愿有助于你们对“资源编排&应用编排”概念有更深的了解，也但愿以开放的心态与你们一块儿努力，使得云真的像水电同样天然和普及。

 

2      为何须要云上自动化

IT领域的自动化要求无需多言，每一个程序员都知道这是必须品。自动化脚本，自动化测试，自动化部署等等，都是为了程序及围绕此程序的各种程序员跑的更加欢快。那么在云上咱们是否还须要自动化？简单而言，初次使用无需考虑；深度用户须要云上自动化。具体体如今：

2.1      重复性的执行动做

在云上验证应用上线的工做中，有不少的事情是须要重复操做的。好比环境的销毁和重建；或者扩容的场景下，重复地完成多个新实例的配置动做。一旦此类操做的频率变高，好比一天一次或者一天屡次的时候，你必定会以为繁琐，而且开始尝试如何使得整个流程变的自动化，从而保证每一次执行是可重复的。也许你会写些Shell或者Python脚本，或者你主动调用云提供商的API，甚至借助某些工具如Chef，Puppet来完成这个目的。

    重复是催生自动化的首要条件。

2.2      节约时间

在云上使用服务，有些操做是很是耗时的，好比建立数据库，建立VM，都需等待分钟级别的时间。一旦须要串行的建立多个耗时任务，就须要用户持续等待一段时间。而此时若是能够将整个流程自动化，则能够释放人为的等待过程，使程序员去完成其余更有价值的任务。

云上的流程自动化后，执行动做的整体耗时并不会减小，只是这段等待时间能够被转移，好比放在深夜执行。也正是这个缘由（耗时没有减小，只是转移了），因此自动化后时间的节省，仍是要以重复性为前途的。假如只是一次性的操做，那么“自动化节约的时间” vs “完成自动化的时间”通常都是不划算的。

 

2.3      基础环境的复制

这里的基础环境是指Infrastructure，是指应用跑在云上所须要的全部云服务的集合。例如一个典型Web网站的3层架构，前端+后台+数据库。在云上的某个区（例如华北区）域搭建好一套完整的系统后，遇到须要在华南区甚至另外一个云提供商的云上，从新搭建同样的环境的时候，就会有系统复制的需求。是靠程序员手动一个一个组件的安装？仍是自动化的一键重复部署？在有后者能力的状况下，固然后者是首选。

如今不少云厂商都推行一个叫作 Infrastructure As Code 的概念，使用机器能够理解的配置文件，来代替人工交互式的配置动做。而且这种配置文件能够经过版本管理系统像代码同样进行版本管理。这样对于企业的好处主要体现有3个：减少成本、提升效率、下降风险。

减少成本很好理解，如上提到的，自动化能够将人力转移到其余任务上，提升程序员的产出。而效率的提高主要体如今经过自动化的配置能够将环境安装的实施过程缩短，若是有多个组件或者团队交互的话，提高效率就更明显了。同时自动化能够消除人为的错误，可重复的执行特性也提高实施过程的可靠性。

2.4      自助式服务

云上服务，若是作得好，应该是自助式的，就像自来水和电同样，即开即用，按需付费。只有这样子才能够支持任意的自动化按需供给、按需扩容，也才是云自己所具有的含义。

因此这一条理由实际上是对云提供商提出的要求，你的云平台要可以支持用户自助式的按需使用各类云服务，并提供相应的使用计量信息（帐单）和使用报告。只有当平台的后端实现流程是全自动化的，才能作到给用户的体验是彻底自助式的。这跟淘宝商家的“有货随便拍”一个道理，不然没到下单前都得跟店家沟通，没法作到按需自助式使用。

 

2.5      小结：自动化的成本

任何须要自动化的东西，前提就是你须要重复的执行，只有当自动化的收益大于重复的成本，才会有自动化的需求出现。假如任务只是一次性的，那就不存在自动化的需求。相反咱们相信从收益方面考虑，精心人工操做一遍会比将流程自动化更为划算。

比如有时候路上遇到口渴并不会想安装一套自来水，还不如直接买一瓶矿泉水来的实在，而在家里，则须要安装一套自来水系统，由于你天天都须要使用水。

云上的自动化提供了一种可靠性，它使得云资源，云服务的每一次建立的行为都是一致的，任何用户，任何组织的执行都是可重复的；同时也消除了因为人为操做可能的失误所带来的问题，是云上深度用户的必需品。

 

3      云上自动化演进

3.1      自动化面临的困难

（1）云服务的种类丰富多样，致使想要完成全面的自动化并不是易事。一个典型的云平台会提供了ECS（虚机），EVS（硬盘），VPC（网络），RDS（数据库），ELB（负载均衡）等等一系列数都数不清的服务。有一个新的术语叫作 AWS fatigued，就是说AWS每一年都会上线各类新服务&新特性，使得用户对新上线的服务&特性都感到了“AWS疲乏”，疲于使用。

（2）云服务间的建立存在复杂的依赖关系。最典型的例子就是，当建立EIP的时候，需绑定VM，而建立CM的时候，又须要先建立Subnet，建Subnet的前提就是须要先有VPC。层层的依赖，以及交叉依赖，都为开发者在企图自动化的道路设置了拦路虎，使得完成自动化的成本大大提升。根据前面提到的成本大于重复性收益的时候，自动化就会被放弃。

（3）云上资源的使用方式与传统方式不一样。用户从资源的彻底拥有者变成资源的使用者，后台权限的下降，致使你没法掌控一切，使得不那么方便的定位资源初始化失败缘由（也许云平台自己的Bug致使）。有时候不得不联系云提供商求助了解失败缘由。另外在使用流程上也会稍有改变，原来你的软件包一次拷贝就到了验证环境，而在云上，也许你须要中转跳板才能达到目的。这些都加重了自动化的实施困难。

3.2      自动化的尝试

 

这里直接给一个图来总结了云上自动化的尝试历程，能够更加直观的了解这一领域的发展状况。不过在资源供给自动化和资源编排上其实边界也没有那么的明显，能够看到主要的差别是在灵活的语法上。在已有的自动化模板里面逐步增长一些灵活的语法，基本能够达到灵活编排的目的。

 

4      终极的自动化体系-编排

自动化是指一个任务流程中不须要人为的干预，而编排则是指多个任务流程能够提早规划，任务间能够互相配合，并行或者串行的执行。能够从最直接的定义上看到，只有作到任意的自动化流程控制才能称之为编排，是一个自动化的升级版。因而可知，若是某云厂商的一个编排系统，连一些基础的自动化流程都没法知足，那么它就不是一个好的编排系统。

 

4.1      云上的编排标杆

提到云上的编排系统，就不得不提老大哥AWS的Cloudformation了，基本上它已是AWS云生态的一个标准，支撑应用市场以及服务目录完成任意IT软件和IT基础设施的初始化流程。

它的主要原理就是用户提供建立对象的各类属性，而后CFN协助完成对象的建立。例如初始化EC2，就是至关于建立VM虚拟机。那么用户就得提供属性：主机名，用什么镜像，硬盘多大，用什么网络，主机规格，安全组等。有了这些属性，CFN就能够肯定如何调用EC2的API来建立VM了。

它之因此能力很强是由于它除了提供执行顺序的控制能力之外，在语法层面还提供了不少的内置函数，用户能够经过函数来引用变量，拼接变量值，控制执行细节。超丰富的编排对象，使得使用CFN基本能够知足任意AWS资源的自动化建立。

 

4.2      云上编排系统对比

这里分析三家典型的提供编排能力的云厂商能力分析表，不对之处也请联系纠正。（亚马逊CFN、阿里ROS、华为AOS）

√表示“强/作得好”，O表示“通常/待加强”，X表示“没有此特性”。

功能	特性	AWS	ROS	AOS	说明
模板语法	入参/对象/输出	√	√	√	编排基本功能
	查表参数	√	√	√	Mapping表语法，提早确认变量值
	条件部署	√	√	O	Condition条件语法，灵活控制对象是否建立
	编排对象	√	√	O	云服务的种类
	内置函数	√	O	O	字符串拼接: Fn::Join 获取属性： Fn::GetAtt
	内置变量	√	√	X	AWS中：AWS::Region ROS中：ALIYUN::StackName
	资源启动顺序	√	√	√	如 DependOn 依赖关系
	头文件引用	O	X	√	长模板文件拆分为多模板文件管理
堆栈执行	资源策略	√	X	X	如堆栈销毁时，部分堆栈资源是否保留
	Metadata定义	√	O	O	为对象填加自定义扩展属性
	堆栈嵌套	√	X	√	堆栈包含另外一个堆栈，大型协做场景(如解决方案)须要
	帮助工具	√	X	X	如cfn-init/cfn-hup等，部署VM虚机应用的辅助工具
	堆栈更新	√	O	O	ChangeSet，给出详尽变动提示
	K8S应用	X	X	√	编排Kubernetes生态中的应用
设计器	元素拖拽	√	√	√
	依赖连线	√	√	√
	缩放定位	√	√	√
	图文联动编辑	√	X	√	ROS不支持IDE纯文本编辑
	图片预览	√	√	√
	单元素编辑	√	√	√
	元素属性联想	X	O	√	光标自动联想，给出元素可用属性字段提示
	属性结构展现	X	√	√	复杂的属性定义，免记编辑
	语法校验	√	X	√
	函数快速插入	X	O	X
	元素文档提示	O	O	√

注：OpenStack的Heat编排能力相似AWS，可是无图形化设计器，这里就不列举了。

4.3      编排系统的不足

当前的编排系统都须要一个描述文件，来描述用户但愿的执行流程。通常都会把这个描述文件称之为“模板”。经过模板来控制执行逻辑，这并非一个问题，由于你能看到的业界编排系统都有本身的“模板”语法规则。问题在于，从无到有的写做一个新的模板，会比较困难，须要使用者学习必定的门槛，你们的第一感受老是像在学习一门新的编程语言。

这个是由编排的目标对象的复杂度决定的：建立一个RDS数据库，就是会比单首创建一台VM，须要有更多的控制参数。因而一种新的模板语法，至关于一种新的编程语言。写过代码的你确定知道，想要快速的编码，固然须要合适的IDE支撑。也正所以，一些有实力的编排系统就会推出相应的图形化设计器，其定位就是配套的模板写做IDE。

好比AWS，阿里和华为都提供了在线的模板编辑IDE。设计器好坏的评价标准就是可否支撑方便的写做模板。

 

5      如何实现云上编排系统

一个编排系统的核心就是一个工做流引擎，负责分析各个步骤间的依赖关系，并按照DAG（有向无环图）模型来控制这些流程的执行顺序。而云上的编排，更加的具化，就是按依赖顺序建立各个云服务。

算法层面，咱们能够称每一个云服务为元素。建立各类云服务的过程，就是按顺序建立各个元素的过程。

 

5.1      有向无环图DAG

有向无环图（Directed Acyclic Graph, DAG）, 是有向图的一种，字面意思的理解就是图中没有环。经常被用来表示事件之间的依赖关系，用于管理任务之间的调度。

 

图：一个有向无环图的例子

其中全部节点的拓扑排序是有向无环图中常常须要使用到的算法，咱们的系统原型也是按照此理论基础进行实现的。就是把全部元素按照DAG依赖关系肯定好谁先谁后的顺序，具体算法你们能够在网上或者资料中搜索得到，这里就不细介绍了。排好序后，接下里的实现就是先完成底层的元素，再完成上层元素，直到全部元素都初始化完毕。以上就是咱们的编排系统模型的理论参照。

5.2      编排系统原型

在这里咱们假设有一个系统的初始化流程以下：

 

要实现全部元素按照设定好的顺序建立，咱们听从两个要点：（1）默认并行执行。（2）无依赖的先执行。具体算法实现上，咱们首先将元素启动顺序分解为有向图，并遍历计算获得每一个节点的依赖数。以下：

 

注：依赖只须要计算临近的节点就能够。

遵循以前的两个原则：那么元素B和元素D的依赖数是0，因此这两个元素能够先执行初始化。同时B和D之间无关，能够并行执行。

在任意一个元素执行完以后，全部依赖这些节点的依赖数减一，从新获得全部节点的依赖数：

 

本次能够执行的元素就是C和F，由于它们的依赖数为0。在这两个元素执行完后，将依赖他们的元素的依赖数减一，从新获得全部节点依赖数：

 

按照上述的逻辑递归执行，直到全部的元素都被执行完，整个工做流就完成了。它保证整个流程是按顺序用时最短的。从工做流实现原理可知，编排的能力强弱并不强调流程控制，而是编排元素，及编排语法的丰富程度。好的编排系统，能够快速的完成新元素的驱动开发，从而提供新服务的编排能力。

5.3      元素间信息传递

若是每一个元素初始化，都得记录着其余元素的信息，这种在实现上元素间就很耦合。为了保持每一个元素在执行时候的独立性（即当前元素在初始化时，不用去了解其余元素的信息）。主体框架须要保持一个全局信息，而后在初始化一个元素的时候，把这个元素须要的信息告诉它就行。它本身彻底不知道还有哪些其余元素，反正它本身须要的信息都有了。

    这里举例说明，调度框架维护一个全局信息，记录每一个元素须要哪些参数才能初始化。上图绿色的须要用户提供，红色的则在被依赖对象建立后自动得到。好比建立VM须要VPC的ID，那么在VPC建立后，VPC的ID就知道了，这个字段不用用户提供。

因此在元素D初始化完成后，元素C就能够开始初始化了。这个时候，全部建立C的参数，都应该是确认的值。在调用C服务的初始化API的时候，不缺任何信息。这样在实现C的建立API和销毁API，就很是独立，只与C服务自己打交道。

    如上图，在开发新服务的时候，只须要了解新服务自身就能够了，全部想要的信息（能够直接要求用户提供，或者经过依赖得到），都会经过框架管理和传递。

 

这就是咱们的插件化框架，这个框架使得新增一种服务很是容易。由于服务的驱动开发是彻底独立的。

5.4      插件设计

5.4.1        元素的生命周期

每一种云服务对象，在编排系统看来都是一个元素。新增一种元素的编排，就须要该元素提供增删改查等基础执行能力。编排系统的插件管理框架会根据用户执行动做，好比建立or销毁，来调用元素对应的API。

有了上一节的元素执行流程框架后，新增一个编排对象，只须要完成该元素的各类行为驱动就能够。例如：只要有建立和销毁VM的方法（API），那么就能够在编排元素里面增长一个EC2服务，就能够在模板里面增长这种元素的编排了。调度框架只是把它当作一个普通元素来对待。

5.4.2        用户自定义插件

    基于插件框架每一个元素驱动独立的优点，同时考虑到Kubernetes中的Resource对象也有自定义扩展特性（custom resource definition），能够设计一种元素插件支持用户定义本身的K8S编排对象的能力。即把用户提供的“信息”原封不动的传递给底层API。由底层系统去解释用户的“信息”。编排系统退化为只负责流程控制+信息传递通道。

5.4.3        操做的等待&进度

以前提过，有些云服务的操做很是耗时，若是不能提供总体进度的直观反馈，用户体验就会很是的差，觉得整个执行流程挂死。因此在元素驱动的编写时，必须考虑进度和等待反馈，让编排框架能感知执行进度。使得用户能够知道当前在执行哪一个元素，该元素的执行进度如何。从而确保总体的编排流程可以给用户最直接和友好的反映。

5.5      TOSCA模型

有了调度框架&插件框架，剩下的就是配置文件的语法了，目前主要的可借鉴语法就是AWS的Cloudformation和TOSCA语法。其中AWS-CFN是以资源初始化为中心的，而TOSCA的定义为TOSCA is a specification that aims to standardize how we describe software applications and everything that is required for them to run in the “cloud”，可见TOSCA是更加偏向于面向App的。鉴于容器技术的流行，愈来愈多的应用以独立容器出现，再也不强调须要传统的VM。咱们以为模板语法使用TOSCA是个不错的选择。

实际上，在自动化的过程当中，你会发现：模板的语法并非关键点。只要能自动化，模板写出来都不会相差太大，因此关键仍是看自动化能力。这个就比如编程语言的选择，Java和Go，写二叉树遍历不会在乎是用for仍是用while。各类编程语言的主要区别在内置函数/库上，因此在模板的语法上提供丰富的自动化便利性才是目的。这一点须要向AWS学习，它提供了不少的内置函数。

6      总结

在云上，自动化实际上是刚需，只有完成了自动化这个基座，才能构建出完整的云生态。而编排做为一种高级自动化能力，须要负起推进云生态走向完整的重任。是检验一个云厂商实力的硬通货。

华为PaaS团队在云上，特别是PaaS云上的自动化&编排领域，有多年的探索和积累。在此但愿能与业界一块儿分享并推进云上编排领域的发展，使得在云的使用过程当中能带来更好的用户体验，让云上自动化能真正如云这个趋势同样无处不在。

 

目前，华为云AOS产品正在举行一场应用最快上云的挑战赛。

在这里，你能够看到全面的场景化解决方案应用上云模板。

如今开始，建立你的应用模板，赢取丰厚礼品吧~

https://bbs.huaweicloud.com/forum/thread-11376-1-1.html