[[433191]]

隨著企業數字化轉型的進程加快，零代碼平臺的的應用越來越廣泛，逐漸被企業級的客戶認可和接受。

零代碼顧名思義就是在不寫代碼的情況下可以搭建應用和功能來滿足客戶的需求，但事實是殘酷的，真實的客戶需求永遠比我們想象的要復雜，傳統的零代碼產品需要提供各種擴展能力，比如可以讓開發人員編寫復雜的業務邏輯代碼，并對接到平臺中。

這樣雖然能夠滿足需求，但會有兩個問題：

• 客戶的需求隨時可能發生變化，需求一變就需要進行代碼的修改;
• 一線業務人員無法直接在平臺中進行調整，一些小的改動都需要進行開發、測試、發布的流程。

這時就需要服務編排了，服務編排是什么，下面舉兩個例子：

1、倉儲物流出庫先進先出更新庫存量

在倉儲物流系統中，商品的入庫有時間的先后順序，出庫時需要遵循先入庫的先進行出庫，如下圖所示：

在不具備服務編排的系統中，搭建好功能后，還需要編寫處理出庫邏輯的 API 接口方法和系統中的某個方法對接起來。這個工作只能由開發人員來完成。

使用服務器編排工具，就能輕松地可視化拖拽就能實現了，如下圖：

2、人員離職后需要處理一系列的操作，比如：

修改 HR 系統中對應用戶的狀態;

刪除企業微信中的賬號;

禁用郵箱;

發送通知。

使用服務編排可以很輕松就能實現，前提是要有豐富的業務組件：

服務編排其實就是一系列單個的業務組件通過流程的方式進行組合起來，最終達到業務的目的，流程中可以控制分支邏輯或循環邏輯。

提到流程，我們印象里都是 OA、CRM 等系統中的各種請假審批流、合同審批流等。事實上，廣義上的工作流是對工作流程及其各操作步驟之間業務規則的抽象、概括、描述。

簡單的說，為了實現某個業務目標，抽象拆解出來的一系列步驟及這些步驟之間的協作關系，就是工作流。也就是上面所說的業務服務的編排流程。

服務編排引擎的總體架構圖如下：

在近些年比較火的微服務中也存在著服務的編排，常見的有三種模式：

• Orchestration(編制)：通過一個可執行的流程來協同內部及外部的服務交互，通過流程來控制總體的目標、涉及的操作、服務調用順序。這種模式必須有一個流程控制服務，用來接收請求，組織服務間的調用，并最終完成業務邏輯。這種方案中大多是同步調用，雖然在某個時刻能夠很清晰的知道服務的執行情況，但當業務復雜，服務很多的情況下，在控制服務中會存在大量的耦合，難以維護;
• Choreography(編排)：通過消息的交互序列來控制各個部分資源的交互，參與交互的資源都是對等的，沒有集中的控制。可以看作一種消息驅動模式，或者說是訂閱發布模式，不同的服務之間通過消息機制串聯起來，這種方式大多都是異步的。好處就是耦合度低，但也會帶來一些問題，比如：業務流程是通過訂閱的方式來體現的，很難直接監控每筆業務的處理，因此難于調試;由于沒有預定義流程，所以很難在事前保證流程正確性，基本靠事后分析數據來判斷等;
• API網關：API網關是一種簡單的接口聚合/拆分的方式：業務組件的請求后先到達網關，網關調用各微服務，并最終聚合/拆分需反饋的結果。API網關其實就是一個適配網關，比如對于 Web端，可以一個頁面同時發起幾十個請求，而對于移動端，最好是一個頁面就幾個請求。而采用API 網關，后面的微服務可以是相同的。但只能應對一些邏輯簡單的場景。

結合上面方式各自的優點，服務編排引擎的實現思路如下：

1、一個服務的編排由一個或多個業務服務組件組成;

2、一個業務服務組件可以拆解為一個或多個原子服務;

3、每個原子服務可以抽象成一個通用模型;

4、每個原子服務提供 API 接口和事件監聽機制;

5、每個原子服務根據持久化適配器將數據更新到訂閱的持久化組件中。

整體過程如下圖：

服務組件的調用是同步還異步，我們把這個決定權交給用戶，可以通過設置的方式來進行，并提供重試機制，確保數據的最終一致性。

每個服務組件都有自己的入參和出參，在一個服務編排的請求上下文中會隨著執行的階段不同，動態組織參數，參數適配器會根據名稱、類型等進行自動適配，當然也能根據在設置界面中的手動綁定進行適配。

原子服務只做一件事情，通過一個原子服務或多個原子服務，可以組裝出來各種不同功能的業務組件，通過事件監聽機制讓服務之間、組件之間可以徹底解耦，以便能夠靈活組裝。

隨著服務和組件的增多，調用鏈會變得越來越復雜，當一個服務編排整個處理完后，調用鏈會形成一個復雜網絡，這對排查問題造成很大的麻煩。我們采用全鏈路跟蹤來解決這個問題，在一個完整的業務調用開始時，會生成一個唯一 ID，這個 ID 會一直存儲在調用上下文中。

上面說到原子服務會有兩種方式被執行，API 和事件監聽的方式，如果是 API ，ID 可以放在請求頭中傳遞到下一層，如果是事件監聽，ID 會做為消息體的一部分進行傳遞。

假設現在用戶已編排了一個復雜的業務，服務組件之間的調用有同步也有異步，當某個環節出現問題時候，我們需要保證數據的最終一致性。常用的一種方式就是提供補償機制。

補償模式核心思想是：針對每個操作，都要注冊一個與其對應的補償(撤銷)操作，一般來說操作本身和其補償操作會在一個事務里完成，當其后續操作失敗后，需要按相反順序完成前面注冊的所有撤銷操作。

我們的補償機制分為兩種：

1、特定服務組件上的獨立設置;

2、全局控制調用補償，所有被調用服務會記錄到一個列表中，如果出現需要重試或者回滾的操作，再從列表中獲取出來進行相應的操作。 

在補償模式中，要求能夠提供補償的服務的操作必須支持冪等，否則當多次執行的時候就會出現數據錯誤。正常情況下，所有的補償都是自動觸發的，但有些特殊的場景還是需要人工干預，在調用失敗的日志列表中管理員可以進行手動重試。