今天談下傳統(tǒng)ESB服務總線里面的可視化服務設計，服務組合編排和微服務里面的服務編排。對于服務組合編排，實際上我們看到有幾個不同的場景。

• 單服務可視化設計-僅僅針對一個服務實現(xiàn)
• 服務組合編排-實現(xiàn)多個服務的組合形成一個新的服務
• 業(yè)務流程編排-通過服務組合編排實現(xiàn)要給完整的業(yè)務流程

對于業(yè)務流程編排可以看到更多的是通過類似BPEL業(yè)務流程設計器來完成，因此今天主要介紹下傳統(tǒng)ESB服務總線里面的單個服務設計，多服務組合設計編排，同時再介紹下NetflixConductor微服務編排的開源實現(xiàn)。

單個服務的可視化設計

圖片

單個服務的可視化設計可以理解為實現(xiàn)單個服務的可視化服務設計，其中包括了服務適配，路由，數(shù)據(jù)映射，協(xié)議轉(zhuǎn)換等常見的編排節(jié)點和組件。

對于單服務設計可能用到的組件，我們基于服務集成場景，主要可以分為服務發(fā)布類組件，服務適配類組件，數(shù)據(jù)映射類組件。具體的組件包括了：

服務發(fā)布類組件(只需要支持SOAP WS服務和Rest WS服務即可）

1. SOAP Proxy WS組件：發(fā)布代理服務
2. SOAP Business WS組件：發(fā)布業(yè)務服務，銜接原始的業(yè)務服務地址
3. Rest Proxy WS組件：發(fā)布基于Rest風格的代理服務
4. Rest Business WS組件：發(fā)布業(yè)務服務，銜接原始的Rest業(yè)務服務地址
5. SOAP WS Request組件和 SOAP WS Response組件
6. Rest WS Request組件和 Rest WS Response組件

適配器組件

1. DBSqlQuery組件：實現(xiàn)對數(shù)據(jù)庫的Sql數(shù)據(jù)查詢能力。
2. DBSqlInsertOrUpdate組件：實現(xiàn)對數(shù)據(jù)庫的Insert或Update操作適配能力。
3. DBStoreProc組件：實現(xiàn)對數(shù)據(jù)庫存儲過程的適配能力。
4. FTPInput或FileInput組件：實現(xiàn)對源端的數(shù)據(jù)獲取能力
5. FTPOutput或FileOutput組件：實現(xiàn)對FTP服務器目標端的適配能力
6. JMSInput組件：實現(xiàn)對JMS寫入能力
7. JMSOutput組件：實現(xiàn)對JMS的消費和訂閱能力

數(shù)據(jù)映射類組件

1. XMLMapping組件：實現(xiàn)兩個XML結(jié)構(gòu)之間的數(shù)據(jù)映射能力
2. tMapping組件：實現(xiàn)ETL時候兩個數(shù)據(jù)集之間的數(shù)據(jù)映射能力

基于以上組件我們可以來看，常見的服務集成場景用上面的設計器組件基本就能夠滿足，同時實現(xiàn)最簡單額設計組件之間的組合和連接。而設計器本身是一個設計態(tài)的東西，因此只需要將設計完成的內(nèi)容，即設計元數(shù)據(jù)存儲為一個獨立的XML文件即可。

后續(xù)基于設計文件要做的就是進行實際的服務封裝和部署，而這個時候才需要將設計器的內(nèi)容進行解析，進行動態(tài)的服務封裝和部署工作。以實現(xiàn)服務設計態(tài)和服務運行態(tài)的自動銜接能力。

多個服務組合編排

圖片

服務組合編排是服務組合，服務組裝等，希望通過服務編排能夠完成這些事情，而不是簡單的完成單一服務的設計和開發(fā)。即將多個原子服務組合或組裝在一起，最終形成一個新的服務并提供的能力。我們舉例來說明下。

比如存在A，B，C三個原子服務，我們通過服務編排形成一個新的D服務。

三個原子服務全部是查詢服務，希望組裝一個新服務，一次返回A，B，C三個服務查詢結(jié)果

這個即我們說的服務組合能力，比如我們可以對合同基本信息查詢，合同條款信息查詢，合同執(zhí)行信息查詢?nèi)齻€基本原子服務進行組合，最終返回一個服務綜合信息查詢的服務，一次返回三個查詢結(jié)果。

