在底層共性技術服務和中臺業務服務能力具備后，上層應用可以根據可重用的服務快速的構建的，但是不可能所有場景都簡單的簡單調用一個API接口服務就能夠實現。當存在一定業務規則需要處理的時候，往往都涉及到調用多個API接口服務，中間還涉及到基礎的邏輯處理，判斷分支往往才能夠完成。

[[415958]]

如果讓前端應用開發來處理這種事情，又變成了需要大量編寫腳本代碼，而且存在共性領域服務邏輯對外泄露的問題。

服務編排實際上就是對基礎的業務處理流程，步驟，規則邏輯進行封裝，然后提供一個封裝后的組合服務或領域服務API接口能力給前端應用開發。這個和傳統SOA架構里面談到的通過BPEL來進行SOA服務編排思路完全一致。

當前微服務編排引擎來源

對于開源的微服務編排引擎，最早大家比較熟悉的是Netfix Conductor，我在前面也專門寫過文章分析和說明，但是這個開源版本本身更多的是面向開發人員使用，很難做到前端的可視化靈活配置，而且也沒有可視化設計能力，只有編排完成后的可視化監控。

從當前主流的一些微服務編排引擎來看，主要包括如下幾類發展演進。

其一是從傳統的工作流引擎或BPM引擎積累開始做微服務編排引擎，比如當前開源的Zeebe，其開發團隊即來源于知名的Activiti工作流和BPM引擎。

其二是傳統的ESB服務總線上層，對于ESB總線本身就有輕量服務編排功能，因此從ESB總線來發展微服務編排引擎。

其三是基于分布式任務調度系統，自動化事件事物觸發編排發展出來的微服務編排引擎，要明白微服務編排最終核心仍然是各個活動或任務的處理。類似當前在物聯網領域應用廣泛的Node-Red編排引擎屬于這種方式。

如何理解微服務編排場景?

當我重新思考這個問題的時候，進一步將編排場景進行分類理解。

首先第一類就是簡單的服務組合，服務拆分，數據裁剪，數據映射等，這些內容可以通過服務編排來解決，比如輸入一個供應商編碼，同時調用兩個API接口服務，一個是查詢供應商基本信息，一個是查詢供應商的訂單明細列表信息。在調用返回后將結果整合為一個Json輸出給調用方。

對于這類場景實際就是對應到傳統ESB輕量服務編排能力，并不涉及到復雜的業務規則，業務邏輯處理，也不涉及到類似BPEL自動化業務流的處理等。

其次是基于業務處理流程的多個服務編排處理，這個場景和傳統SOA架構里面的BPEL很類似，就是要完成一個業務功能，你會發現本身就需要調用多個接口才能夠完成，而且這些API接口調用本身有先后關系，有調用邏輯和分支判斷，上游API接口服務的輸出往往會變成下游API服務的輸入，形成核心的串行邏輯結構。因此你需要通過一個編排功能將多個服務編排在一起，最終暴露一個服務。

對于這類場景一個典型就是一個前端功能實現，當完成相關書籍錄入后，點擊一個按鈕觸發事件，傳統代碼開發方法一定是在按鈕觸發事件方法中編寫具體的代碼實現邏輯，這個邏輯本身也涉及到調用多個API接口服務，當然也存在分支判斷邏輯等。

而新的低代碼開發或Serverless無服務器化下，我們更加希望點擊代碼只需要調用一個編排完成的組合服務能力即可。前端開發人員并不需要知道內部多個API服務編排組合的規則邏輯。那么這個場景下就需要先通過微服務編排引擎形成一個組合服務API，然后再暴露給前端應用使用。

我們最近做了什么事?

最近在實現微服務編排能力的時候，前期也進行了大量的選型，最早的計劃是整體從零開始，基于已有的圖形化設計器的基礎來做服務編排引擎。

但是分析完成后整體從零開始做仍然難度不小，不僅僅是API服務本身的組裝，拆分，規則邏輯處理，更加重要的是需要底層有一個完整的任務調度引擎或事件處理引擎。對于消費方系統來說看到的是一個組合服務API，但是其內部本身是多個服務組裝，組合完成的，內部已經變成一個消息或事件驅動的異步處理系統。

因此在這個過程中你需要去處理任務調度，處理異常容錯，處理分布式事務和回退機制。所有的這些底層邏輯要從零開始實現本身還是有一定難度的。

Node-RED是一種基于流的編程工具，它有一個可視化編輯器，允許將節點連接在一起創建流。滿足微服務編排最基礎的可視化服務編排需求。Node-RED最初是IBM在2013年末開發的一個開源項目，以滿足他們快速連接硬件和設備到Web服務和其他軟件的需求——作為物聯網的一種粘合劑，它很快發展成為一種通用的物聯網編程工具。

因此通過選型后，最終選擇了Node-Red來實現微服務編排，當時我們規劃的接口服務串行，并行，數據合并整合，規則處理，異常捕獲，日志記錄等需要都能夠實現。

整體來講Node-Red應對簡單的服務組裝，組合沒有任何問題。但是如果存在類似BPEL一樣的自動化業務流處理，仍然不合適。畢竟Node-Red這個開源項目誕生的目的仍然是為了應對物聯網領域常見的任務和事件處理，重點是多個任務或事件的編排而非類似業務系統功能開發中的流程編排。

