目前，市面上的流水線/工作流產品層出不窮，有沒有一款工作流引擎，能夠同時滿足：

- 支援各種任務執行時，包括 K8s Job、K8s Flink、K8s Spark、DC/OS Job、Docker、InMemory 等？
- 支援快速對接其他任務執行時？
- 支援任務邏輯抽象，並且快速地開發自己的 Action？
- 支援巢狀流水線，在流水線層面進行邏輯複用？
- 支援靈活的上下文引數傳遞，有好用的 UI 以及簡單明確的工作流定義？
- ······

那麼，不妨試試 **Erda Pipeline** 吧～

**Erda Pipeline** 是一款自研、用 Go 編寫的工作流引擎。作為基礎服務，它在 Erda 內部支撐了許多產品：
  
- CI/CD
- 快資料平臺
- 自動化測試平臺
- SRE 運維鏈路
- ……

Erda Pipeline 之所以選擇自研，其中最重要的三點是：
   
1. 自研能更快地響應業務需求，進行定製化開發；
2. 時至今日，開源社群還沒有一個實質上的流水線標準，各種產品百花齊放；
3. K8s、DC/OS 等的 Job 實現都偏弱、上下文傳遞缺失，無法滿足我們的需求，更不用說靈活好用的 Flow  了，例如：巢狀流水線。
 
本文我們將主要從架構層面對 Pipeline 進行剖析，和大家一起來深入探索 Pipeline 的架構設計。主要內容包括以下幾個部分：

- 整體架構
- 內部架構
- 水平擴充套件
- 分散式架構
- 功能特性
- 實現細節
    
# 整體架構

