零代碼平台中的服務編排思路

語言: CN / TW / HK

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

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

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

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

1、客户的需求隨時可能發生變化,需求一變就需要進行代碼的修改;

2、一線業務人員無法直接在平台中進行調整,一些小的改動都需要進行開發、測試、發佈的流程。

這時就需要服務編排了,服務編排是什麼,下面舉兩個例子:

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

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

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