微服務下Http API接口編排關鍵點

我們這里談的微服務編排更多的是指對微服務暴露的Http API接口的可視化編排和組裝。這個是談論這個點的前提。

對于微服務編排引擎底層前面已經談到重點是消息中間件，分布式任務調度和執行邏輯，狀態機等。那么在這個底層邏輯上面進行微服務API編排的時候還需要具備或擴展哪些關鍵能力，初步思考如下。

其一是對于Json格式的處理。

也就是服務編排中會經常遇到Json格式的拆分，合并，數據映射等操作，一個編排引擎必須在這個方面相當靈活。Json格式的字符串本身也是存在規則，是可以模板化的，只有模板化后才方便進行處理。同時一個Http接口調用本身存在輸入，輸入的內容在后續多個編排節點都可能使用到，因此還需要支持輸入信息的參數化處理。

這些參數對于整個組合服務運行實例中的全局參數，在后續任何節點都可以引用到。

比如當獲取訂單信息的時候，我們希望同時返回訂單對應的供應商的基本信息。也就是先調用獲取訂單信息，拿到供應商編碼后再去調用獲取供應商信息，最好將供應商信息結果拼裝到整個訂單信息中返回。

//調用GetOrderInfo獲取Order信息  
//根據返回的supplierid發起對GetSuplier接口調用  
//將返回的信息作為子對象拼裝到完整Json里面     
       orderInfo  
          {  
               orderid  
               ordername  
               supplierid  
                   {  
                        suppliername:  
                        suppliertype:  
                        address:  
                         contactphone:  
                    }  
            }  

可以看到，編排的時候同時調用多個API接口并不難，難的地方是如何完成結果的映射，快速，靈活的組裝，這個能力反而更加關鍵。

在傳統的SOA服務編排里面，經常會采用類似Xslt模板來完成數據的映射，組裝等操作，這種參數化模板映射的思路完全可以借鑒。

其二就是業務規則和邏輯處理

在常規的SOA服務組裝中，一般會將BPEL和規則引擎結合，來實現復雜業務規則和邏輯的處理。而對于微服務編排，本身就是一種偏輕量的編排，不適合處理過于復雜的業務規則和邏輯。

因此服務可視化編排中，能夠支撐最簡單額分支判斷邏輯，條件組合邏輯就可以了。而對于更加復雜的邏輯建議是單獨先實現一個規則處理的原子服務API接口，再應用到微服務編排中去。

對于低代碼開發平臺的應用，我在前面也提到過這個觀點。

即首先低代碼開發平臺應該是基于服務分層的思路，將前端開發和后端服務能力區別開，通過服務層來徹底解耦。其次就是在服務層提供可視化服務編排能力，提供編排后的組合服務給前端應用調用，減少前端應用調用難度。

但是如果出現了復雜的業務規則處理邏輯，這個就不要在服務編排里面去處理，還是單獨實現一個規則處理API接口服務，再暴露出來給上層應用或編排設計器使用。

其三就是分布式事務處理機制

由于將多個微服務API接口服務編排在一起，一定會產生分布式事務問題。

當前的編排技術實際本身又為了完全同步等待的方式和異步類似任務事件和狀態機處理機制。在前面我們談到兩個場景。

如果是簡單的服務組合，拆分，可以用同步模式。但是如果是類似業務流程處理的多個服務串行編排，建議是采用異步任務事件處理機制。底層也需要消息中間件和中間態數據的存儲機制來進行支撐。

實際在微服務編排里面的分布式事務處理，最佳的方式仍然是基于冪等規則下的事務補償。

我們一個最簡單的例子。在訂單保存的時候需要扣減庫存。

這個時候涉及到SaveOrderAPI接口和FreezeStockAPI兩個接口，對于扣減庫存有一個對應的逆操作接口ReleaseStockAPI。

那么你在進行微服務編排的時候實際需要將這三個接口都編排進去，而且還需要增加判斷規則邏輯，即當SaveOrderAPI失敗的時候進行ReleaseStockAPI，庫存扣減回退操作。

那么是否有一種方式將這個過程簡化。

即涉及到分布式事務的場景，我們對任何一個API接口服務都需要同時配置這個服務的逆操作回退API接口服務。那么當下游服務操作在出現異常的時候，由整個微服務調度機制通過調研逆向API接口，自動發起多上游服務的回退操作。

如果回退操作仍然失敗，那么發送異常處理通知或郵件，通知人工介入操作。

第四點是微服務鏈路監控

在談微服務的時候經常會談到微服務鏈路監控，簡單來說就是前端是調用一個按鈕處理，但是按鈕方法的實現邏輯里面可能會調用多個微服務API，因此需要對整個鏈路進行監控，以方便進行性能問題分析，異常問題排查。

在使用微服務編排后，按鈕原來的處理邏輯已經轉換到微服務編排和設計里面去完成。一個編排后的微服務在內部可能會調用多個微服務API接口，形成微服務API的接口調用鏈。而這個內容仍然需要提供完整的監控，日志查看能力。

這個和工作流引擎里面的流程監控類似。

即微服務編排完成的也是一個流程，是自動化的業務流，中間調用多個API接口服務，因此需要對整個自動化業務流做到端到端監控。通過微服務流程實例進入后，能夠詳細看到當前執行到哪個環節，如果出現異常也能夠快速地排查到具體的錯誤異常日志。