在這種場景下我們需要考慮查詢結(jié)果是并行返回還是按層次返回即可。

二個查詢類的原子服務，最終需要返回兩個數(shù)據(jù)集關聯(lián)查詢的結(jié)果集

這個在微服務架構(gòu)做了底層數(shù)據(jù)庫拆分后經(jīng)常會遇到，比如對于物料基本信息查詢，和采購訂單明細查詢是在兩個獨立的數(shù)據(jù)庫獨立服務提供。而我們希望返回的查詢結(jié)果集是物料編碼，名稱，型號，單位，價格，采購數(shù)量的復合結(jié)果集。

這種場景下往往一般都是在前端功能開發(fā)的時候進行組裝，而實際上可以考慮是否可以在服務編排層解決這個問題，該問題寫代碼來解決容易，但是要做為可視化服務編排組態(tài)方式來做實際上有一定的難度。

對單個已有服務進行裁剪和豐富并形成一個新服務輸出

這個暫時也將其納入到服務編排的范疇，即仍然是輸入服務，但是輸出是提供了一個新服務。

即對單個已有的服務進行服務裁剪和豐富，比如對于輸出結(jié)果過濾掉一些數(shù)據(jù)項，對于輸入固定輸入一些數(shù)據(jù)項等。這些簡單的服務裁剪，豐富，或簡單的數(shù)據(jù)轉(zhuǎn)換可以在服務編排的時候完成，并提供一個新服務。

對多個原子服務進行流程式的前后串接并形成服務提供

這個是我們經(jīng)?？吹降囊环N服務編排場景，即A，B，C三個服務直接進行編排，即A服務的輸出直接變?yōu)锽服務的輸入，B服務的輸出又變?yōu)镃服務的輸出。如果僅僅是上面假設的這樣，那么這種流程式的服務編排仍然很簡單，也很容易去實現(xiàn)。

但是實際上的難點在于A服務的輸出本身也需要作為C服務的輸出，同時A，B服務的輸出也可能是整體輸出的一部分，這本身就加大了服務編排可視化設計的難度。

單一業(yè)務服務為主體服務，但是編排多個業(yè)務規(guī)則邏輯處理類服務

這也是經(jīng)常會遇到的場景，比如我們在進行合同信息導入的時候，首先要調(diào)用合同有效性校驗服務，同時還有調(diào)用預算信息檢查和扣減服務進行相關的完整性和業(yè)務規(guī)則校驗。在這些校驗完成后再調(diào)用實際的合同信息導入服務，如果校驗失敗則直接返回失敗結(jié)果。

這類服務編排往往也正是我們實際在進行前端功能開發(fā)時候服務進行組裝的邏輯。

多個導入服務組裝為一個導入服務合并導入并形成一個新服務

這個場景實際上和場景1是對應的，既然多個服務可以組合后形成組合結(jié)果返回，那么自然可以將多個導入服務合并為一個導入服務，一次性的完成數(shù)據(jù)導入。

比如有項目信息導入和項目WBS信息導入兩個原子服務，那么我們就可以提供一個新的項目信息導入服務，一次完成項目基本信息和項目WBS信息的導入。

圖片

在這些場景里面可以看到，實際上服務編排就是服務串聯(lián)，服務并聯(lián)下的輸入和輸出合并，服務內(nèi)容豐富和裁剪等常見場景。在一個理想的場景下，我們最希望實現(xiàn)的就是一個業(yè)務功能點的實現(xiàn)完全能夠通過服務編排可視化設計方式來完成。

下面我們來分析和討論下服務編排的可視化設計。

a. 定義一個新服務，需要提前考慮新服務輸入和輸出結(jié)構(gòu)設計

