先打個廣告，我們的第三場零代碼實踐的直播在本周五（ 11 月 5 日 ）晚8點準時開始，掃描下面二維碼，直接預約直播，到時間微信會自動提醒。

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

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

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

1、客戶的需求隨時可能發(fā)生變化，需求一變就需要進行代碼的修改；

2、一線業(yè)務人員無法直接在平臺中進行調(diào)整，一些小的改動都需要進行開發(fā)、測試、發(fā)布的流程。

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

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

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

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

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

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

• 修改 HR 系統(tǒng)中對應用戶的狀態(tài)；
• 刪除企業(yè)微信中的賬號；
• 禁用郵箱；
• 發(fā)送通知。

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

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

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

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

服務編排引擎的總體架構(gòu)圖如下：

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

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

結(jié)合上面方式各自的優(yōu)點，服務編排引擎的實現(xiàn)思路如下：

1、一個服務的編排由一個或多個業(yè)務服務組件組成；

2、一個業(yè)務服務組件可以拆解為一個或多個原子服務；

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

4、每個原子服務提供 API 接口和事件監(jiān)聽機制；

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

整體過程如下圖：

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

每個服務組件都有自己的入?yún)⒑统鰠?，在一個服務編排的請求上下文中會隨著執(zhí)行的階段不同，動態(tài)組織參數(shù)，參數(shù)適配器會根據(jù)名稱、類型等進行自動適配，當然也能根據(jù)在設置界面中的手動綁定進行適配。

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

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

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

假設現(xiàn)在用戶已編排了一個復雜的業(yè)務，服務組件之間的調(diào)用有同步也有異步，當某個環(huán)節(jié)出現(xiàn)問題時候，我們需要保證數(shù)據(jù)的最終一致性。常用的一種方式就是提供補償機制。

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

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

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

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

在補償模式中，要求能夠提供補償?shù)姆盏牟僮鞅仨氈С謨绲?，否則當多次執(zhí)行的時候就會出現(xiàn)數(shù)據(jù)錯誤。正常情況下，所有的補償都是自動觸發(fā)的，但有些特殊的場景還是需要人工干預，在調(diào)用失敗的日志列表中管理員可以進行手動重試。

如果您有什么意見或建議，歡迎私信我。