作者：耿杰 春暉 志遠

經過近3年的建設打磨，美團流水線引擎完成了服務端的基建統一，每日支撐近十萬次的流水線執行量，系統成功率保持在99.99%以上。

一、背景

持續交付這個概念最早在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）什么是流水線

我們可以把流水線的執行看作是對代碼一步步加工，最終交付到線上的過程。根據業務定義的順序關系，依次執行相應的加工或質量校驗行為（如構建、代碼掃描、接口測試、部署工具等），整個執行過程類似一個有向無環圖。

圖1 流水線概念

2）基本概念

• 組件：出于代碼復用和業務共享的考慮，我們將某一工具的操作行為封裝成一個組件，表示對于一項具體的加工或校驗行為。通過組件方式，業務可以便捷地使用已集成的質量工具（如靜態代碼掃描、安全漏洞分析等），減少在同一工具上的重復開發成本；對于不滿足需求的場景，業務可以自定義一個新的組件。
• 組件作業：表示組件的一次運行實例。
• 資源：為組件作業分配的一個可執行環境。
• 流水線編排：表示流水線中不同組件執行的先后順序。
• 引擎：負責調度所有的組件作業，為其分配相應的執行資源，保證流水線執行按預期完成。

2、主要挑戰

1）調度效率瓶頸

對調度時間相對敏感，流水線大部分是短時作業（作業持續數十秒到分鐘不等），如果調度時間過長，業務能明顯感知到流水線執行變慢了。我們需要保證作業調度時間在一個可控的范圍內，避免出現調度瓶頸。

• 從業務場景考慮，調度邏輯存在一定的業務復雜性（如組件串并行判斷、優先級搶占、降級跳過、復用上一次結果等），不僅僅是作業與資源的匹配計算，作業調度耗時存在一定的業務開銷。
• 引擎支撐公司每天近十萬次的執行量，峰值量情況下，并發調度的作業量大，常見的開源工具（Jenkins/GitLab CI/Tekton等）都是采用單體調度模式，作業是串行調度的，容易出現調度瓶頸。

2）資源分配問題

對于作業系統來說，作業數通常都是大于資源數的（真實部署情況，資源不是無限的），作業積壓是系統設計時必須考慮的問題。如何在有限的資源下，盡可能提高作業的吞吐能力，同時降低在資源不足情況時造成對核心業務場景的影響。

• 如果只依靠動態擴容，容易出現資源不足時無法擴容、作業排隊等待的情況。特別是對于依賴流水線做研發卡控的業務，這會直接阻塞業務的上線流程。
• 出于執行耗時的考慮，大部分資源采用預部署的方式，縮短資源申請和應用啟動的準備時間。而對于預部署的資源，如何進行有效劃分，既保證每類資源都有一定配額，同時也避免出現部分資源利用率過低，影響作業整體的吞吐能力。
• 不是所有工具的執行資源都由引擎管理（如發布系統，部署任務的資源管理是單獨的），在作業的資源分配上，還需要考慮不同的資源管理方式。

3）工具差異化問題

公司內不同業務的差異化大，涉及的質效類工具眾多，如何設計一個合適的插件化架構，滿足不同工具的接入需求。

• 不同工具實現形式差異化大，有些工具有獨立的平臺，可以通過接口方式進行集成，有些僅僅是一段代碼片段，還需要提供相應的運行環境。面對不同的接入形態，引擎如何屏蔽不同工具帶來的差異，使業務在編排流水線時不用關注到工具的實現細節。
• 隨著業務場景的不斷豐富，組件執行還會涉及人工交互（審批場景）、支持重試、異步處理、故障恢復等能力，這些能力的擴展如何盡可能減少對系統的沖擊，降低實現的復雜度。

3、解決思路

1）拆分調度決策與資源分配，解決調度效率瓶頸

從上述分析，一個作業的實際調度耗時 = 單個作業的調度耗時 * 待調度的作業數。因為單個作業的調度耗時會受具體的業務邏輯影響，不確定性大，優化空間有限。而串行調度問題相對明確，在作業調度時間和數量不可控的情況下，是一個合適的優化方向。

關于串行調度，業界常見的做法是按照業務線維度拆分多個集群，分攤總的調度壓力。但這種方式存在的問題是資源分配不具備靈活性，很容易出現資源的分配不均，在整體資源不足時，無法從全局上考慮高優作業的資源分配。并且，多集群管理（新增集群/拆分現有集群）也是不小的運維負擔。

