这里举例说明，调度框架维护一个全局信息，记录每个元素需要哪些参数才能初始化。上图绿色的需要用户提供，红色的则在被依赖对象创建后自动获得。比如创建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 总结