零代碼平臺(tái)中的服務(wù)編排思路（零代碼平臺(tái)中的服務(wù)編排思路是什么）

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

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

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

這樣雖然能夠滿足需求，但會(huì)有兩個(gè)問題：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Orchestration（編制）：通過一個(gè)可執(zhí)行的流程來協(xié)同內(nèi)部及外部的服務(wù)交互，通過流程來控制總體的目標(biāo)、涉及的操作、服務(wù)調(diào)用順序。這種模式必須有一個(gè)流程控制服務(wù)，用來接收請求，組織服務(wù)間的調(diào)用，并最終完成業(yè)務(wù)邏輯。這種方案中大多是同步調(diào)用，雖然在某個(gè)時(shí)刻能夠很清晰的知道服務(wù)的執(zhí)行情況，但當(dāng)業(yè)務(wù)復(fù)雜，服務(wù)很多的情況下，在控制服務(wù)中會(huì)存在大量的耦合，難以維護(hù)；
• Choreography（編排）：通過消息的交互序列來控制各個(gè)部分資源的交互，參與交互的資源都是對(duì)等的，沒有集中的控制?？梢钥醋饕环N消息驅(qū)動(dòng)模式，或者說是訂閱發(fā)布模式，不同的服務(wù)之間通過消息機(jī)制串聯(lián)起來，這種方式大多都是異步的。好處就是耦合度低，但也會(huì)帶來一些問題，比如：業(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)其實(shí)就是一個(gè)適配網(wǎng)關(guān)，比如對(duì)于 Web端，可以一個(gè)頁面同時(shí)發(fā)起幾十個(gè)請求，而對(duì)于移動(dòng)端，最好是一個(gè)頁面就幾個(gè)請求。而采用API 網(wǎng)關(guān)，后面的微服務(wù)可以是相同的。但只能應(yīng)對(duì)一些邏輯簡單的場景。

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

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

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

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

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

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

整體過程如下圖：

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

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

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

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

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

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

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

我們的補(bǔ)償機(jī)制分為兩種：

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

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

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

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