進一步分析，串行調度主要是為了避免資源競爭問題，獲得相對最優的資源。這對于流水線場景（作業量大于資源量且都是短時作業），資源最優解不是強訴求。并且，資源量的并發度相對作業量更可控，根據作業執行快慢不同，我們通過主動拉取作業的方式，控制拉取的數量和頻率，從而有效降低了資源競爭的情況。

最終，我們在設計上采取了調度決策與資源分配分離的模式：

• 調度決策：負責計算出可以調度的作業，提交決策，等待合適的資源來執行。該模塊具體水平擴展，分擔調度決策的壓力。
• 資源分配：負責維護作業與資源的關系，通過主動拉取作業的方式，資源可以向任意的實例拉取作業，取消了原先串行分配資源的單點限制。

在這種模式下，作業調度、資源分配都具備水平擴展能力，擁有更高的性能和系統可用性。也利于作業調度的邏輯能夠獨立演進，便于開發、測試以及灰度上線。

2）引入資源池管理模式，實現資源的靈活分配

考慮到不是所有資源都由引擎管理，我們引入資源池的概念來屏蔽不同資源方式的差異，每個資源池代表一類資源的集合，不同資源池的資源管理方式可以是多樣化的。通過該方式，我們將資源分配的問題簡化為作業與資源池的匹配問題，根據作業的實際情況，合理設置不同的資源池大小，并配合監控手段對資源池進行動態調整。

在具體措施上，我們選擇“標簽”的方式建立作業與資源池的匹配關系，通過從作業與資源兩個維度來滿足上述條件。

• 在作業端，作業基于標簽屬性拆分到不同的作業隊列，并引入優先級概念，保證每個隊列中作業按優先級高低被拉取到，避免在積壓時，高優作業排在后面無法被及時處理，阻塞業務研發流程。
• 在資源端，結合資源的實際場景，提供三種不同的資源池管理方式，以解決不同資源類型的配額和利用率問題。

a. 預置的公共資源，這部分資源會提前在資源池上擴容出來，主要應對業務高頻使用的且對時間敏感的組件作業。在資源配額和利用率上，根據資源池的歷史情況和實時監控，動態調整不同資源池的大小。

b. 按需使用的資源，主要針對公共資源環境不滿足的情況，業務需要自定義資源環境，考慮到這部分作業的體量不大，直接采用實時擴容的方式，相比預置資源的方式，可以獲得更好的資源利用率。

c. 外部平臺的資源，這些資源的管理平臺方比我們更有經驗，平臺方通過控制向引擎拉取作業的頻率和數量，自行管理作業的吞吐情況。

3）引入組件的分層設計，滿足工具差異化需求

為了保持工具接入的自由度，引擎提供了作業維度最基本的操作接口（拉取作業、查詢作業狀態、上報作業結果），不同工具可以根據作業接口形式實現定制化的組件開發。

組件開發主要涉及①實現業務邏輯和②確定交付方式兩部分工作，而與引擎的系統交互相對是標準的。我們根據組件執行過程進行分層設計，拆分出業務邏輯、系統交互與執行資源三層。在向引擎屏蔽工具實現細節的同時，可以更好地滿足多樣化的接入場景。

• 系統交互層，該層相對組件開發者是透明的，根據引擎提供的接口制定統一的流程交互標準，以向引擎屏蔽不同組件的實現差異。
• 執行資源層，主要解決工具運行方式的差異化，通過支持多種組件交付形式（如鏡像、插件安裝、獨立服務）滿足工具與引擎的不同集成方式。
• 業務邏輯層，針對業務不同的開發場景，采用多種適配器的選擇，來滿足業務不同的開發訴求。

三、整體架構

圖2 流水線架構

• 觸發器：作為流水線的觸發入口，管理多種觸發源及觸發規則（Pull Request、Git Push、API 觸發、定時觸發等）。
• 任務中心：管理流水線構建過程中的運行實例，提供流水線運行、中止、重試、組件作業結果上報等操作。
• 決策者：對所有等待調度的作業進行決策，并將決策結果同步給任務中心，由任務中心進行作業狀態的變更。
• Worker：負責向任務中心拉取可執行的作業，并為作業分配具體的執行資源。
• 組件SDK：作為執行組件業務邏輯的殼，負責真正調起組件，完成組件初始化與狀態同步的系統交互。

