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