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

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

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

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

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

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

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

1、倉儲物流出庫先進(jìn)先出更新庫存量

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整體過程如下圖：

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

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

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

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

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

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

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

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

1、特定服務(wù)組件上的獨立設(shè)置；

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

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

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