四、核心設計點

1、作業調度設計

1）調度過程

下面，我們以一個簡單的流水線調度示例（源碼檢出 - [并行：代碼掃描，構建] - 部署），來介紹調度設計中各模塊的協作過程。

圖3 調度過程

大致邏輯如下：

①當觸發流水線構建后，系統會在任務中心創建該編排所要執行的所有組件作業。并且將作業狀態的變化以事件方式通知決策者進行決策。

②決策者接收決策事件，根據決策算法計算出可被調度的作業，向任務中心提交作業的狀態變更請求。

③任務中心接收決策請求，完成作業狀態變更（作業狀態變更為已決策），同時加入相應的等待隊列。

④Worker 通過長輪詢方式拉取到和自己匹配的等待隊列的作業，開始執行作業，執行完成后將結果上報給任務中心。

⑤任務中心根據Worker上報的作業執行結果變更作業狀態，同時向決策者發起下一輪決策。

⑥以此反復，直至流水線下所有作業都已執行完成或出現作業失敗的情況，對流水線進行最終決策，結束本次執行。

整個過程中，任務中心作為一個分布式存儲服務，統一維護流水線和作業的狀態信息，以API方式與其他模塊進行交互。而決策者和Worker通過監聽作業狀態的變化執行相應的邏輯。

2）作業狀態流轉

下面是一個作業完整的狀態機，我們通過作業決策、拉取、ACK以及結果上報一系列事件，最終完成作業從初始狀態向完結狀態的流轉過程。

狀態機在接收某種狀態轉移的事件（Event）后，將當前狀態轉移至下一個狀態（Transition），并執行相應的轉移動作（Action）。

圖4 狀態機

在實際場景中，由于調度過程涉及鏈路長、各環節穩定性無法完全保證，容易產生因異常情況導致狀態不流轉的情況。為此，在設計上利用數據庫保證狀態變更的正確性，同時為非完結狀態作業設立相應的補償機制，確保任一環節異常后作業可以恢復正確流轉。

我們重點從作業決策和作業拉取這兩個關鍵過程來看狀態流轉過程可能出現的問題，以及在設計上是如何解決的。

①作業決策過程：任務中心接收調度作業的決策，將可調度的作業從unstart變為pending狀態，同時將作業加入等待隊列，等待被拉取。

圖5 狀態機-決策

• 未收到決策事件：由于決策者服務自身的問題或網絡原因，導致決策事件的請求失敗，作業長時間處于未調度狀態。

解決方案：引入定時監測的機制，對于無過程狀態作業且處于未完結狀態的流水線進行重新決策，避免決策服務短時間異常導致決策失敗。

• 重復決策：由于網絡延遲、消息重試現象可能出現多個決策者同時決策同一個作業，產生作業轉移的并發問題。

解決方案：增加pending的狀態表示作業已被決策到，并通過數據庫樂觀鎖機制進行狀態變更，保證僅有一個決策會真正生效。

• 狀態變更過程異常：由于存在異構數據庫，狀態變更和加入隊列可能存在數據不一致，導致作業無法被正常調度。

解決方案：采用最終一致性的方案，允許調度的短暫延遲。采用先變更數據庫，再加入隊列的操作順序。利用補償機制，定時監測隊列隊首的作業信息，若pending狀態下的作業有早于隊首作業的，進行重新入隊操作。

②作業拉取過程：任務中心根據Worker拉取作業的事件請求，從等待隊列中獲取待調度作業，將作業的狀態從pending變更為scheduled，并返回給Worker。

圖6 狀態機-ACK

• 作業丟失問題：這里存在兩種情況，①作業從隊列中移除，但在狀態將要變更時異常了；②作業從隊列中移除，也正確變更了狀態。但由于poll請求連接超時，未正常返回給Worker。

解決方案：前者通過作業決策環節中對pending狀態的作業補償機制，重新加入隊列；后者對于狀態已變更的情況，已調度的作業增加ACK機制，若超時未確認，狀態會流轉回pending狀態，等待被重新拉取。

• 作業被多個Worker拉取：Worker在接收到作業后，遇到長時間的GC，導致狀態流轉回pending狀態，在Worker恢復后，可能出現作業已分配到另一個Worker上。

解決方案：通過數據庫樂觀鎖機制保證僅有一個Worker更新成功，并記錄作業與Worker的關系，便于對作業進行中止以及Worker故障后的恢復操作。