要進行服務編排，實際上編排完成后是新產(chǎn)生一個新服務，那么新服務一定有輸入和輸出結(jié)構(gòu)，那么就需要對新服務的輸入和輸出結(jié)構(gòu)進行設計。一種方法是在服務編排的時候再對輸入和輸出結(jié)構(gòu)進行定義，一種方法是提前對新服務的服務契約進行定義，服務契約定義好后就形成了標準的服務輸入和輸出結(jié)構(gòu)。

對于定義的服務編排產(chǎn)生的新服務，拖拽到設計器后應該產(chǎn)生輸入和輸出兩個獨立節(jié)點，這個在我們做單服務的ESB服務設計器的時候思路是一致的。

b. 服務之間的連接，本質(zhì)是服務輸入和輸出之間的連接和映射

要明白服務之間的連接本質(zhì)是輸入和輸出之間的連接和映射。以三個原子服務全部是查詢服務，我們希望組裝一個新服務，一次返回A，B，C三個服務查詢結(jié)果，這個場景來舉例說明。

我們需要拖拽A，B，C三個原子服務節(jié)點到設計器里面，然后將新服務的輸入連線到A，B，C三個原子服務節(jié)點。在連接完成后，我們需要將新服務的輸入和ABC三個服務的輸入之間進行數(shù)據(jù)映射。

其次我們需要將ABC三個服務的輸出連接到新服務的輸出。對于新服務的輸出，我們同樣需要完成數(shù)據(jù)項之間的映射。但是這里的復雜性體現(xiàn)在ABC三個服務輸出的三個結(jié)果集之間究竟是并行關系，還是父子層次關系，在進行數(shù)據(jù)映射和合并返回的時候，我們需要提前進行三個結(jié)果集的層次關系定義。這里面場景包括

1. 結(jié)果集并行結(jié)構(gòu)返回多個
2. 結(jié)果集返回層一個層次結(jié)構(gòu)的結(jié)果集返回
3. 對多個結(jié)果集類似Sql一樣進行查詢關聯(lián)，返回一個結(jié)果集作為結(jié)果

以上三種則是我們場景的對服務查詢結(jié)果進行處理，合并或關聯(lián)的方式。

c. 對服務流程式的串聯(lián)和順序處理，重點需要解決跨多節(jié)點數(shù)據(jù)映射問題

這個前面已經(jīng)講過，即將A，B，C三個服務進行串聯(lián)方式編排的時候，實際我們看到B結(jié)果的輸入只能夠是A節(jié)點的輸出，但是服務C的輸入?yún)s可以同時是A或B的輸出。因此在編排完成后進行數(shù)據(jù)映射的時候，一定需要支持C節(jié)點的輸入可以同時映射到A或B的輸出數(shù)據(jù)項元素。

d. 對于規(guī)則計算節(jié)點的兩種可能，簡單規(guī)則節(jié)點和復雜規(guī)則節(jié)點

對于規(guī)則節(jié)點需要考慮兩種可能性，一種是常見的簡單規(guī)則節(jié)點，即進行簡單的加減乘除運算得出一個規(guī)則，基于規(guī)則判斷后能夠走不同的分支對結(jié)果進行處理。另外一種可能即將輸入送入到規(guī)則引擎進行處理，處理完成后返回一個結(jié)果，如果在不連接規(guī)則引擎的情況下，我們可以設計一個專門的WS服務節(jié)點，即該節(jié)點可以去調(diào)用外部服務并返回輸出結(jié)果，并基于輸出結(jié)果情況進行判斷，基于判斷走不同的分支。

注意這種規(guī)則WS服務節(jié)點僅僅是進行規(guī)則處理，而非整個服務編排的主體輸入和輸出。實際我們在進行服務編排設計的時候，最好不要將這類節(jié)點放在主體服務編排路徑上面。

NetflixConductor微服務編排

圖片

對于服務編排的可視化設計，其中最核心的還是服務編排本身任務或活動節(jié)點對應的是原子服務，連線對應的是服務輸入輸出之間的映射，整個編排完成是形成一個新的接口服務能力，這就是服務編排要做的事情。如果無法滿足上面的核心，那談不上服務編排。

