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

经过近3年的建设打磨，美团流水线引擎完成了服务端的基建统一，每日支撑近十万次的流水线执行量，系统成功率保持在99.99%以上。本文主要介绍美团在自研引擎建设层面遇到的挑战以及解决方案，希望对大家能够有所帮助或启发。
目录
一、背景
二、问题及思路
2.1业务介绍
2.2主要挑战
2.3解决思路
三、整体架构
四、核心设计点
4.1作业调度设计
4.2资源池划分设计
4.3组件分层设计
五、后续规划
一、背景
持续交付这个概念最早在2006年敏捷大会上被提出，经过多年的发展，目前已成为很多技术团队提升研发效能的必经之路。通过建设部署流水线，打通从代码开发到功能交付的整个环节，以自动化的方式完成构建、测试、集成、发布等一系列行为，最终实现向用户持续高效地交付价值。
流水线引擎作为支撑部署流水线的底座，它的好坏直接影响着部署流水线建设的水平。业界通常的做法是通过Jenkins、GitlabCI等开源工具（或公有云产品）进行搭建，这是一条能帮助业务快速落地持续交付的道路，美团早期也是采用搭建Jenkins的方式来快速支撑业务。
但随着越来越多业务开始做持续交付的建设，这种“短平快”方式的弊端逐渐显现。比如，工具建设没有统一的标准，各业务都需要去了解整个工具链的细节，建设成本高、水平参差不齐，很少有业务能搭建完整的部署流水线。同时，业务每天的构建量都在快速增长，逐渐超过Jenkins等开源工具所能承受的极限，在交付高峰期任务严重排队、服务不可用现象频出，严重影响着业务交付的顺畅度。
美团在流水线引擎的建设层面大概经历了几个阶段。在2019年以前，主要围绕Jenkins进行优化， 2019年开始正式立项打造自研的流水线引擎，大致的历程如下：第一阶段（2014-2015）：搭建Jenkins统一集群，解决业务接入的通用问题（如单点登录、代码仓库集成、消息通知、执行机的动态扩缩等），降低业务的建设成本。第二阶段（2016-2018）：拆分多个Jenkins集群，解决业务增长导致单集群性能瓶颈。最多时有十几个集群，这些集群通常是按业务线维度划分，并由业务自行建设。但随着时间的推移，集群的拆分管理难度越来越大， Jenkins安全隐患频出，对平台方造成了很大的运维负担。第三阶段（2019-至今）：为了彻底解决引擎单机瓶颈和工具重复建设问题，我们开始自研分布式流水线引擎（美团内部项目名称为Pipeline），并逐步收敛各业务依赖的底层基建。
经过3年左右的建设打磨，流水线引擎完成了服务端的基建统一，涵盖到店、到家、大众点评、美团优选、美团平台、自动配送车、基础研发平台等几乎所有的业务，支持Java、C++、NodeJS、Golang等多种语言。在性能和稳定性方面，引擎每日支撑近十万次的流水线执行量（作业调度峰值每小时达上万次），系统成功率保持在99.99%以上（排除业务代码自身原因和第三方工具的问题）。
下面我们主要介绍下我们在自研引擎建设上遇到的挑战以及对应的解决方案。
二、问题及思路
1、业务介绍
1）什么是流水线
我们可以把流水线的执行看作是对代码一步步加工，最终交付到线上的过程。根据业务定义的顺序关系，依次执行相应的加工或质量校验行为（如构建、代码扫描、接口测试、部署工具等），整个执行过程类似一个有向无环图。