3）決策過程

決策過程是從所有未啟動的作業中篩選出可以被調度的作業，通過一定的順序將其提交給任務中心，等待被資源拉取的過程。整個篩選過程可以分為串并行順序、條件過濾、優先級設置三部分。

圖7 決策過程

• 串并行順序：相對于DAG中復雜的尋路場景，流水線場景比較明確，是將代碼逐步加工驗證，通過開發、測試、集成、上線等一系列階段的過程。階段間是嚴格串行的，階段內出于執行效率的考慮，會存在串并行執行的情況。這里通過模型設計，將DAG的調度問題轉變成作業的先后次序問題，引入run order概念，為每個組件作業設置具體的執行次序，根據當前已執行作業的次序，快速篩選出下一批次序僅大于當前的作業，若并行執行，僅需將作業的次序設置成相同即可。

圖8 串并行決策

• 條件過濾：隨著業務場景擴展，不是所有的作業都需要調度資源，進行真正的執行。如某類耗時的組件，在代碼和組件參數都不變的情況下，可以直接復用上一次的執行結果，或者在系統層面針對某類工具異常時進行組件跳過的降級操作。針對這類情況，在作業真正提交給任務中心之前，會增加一層條件判斷（條件分為全局設置的系統條件以及用戶條件），這些條件以責任鏈形式進行依次匹配過濾，根據匹配到的條件單獨向任務中心提交決策。
• 優先級設置：從系統全局考慮，在作業出現積壓時，業務更關心核心場景下整條流水線是否能盡早執行完成，而不是單個作業的排隊情況。所以，在優先級設置上除了基于時間戳的相對公平策略外，引入流水線類型的權重值（如發布流水線>自測流水線；人工觸發>定時執行），保證核心場景流水線相關作業能夠盡早被調度到。

2、資源池劃分設計

1）整體方案

我們采用多隊列的設計，結合標簽建立作業隊列與資源池的匹配關系，以保障不同隊列資源的有效劃分，在出現隊列積壓、資源池故障、無可擴資源等情況時，最大限度地降低影響范圍，避免所有作業全局排隊等待的現象。

圖9 資源池架構

2）模型關系

圖10 資源池模型對象

①作業隊列與標簽的關系：隊列與標簽采用1對1的關系，降低業務理解和運維成本。

• 當隊列積壓時，能快速定位到某個標簽沒資源了。
• 標簽資源不足時，也能快速判斷影響的具體隊列情況。

②標簽與資源池的關系：標簽和資源池采用多對多的關系，主要從資源整體利用率和對核心隊列的資源可用性保障考慮。

• 對于一些作業量較少的隊列，單獨分配一個資源池會造成大部分時間資源是空閑狀態，資源利用率低。我們通過給資源池打多標簽的方式，既保證了隊列有一定的資源配額，同時也能處理其他標簽的作業，提高資源的利用率。
• 對于核心場景的隊列，通常標簽資源會分配到多個資源池上，保證資源的一定冗余，同時也降低單個資源池整體故障帶來的影響。

3）標簽設計

標簽的目的是建立資源（池）與作業（隊列）的匹配關系。在設計上，為便于標簽管理和后期維護，我們采用二維標簽的形式，通過組件和流水線兩個維度，共同決定一個作業所屬標簽及對應的資源。

• 第一維度：組件維度，對資源做通用劃分。結合組件的業務覆蓋情況、作業執行量、對機器和環境的特殊要求（如SSD、Dev環境等），對需要獨立資源的組件進行打標，劃分出不同的公共資源池（每個公共資源池執行一類或多類組件作業），在引擎層面統一分配，保證所有作業都有可正常運行。
• 第二維度：流水線維度，根據業務場景進行劃分。結合業務對資源隔離/作業積壓敏感度的訴求，按需進行劃分。有些希望資源完全獨立的業務，會從所有的公共資源池進行切分；有些僅對部分核心場景下的資源需要保障，根據鏈路上涉及的組件，選擇性地從部分公共資源池進行劃分，實現業務隔離和資源利用率的平衡。

注：每個維度都會設一個other的默認值用來兜底，用于處理無資源劃分需求的場景。

圖11 標簽設計

4）隊列拆分設計

根據作業所屬標簽不同拆分出多個隊列，保證每個隊列的獨立性，降低作業積壓的影響范圍。整個拆分過程可以分為入隊和出隊兩部分：