今天談下開源的微服務編排Netflix Conductor，先說下具體的場景，這個是Netflix內(nèi)容平臺工程團隊運行由微服務上執(zhí)行的任務的異步編排驅(qū)動的多個業(yè)務流程。其中一些是長期運行的流程，跨越幾天。這些流程在準備好標題流式傳輸給全球的觀眾上發(fā)揮關鍵作用。

這些流程的幾個實例是：

• 用于內(nèi)容提取的Studio合作伙伴集成
• 基于IMF的內(nèi)容提取我們的合作伙伴
• 在Netflix中設置新標題的過程
• 內(nèi)容提取、編碼和部署到CDN

傳統(tǒng)上，這些流程中的一些已經(jīng)以ad-hoc方式使用pub/sub的組合來編排，進行直接REST調(diào)用，并使用數(shù)據(jù)庫來管理狀態(tài)。然而，隨著微服務數(shù)量的增長和進程的復雜性增加，在沒有中央編排器的情況下，獲得對這些分布式工作流的可見性變得困難。我們將Conductor構(gòu)建為一個編排引擎，以滿足以下要求，取出在應用程序中需要的樣板，并提供一個反應流：

基于藍圖?；贘SON DSL的藍圖定義執(zhí)行流程。

• 跟蹤和管理工作流。
• 能夠暫停、恢復和重新啟動進程。
• 能夠擴展到數(shù)百萬個并發(fā)運行的進程流。
• 由從客戶端抽象的排隊服務支持。
• 能夠通過HTTP或其他傳輸方式進行操作，如 gRPC。

基于上面介紹可以看到Netflix Conductor最重要的還是實現(xiàn)了基本的工作流定義，任務定義，任務的連接，整個工作流的任務調(diào)度和監(jiān)控等基本能力。

官方參考文檔：https://github.com/Netflix/conductor

實例參考文檔：https://cloud.tencent.com/developer/article/1367734

對于具體的功能說明和介紹參考上面兩篇文章即可，在此不再重復進行描述，只對看完了整個Netflix Conductor功能實現(xiàn)后做一下簡單總結(jié)。

圖片

在Netflix Conductor中任務節(jié)點的定義雖然可以定義詳細的輸入和輸出，但是任務節(jié)點并不是服務引用節(jié)點，任務節(jié)點具體需要開發(fā)實現(xiàn)類來進行實現(xiàn)。那么我們場景里面說的任務節(jié)點即服務節(jié)點，任務的輸入或輸出就是服務的輸入或輸出是無法實現(xiàn)的，如果要實現(xiàn)也需要進行大量的定制開發(fā)才能夠支持。

微服務編排完成后可以形成一個新的Http Rest服務接口，這個是我們需要的。同時對于編排完成的workflow本身是可以實現(xiàn)靈活的任務監(jiān)控和任務調(diào)度，滿足基本的流程引擎該有的功能。

圖片

沒有看到可以進行可視化服務編排設計的地方，但是對于編排完成的模型文件可以展現(xiàn)為可視化的流程圖展示，這個也是很多編排軟件常用的做法。由于沒有可視化設計，當前的輸入輸出數(shù)據(jù)項映射也在手工編寫流程模板文件的時候完成數(shù)據(jù)映射工作。但是可以實現(xiàn)前面多個節(jié)點的輸出朝后續(xù)節(jié)點傳遞的需求。

工作流設計完成后，可以看到仍然需要寫大量的代碼和實現(xiàn)類才能夠完成工作流的運行，因此可以看到該開源軟件并不能實現(xiàn)完全的面向業(yè)務或開發(fā)人員的可配置零編碼的效果。

基于以上初步分析可以看到，Netflix Conductor開源微服務編排框架并不滿足我們前面描述的微服務編排場景，如果要實現(xiàn)服務和服務之間的編排，實際上對該開源軟件的定制和改造工作量相當大。因此在我們實現(xiàn)微服務編排的時候并不建議選擇該開源軟件。其次，在整個微服務架構(gòu)體系中，也不建議采用Netflix Conductor，至少在前期的改造過程中使用的場景很小，完全可以用其他方式來替代。