系统成功率99.99%+，美团CI/CD流水线引擎演进实践( 七 ) 经过近3年的建设打磨

文章图片
图12队列拉取设计
3、组件分层设计
1）分层架构

文章图片
图13组件架构设计业务层：引入适配层，满足组件开发中多样化的需求场景，同时避免上层差异污染到下层。系统交互层：设立统一的流程标准，保证引擎和组件交互过程的一致性，便于统一处理非功能性的系统优化。执行资源层：提供多种资源策略，向上层屏蔽不同资源类型的差异。
2）标准的交互流程设计
在系统交互层，组件与引擎交互的过程中，有两个环节是确定的， ①组件作业的状态机流转，这涉及到组件执行的整个生命周期管理，若允许存在不同的状态流转关系，整个管理过程会十分混乱；②引擎对外提供的接口范围，从服务间解耦的角度，对外提供的接口主要是组件作业维度的接口操作，不应该耦合任何组件内部的实现细节。
结合作业状态机+引擎提供的接口，确定了组件执行基本的系统交互流程。利用模版模式，抽象出init()、run()、queryResult()、uploadArtifacts()等必要方法供业务实现，整个交互流程则由系统统一处理，业务无需关心。

文章图片
图14组件标准流程设计
3）扩展基础能力
组件执行除了正常的执行流程外，随着业务场景的丰富，还会涉及组件中止、回调（人工审批场景）等操作，这些操作的引入势必会改变原先的交互流程。为了不增加额外的交互复杂度，在拉取作业环节，增加作业的事件类型（运行、中止、回调等事件）， Worker根据拉取到的不同事件，执行相应的扩展逻辑。同时，引入新的扩展也不会影响到已有的交互流程。

文章图片
图15组件扩展能力设计
基于上述扩展，我们可能更好地将一些通用能力下沉到DaemonThread层。如结果查询流程，通过守护线程的方式，取消了原先同步等待的查询限制，这对于需要异步化处理的场景（如组件作业逻辑已执行完，仅在等待外部平台接口返回结果）可以提前释放资源，提高资源执行的利用率。并且，当执行资源故障重启后，结果查询线程会自动恢复待处理异步作业。这部分能力的支持在业务层是透明的，不改变整个交互流程。
4）引入适配器
业务虽可以通过必要方法完成自定义组件，但这些方法过于基础，业务在一些特定场景下实现成本较高。如对于组件支持Shell的脚本化调用，业务其实仅需提供可执行的Shell即可，通用约定的方式，其他必要方法的实现都可以交由系统完成。
针对业务个性化的处理，采用适配器模式，通用引入不同Command（ShellCommand、xxCommand）来默认实现特定场景下的必要方法，降低业务的开发成本。同时，保持系统侧流程的一致性，通过动态注入Command的方式，防止对业务个性化处理的耦合。

文章图片
图16组件适配器设计
5）效果
目前已支持Shell组件、服务组件、容器组件等多种接入方式，平台上已提供数百个组件，组件开发方涉及数十个业务线。组件库覆盖源码域、构建域、测试域、部署域、人工审批域等多个环节，打通了研发过程所涉及的各个基础工具。

文章图片