• 入隊過程：通過計算作業在組件和流水線兩個維度的屬性值，來確定作業對應的標簽。結合模型關系中標簽與隊列（1對1）的關系，為每個標簽按需創建一個隊列，存儲該標簽作業，不同隊列間作業做排他處理，簡化出隊的實現復雜度。
• 出隊過程：隊列拆分后，因為標簽和資源池（多對多）的關系，資源池的一次作業拉取請求往往會涉及多個隊列。出于拉取效率的考慮，采用輪詢的方式依次對單隊列進行出隊操作，直到達到該次請求的作業數上限或所有可選隊列為空時返回結果。該方式可以避免同時對多個隊列加鎖，并且在前置環節會對多標簽進行隨機排序，降低多個請求同時操作一個隊列的競爭概率。

圖12 隊列拉取設計

3、組件分層設計

1）分層架構

圖13 組件架構設計

• 業務層：引入適配層，滿足組件開發中多樣化的需求場景，同時避免上層差異污染到下層。
• 系統交互層：設立統一的流程標準，保證引擎和組件交互過程的一致性，便于統一處理非功能性的系統優化。
• 執行資源層：提供多種資源策略，向上層屏蔽不同資源類型的差異。

2）標準的交互流程設計

在系統交互層，組件與引擎交互的過程中，有兩個環節是確定的，①組件作業的狀態機流轉，這涉及到組件執行的整個生命周期管理，若允許存在不同的狀態流轉關系，整個管理過程會十分混亂；②引擎對外提供的接口范圍，從服務間解耦的角度，對外提供的接口主要是組件作業維度的接口操作，不應該耦合任何組件內部的實現細節。

結合作業狀態機 + 引擎提供的接口，確定了組件執行基本的系統交互流程。利用模版模式，抽象出init()、run()、queryResult()、uploadArtifacts() 等必要方法供業務實現，整個交互流程則由系統統一處理，業務無需關心。

圖14 組件標準流程設計

3）擴展基礎能力

組件執行除了正常的執行流程外，隨著業務場景的豐富，還會涉及組件中止、回調（人工審批場景）等操作，這些操作的引入勢必會改變原先的交互流程。為了不增加額外的交互復雜度，在拉取作業環節，增加作業的事件類型（運行、中止、回調等事件），Worker根據拉取到的不同事件，執行相應的擴展邏輯。同時，引入新的擴展也不會影響到已有的交互流程。

圖15 組件擴展能力設計

基于上述擴展，我們可能更好地將一些通用能力下沉到Daemon Thread層。如結果查詢流程，通過守護線程的方式，取消了原先同步等待的查詢限制，這對于需要異步化處理的場景（如組件作業邏輯已執行完，僅在等待外部平臺接口返回結果）可以提前釋放資源，提高資源執行的利用率。并且，當執行資源故障重啟后，結果查詢線程會自動恢復待處理異步作業。這部分能力的支持在業務層是透明的，不改變整個交互流程。

4）引入適配器

業務雖可以通過必要方法完成自定義組件，但這些方法過于基礎，業務在一些特定場景下實現成本較高。如對于組件支持Shell的腳本化調用，業務其實僅需提供可執行的Shell即可，通用約定的方式，其他必要方法的實現都可以交由系統完成。

針對業務個性化的處理，采用適配器模式，通用引入不同Command（ShellCommand、xxCommand）來默認實現特定場景下的必要方法，降低業務的開發成本。同時，保持系統側流程的一致性，通過動態注入Command的方式，防止對業務個性化處理的耦合。

圖16 組件適配器設計

5）效果

目前已支持Shell組件、服務組件、容器組件等多種接入方式，平臺上已提供數百個組件，組件開發方涉及數十個業務線。組件庫覆蓋源碼域、構建域、測試域、部署域、人工審批域等多個環節，打通了研發過程所涉及的各個基礎工具。

圖17 組件庫

五、后續規劃

• 借助Serverless等云原生技術，探索更輕量、高效的資源管理方案，提供更精細化的資源策略，從資源的彈性、啟動加速、環境隔離三個方面為業務提供更優的資源托管能力。
• 面向組件開發者，提供從開發、上線到運營的一站式開發管理平臺，降低組件開發、運營成本，使更多工具方、個人開發者能參與其中，共同打造豐富多樣的業務場景，形成良性的組件運營生態。?