![](http://img.blog.itpub.net/blog/2022/05/10/3bc09e7f80aa2e13.png?x-oss-process=style/bb)

Pipeline 支援靈活的使用方式，目前支援  UI 視覺化操作、OPENAPI 開放介面、CLI 命令列工具幾種方式。

協議層面，在 Erda-Infra 微服務框架的加持下，以 HTTP 和 gRPC 形式對外提供服務：在早期的時候，我們只提供了 HTTP 服務，由於 Erda 平臺本身內部是微服務架構，服務間呼叫就需要手動編寫 HTTP 客戶端，不好自動生成，麻煩且容易出錯。後來我們改為使用 Protobuf 作為 IDL（Interface Define Language），在 Erda-Infra 中自動生成 gRPC 的客戶端呼叫程式碼和服務端框架程式碼，內部服務間的呼叫都改為使用 gRPC 呼叫。

在中介軟體依賴層面，我們使用 ETCD 做分散式協調，用 MySQL 做資料持久化。ETCD 我們也有計劃把它替換掉，使用 MySQL 來做分散式協調。

最關鍵的任務執行時（Task Runtime）層面，我們支援任務可以執行在 K8s、DC/OS（分散式雲 OS，在 2017-2019 年非常火）、使用者本地 Docker 環境等。

我們還有開放的任務擴充套件市場，在平臺級別內建了非常多的流水線任務擴充套件，開箱即用。同時，使用者也可以開發企業/專案/應用/個人級別的任務擴充套件，這部分功能在程式碼層面已經完全支援，產品層面正在開發中，在後續迭代中很快就可以和大家見面。

# 內部架構

![](http://img.blog.itpub.net/blog/2022/05/10/67bbb00f02539f41.png?x-oss-process=style/bb)

使用 Erda-Infra 微服務框架開發，功能模組劃分清晰：

- Server 層包括業務邏輯，對 Pipeline 來說業務就是建立、執行、重試、重試失敗節點等。
- Modules 層提供不含業務邏輯的公共模組，其餘兩層均可呼叫，包括預校驗機制、定時守護程式、YAML 解析器、配置管理、事件管理等。

Erda Pipeline 一直在踐行：“**把複雜留給自己，把簡單留給別人**”。
  
在 Pipeline 中，我們對一個任務執行的抽象是 ActionExecutor。
    
- Engine 層負責流水線的推進，包括：
  - Queue Manager 佇列管理器，支援佇列內工作流的優先順序動態調整、資源檢查、依賴檢查等
  - Dispatcher 任務分發器，用於將滿足出隊條件的流水線分發給合適的 Worker 進行推進
  - Reconciler 協調器，負責將一條完整的流水線解析為 DAG 結構後進行推進，直至終態。
   
- 模組內部使用外掛機制，對接各種任務執行時。
- AOP 擴充套件點機制（借鑑 Spring），把程式碼關鍵節點進行暴露，方便開發同學在不修改核心程式碼的前提下定製流水線行為。
  - 目前已經有的一些擴充套件點外掛，譬如自動化測試報告巢狀生成、佇列彈出前檢查、介面測試自動登入保持等。
  - 這個能力後續我們還會開放給呼叫方，包括使用者，去做一些有意思的事情。
   
- 統一使用 Event，封裝了 WebHook / WebSocket / Metrics。
     
# 水平擴充套件

![](http://img.blog.itpub.net/blog/2022/05/10/53d2467448577ab5.png?x-oss-process=style/bb)
 
隨著 Pipeline 需要支撐的業務場景和資料量與日俱增，單例項的 Pipeline 穩定性和推進效能面臨著挑戰。
   
Pipeline 的多例項方案如下：

- Leader & Worker 模式，兩者在部署上不區分狀態，僅為 Replicas 多例項：
  - 使用 ETCD 選舉，每個例項都可以是 Leader。
  - 只有 Leader 開啟 Queue Manager 和 Dispatcher，分發任務給 Worker。
  - Leader 本身也可以作為 Worker，支援單節點部署模式，Leader 必須開啟 Reconciler。
  
- Dispatch 使用有界負載的一致性雜湊演算法：
  - 使用一致性雜湊來分配任務。但一致性雜湊會超載，例如某些熱點內容會持續打到一個節點上。
  - 有界負載演算法（The bounded-load algorithm）：
    1. 只要伺服器未過載，請求的分配策略與一致性雜湊相同。
    2. 過載伺服器的溢位負載將在可用伺服器之間分配。
  - Pipeline 例項增減時，已經被分配的流水線不重新分配，儘可能減少切換成本，防止重複推進；新增的流水線使用一致性 Hash 演算法進行分配。
     
在之前，我們使用過分散式鎖的方案來做多例項協調。和選舉比起來，競爭會更大，在具體實現裡，如果想要多例項同時推進流水線，那競爭的資源就是流水線 ID。每個 ID 會請求一個分散式鎖，而且這個分散式鎖是阻塞性的，保證每個流水線 ID 一定會被推進，天然做了多節點重試。
   
# 分散式架構

![](http://img.blog.itpub.net/blog/2022/05/10/90f7439147ee554b.png?x-oss-process=style/bb)

該分散式架構是典型的 AP 模型，資料層面遵循最終一致性。
  
這套分散式架構的核心目標（典型場景）是在網路分割槽的情況下，保證邊緣叢集的定時任務正常執行。
  
我們來對比一下**原有部署架構**（執行時以 K8s 為例）：
    
- 中心 Pipeline 直接負責流程推進，呼叫邊緣 K8s 建立 Job。
- 當網路分割槽時，原有部署架構下，定時任務無法正常執行。
  
**分散式架構**：
  
- 中心下發任務定義，由 Edge Pipeline 負責推進，直連 K8s，更加穩定。
- 在網路分割槽恢復時，主動上報執行資料，實現資料最終一致性。
    
在程式碼層面，我們使用同一份程式碼構建出同一個映象，透過配置（不同的部署模式）使得各個例項各司其職。
    
另外，在資料同步時，我們遇到了前端 JavaScript Number 型別 53位最大值問題，對 SnowFlake ID 進行了 64bit -> 53bit 的改造，在保證唯一性的前提下，儘可能地增加可用性（生命週期約為 10 年，同時支援 4096 個分散式節點，每 10ms 可生成 64 個 ID）。
   
# 功能特性
  
這裡簡單列舉一些比較常見的功能特性：
  
- 配置即程式碼
- 擴充套件市場豐富
- 視覺化編輯
- 支援巢狀流水線
- 靈活的執行策略，支援 OnPush / OnMerge 等觸發策略
- 支援工作流優先佇列
- 多維度的重試機制
- 定時流水線及定時補償功能
- 動態配置，支援“值”和“檔案”兩種型別，均支援加密儲存，確保資料安全性
- 上下文傳遞，後置任務可以引用前置任務的“值”和“檔案”
- 開放的 OpenAPI 介面，方便第三方系統快速接入

# 一些實現細節
## 如何實現上下文傳遞(值引用)

在一條流水線中，節點間除了有依賴順序之外，一定會有資料傳遞的需求。
  
值引用：
  
- 每個節點的特殊輸出(按格式寫入指定檔案或者列印到標準輸出)會被儲存在 Pipeline 資料庫中；
- 後續節點透過 outputs 語法宣告的表示式會在節點開始執行前被替換為真正的值。
   
舉例：
  
![](http://img.blog.itpub.net/blog/2022/05/10/b65e6a2c585a0f26.png?x-oss-process=style/bb)

如圖所示：第一個節點 repo 拉取程式碼；第二個節點 build erda 則是構建 Erda 專案。
  
在例子中，第二步構建時同時用到了 “值引用” 和 “檔案引用” 兩種引用型別，是進依次入程式碼倉庫，指定 GIT_COMMIT 進行構建。

![](http://img.blog.itpub.net/blog/2022/05/10/e0633dab10dc3552.png?x-oss-process=style/bb)
 
## 如何實現上下文傳遞(檔案引用)

- 檔案引用比值引用複雜，因為檔案的資料量比值大得多，不能儲存在資料庫中，而是儲存在卷中。
- 這裡又根據是否使用共享儲存而分為兩種情況，兩者的區別在於申請的卷的型別和個數。
- 對於流水線使用者而言，沒有任何區別。

![](http://img.blog.itpub.net/blog/2022/05/10/34de92750b7ff6eb.png?x-oss-process=style/bb)
使用共享儲存

![](http://img.blog.itpub.net/blog/2022/05/10/51454b1d14e8ea22.png?x-oss-process=style/bb)
不使用共享儲存

## 如何實現快取加速
  
在許多流水線場景中，同一條流水線的多次執行之間是有關聯的。如果能夠用到上一次的執行結果，則可以大幅縮短執行時間。
  
典型場景是 CI/CD 構建，我們以 Java 應用 Maven 構建舉例：不但同一條流水線不同的多次執行可以複用 ${HOME}/.m2 目錄(快取目錄)，甚至同一個應用下的多個分支之間都可以使用同一個快取目錄，就像本地構建一樣～
  
舉例：

![](http://img.blog.itpub.net/blog/2022/05/10/0e106f81566c5cf7.png?x-oss-process=style/bb)
   
仍然使用前面的例子，在第二步 build erda 里加上 cache 即可。

![](http://img.blog.itpub.net/blog/2022/05/10/535d89d4466b9e3b.png?x-oss-process=style/bb)

## Action Agent
  
在 Pipeline 裡，每個節點都會對應一個 Action 型別，並且在擴充套件市場中都可以找到。為了更加方便 Action 開發者進行開發，我們提供了很多便捷的機制。如：
    
- 對敏感日誌進行脫敏處理，保證資料安全
- 無感知的錯誤分析和資料上報
- 檔案變動監聽及實時上報
- ……
   
上述所有機制都是由 Action Agent 程式完成的，它是一個靜態編譯的 Go 程式，可以執行在任意 Action 映象中。Agent 完整的執行鏈路如下：

![](http://img.blog.itpub.net/blog/2022/05/10/2946191890aac80b.png?x-oss-process=style/bb)

## Action Executor 擴充套件機制
  
Pipeline 之所以好用，是因為它提供了靈活一致的流程編排能力，並且可以很方便地對接其他單任務執行平臺，這個平臺本身不需要有流程編排的能力。

在 Pipeline 中，我們對一個任務執行的抽象是 ActionExecutor。一個執行器只要實現單個任務的建立、啟動、更新、狀態查詢、刪除等基礎方法，就可以註冊成為一個 ActionExecutor：
  
- 恰當的任務執行器抽象，使得 Batch/Streaming/InMemory Job 的配置方式和使用方式完全一致，流批一體，對使用者遮蔽底層細節，做到無感知切換。
- 在同一條流水線中，可以混用各種 ActionExecutor。
      
排程時，根據任務型別智慧排程到對應的任務執行器上，包括 K8sJob、Metronome Job、Flink Job、Spark Job 等等。

![](http://img.blog.itpub.net/blog/2022/05/10/41f6da038c76c9d1.png?x-oss-process=style/bb)
Go 介面定義

![](http://img.blog.itpub.net/blog/2022/05/10/58500ccab6fc72b8.png?x-oss-process=style/bb)

## AOP 擴充套件點機制
  
AOP 擴充套件點機制是借鑑 Java 裡 Spring 的概念應運而生的。
   
我們把程式碼關鍵節點進行暴露，方便開發同學在不修改核心程式碼的前提下定製流水線行為。AOP 擴充套件點機制已經使用 Erda Infra 的模組化思想重構，整個擴充套件點的外掛開發和編排更為靈活，如下圖所示：

![](http://img.blog.itpub.net/blog/2022/05/10/d6606fe0b1238058.png?x-oss-process=style/bb)
AOP 在 Pipeline 內部的使用

這個能力後續我們還會開放給使用者，讓使用者可以在 pipeline.yaml 中使用程式語言宣告和編排擴充套件點外掛，更靈活地控制流水線行為。

----

我們致力於決社群使用者在實際生產環境中反饋的問題和需求，
如果您有任何疑問或建議，
歡迎關注**【爾達Erda】公眾號**給我們留言，
加入 Erda 使用者群參與交流或在 Github 上與我們討論！

深入探索雲原生流水線的架構設計

相關文章