干货：如何实现云上编排系统

随着云计算的普及，在云上的自动化需求是必然的结果。那么作为一个优秀的云平台，如何去实现一个可靠且便捷的编排系统呢？本文就跟大家分享并探讨我们这这方面的实践经验。
一个编排系统的核心就是一个工作流引擎，负责分析各个步骤间的依赖关系，并按照DAG（有向无环图）模型来控制这些流程的执行顺序。而云上的编排，更加的具化，就是按依赖顺序创建各个云服务。算法层面，我们可以称每个云服务为元素。创建各种云服务的过程，就是按顺序创建各个元素的过程。
有向无环图DAG
有向无环图（Directed Acyclic Graph, DAG）, 是有向图的一种，字面意思的理解就是图中没有环。常常被用来表示事件之间的依赖关系，用于管理任务之间的调度。
一个有向无环图的例子
其中所有节点的拓扑排序是有向无环图中经常需要使用到的算法，我们的系统原型也是按照此理论基础进行实现的。就是把所有元素按照DAG依赖关系确定好谁先谁后的顺序，具体算法大家可以在网上或者资料中搜索获得，这里就不详细介绍了。排好序后，接下里的实现就是先完成底层的元素，再完成上层元素，直到所有元素都初始化完毕。以上就是我们的编排系统模型的理论参照。
编排系统原型
在这里我们假设有一个系统的初始化流程如下：
要实现所有元素按照设定好的顺序创建，我们遵从两个要点：
•默认并行执行。
•无依赖的先执行。
具体算法实现上，我们首先将元素启动顺序分解为有向图，并遍历计算得到每个节点的依赖数。如下：
注：依赖只需要计算临近的节点就可以
遵循之前的两个原则：那么元素B和元素D的依赖数是0，所以这两个元素可以先执行初始化。同时B和D之间无关，可以并行执行。

在任意一个元素执行完之后，所有依赖这些节点的依赖数减一，重新得到所有节点的依赖数：
本次可以执行的元素就是C和F，因为它们的依赖数为0。在这两个元素执行完后，将依赖他们的元素的依赖数减一，重新得到所有节点依赖数：
按照上述的逻辑递归执行，直到所有的元素都被执行完，整个工作流就完成了。它保证整个流程是按顺序用时最短的。从工作流实现原理可知，编排的能力强弱并不强调流程控制，而是编排元素，及编排语法的丰富程度。好的编排系统，可以快速的完成新元素的驱动开发，从而提供新服务的编排能力。

元素间信息传递
如果每个元素初始化，都得记录着其他元素的信息，这种在实现上元素间就很耦合。为了保持每个元素在执行时候的独立性（即当前元素在初始化时，不用去了解其他元素的信息），主体框架需要保持一个全局信息，然后在初始化一个元素的时候，把这个元素需要的信息告诉它就行。它自己完全不知道还有哪些其他元素，反正它自己需要的信息都有了。
这里举例说明，调度框架维护一个全局信息，记录每个元素需要哪些参数才能初始化。上图绿色的需要用户提供，红色的则在被依赖对象创建后自动获得。比如创建VM需要VPC的ID，那么在VPC创建后，VPC的ID就知道了，这个字段不用用户提供。

所以在元素D初始化完成后，元素C就可以开始初始化了。这个时候，所有创建C的参数，都应该是确认的值。在调用C服务的初始化API的时候，不缺任何信息。这样在实现C的创建API和销毁API，就非常独立，只与C服务本身打交道。
在开发新服务的时候，只需要了解新服务自身就可以了，所有想要的信息（可以直接要求用户提供，或者通过依赖获得），都会通过框架管理和传递。
这就是我们的插件化框架，这个框架使得新增一种服务非常容易，因为服务的驱动开发是完全独立的。
插件设计
1、元素的生命周期
每一种云服务对象，在编排系统看来都是一个元素。新增一种元素的编排，就需要该元素提供增删改查等基础执行能力。编排系统的插件管理框架会根据用户执行动作，比如创建or销毁，来调用元素对应的API。
有了上一节的元素执行流程框架后，新增一个编排对象，只需要完成该元素的各种行为驱动就可以。例如：只要有创建和销毁VM的方法（API），那么就可以在编排元素里面增加一个EC2服务，就可以在模板里面增加这种元素的编排了。调度框架只是把它当做一个普通元素来对待。
2、用户自定义插件
基于插件框架每个元素驱动独立的优势，同时考虑到Kubernetes中的Resource对象也有自定义扩展特性（custom resource definition），可以设计一种元素插件支持用户定义自己的K8S编排对象的能力。即把用户提供的“信息”原封不动的传递给底层API。由底层系统去解释用户的“信息”。编排系统退化为只负责流程控制+信息传递通道。
3、操作的等待&进度
之前提过，有些云服务的操作非常耗时，如果不能提供整体进度的直观反馈，用户体验就会非常的差，以为整个执行流程挂死。所以在元素驱动的编写时，必须考虑进度和等待反馈，让编排框架能感知执行进度。使得用户可以知道当前在执行哪个元素，该元素的执行进度如何。从而确保整体的编排流程能够给用户最直接和友好的反映。

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学习，它提供了很多的内置函数。
在云上，自动化其实是刚需，只有完成了自动化这个基座，才能构建出完整的云生态。而编排作为一种高级自动化能力，需要负起推动云生态走向完整的重任。是检验一个云厂商实力的硬通货。
华为PaaS团队在云上，特别是PaaS云上的自动化&编排领域，有多年的探索和积累。在此希望能与业界一起分享并推动云上编排领域的发展，使得在云的使用过程中能带来更好的用户体验，让云上自动化能真正如云这个趋势一样无处不在。

如果有好的想法&建议，留言跟我们交流。