從ESB服務(wù)組合編排到NetflixConductor微服務(wù)編排
今天談下傳統(tǒng)ESB服務(wù)總線里面的可視化服務(wù)設(shè)計，服務(wù)組合編排和微服務(wù)里面的服務(wù)編排。對于服務(wù)組合編排，實際上我們看到有幾個不同的場景。
- 單服務(wù)可視化設(shè)計-僅僅針對一個服務(wù)實現(xiàn)
- 服務(wù)組合編排-實現(xiàn)多個服務(wù)的組合形成一個新的服務(wù)
- 業(yè)務(wù)流程編排-通過服務(wù)組合編排實現(xiàn)要給完整的業(yè)務(wù)流程
對于業(yè)務(wù)流程編排可以看到更多的是通過類似BPEL業(yè)務(wù)流程設(shè)計器來完成，因此今天主要介紹下傳統(tǒng)ESB服務(wù)總線里面的單個服務(wù)設(shè)計，多服務(wù)組合設(shè)計編排，同時再介紹下NetflixConductor微服務(wù)編排的開源實現(xiàn)。
單個服務(wù)的可視化設(shè)計
圖片
單個服務(wù)的可視化設(shè)計可以理解為實現(xiàn)單個服務(wù)的可視化服務(wù)設(shè)計，其中包括了服務(wù)適配，路由，數(shù)據(jù)映射，協(xié)議轉(zhuǎn)換等常見的編排節(jié)點和組件。
對于單服務(wù)設(shè)計可能用到的組件，我們基于服務(wù)集成場景，主要可以分為服務(wù)發(fā)布類組件，服務(wù)適配類組件，數(shù)據(jù)映射類組件。具體的組件包括了：
服務(wù)發(fā)布類組件(只需要支持SOAP WS服務(wù)和Rest WS服務(wù)即可）
- SOAP Proxy WS組件：發(fā)布代理服務(wù)
- SOAP Business WS組件：發(fā)布業(yè)務(wù)服務(wù)，銜接原始的業(yè)務(wù)服務(wù)地址
- Rest Proxy WS組件：發(fā)布基于Rest風(fēng)格的代理服務(wù)
- Rest Business WS組件：發(fā)布業(yè)務(wù)服務(wù)，銜接原始的Rest業(yè)務(wù)服務(wù)地址
- SOAP WS Request組件和 SOAP WS Response組件
- Rest WS Request組件和 Rest WS Response組件
適配器組件
- DBSqlQuery組件：實現(xiàn)對數(shù)據(jù)庫的Sql數(shù)據(jù)查詢能力。
- DBSqlInsertOrUpdate組件：實現(xiàn)對數(shù)據(jù)庫的Insert或Update操作適配能力。
- DBStoreProc組件：實現(xiàn)對數(shù)據(jù)庫存儲過程的適配能力。
- FTPInput或FileInput組件：實現(xiàn)對源端的數(shù)據(jù)獲取能力
- FTPOutput或FileOutput組件：實現(xiàn)對FTP服務(wù)器目標(biāo)端的適配能力
- JMSInput組件：實現(xiàn)對JMS寫入能力
- JMSOutput組件：實現(xiàn)對JMS的消費和訂閱能力
數(shù)據(jù)映射類組件
- XMLMapping組件：實現(xiàn)兩個XML結(jié)構(gòu)之間的數(shù)據(jù)映射能力
- tMapping組件：實現(xiàn)ETL時候兩個數(shù)據(jù)集之間的數(shù)據(jù)映射能力
基于以上組件我們可以來看，常見的服務(wù)集成場景用上面的設(shè)計器組件基本就能夠滿足，同時實現(xiàn)最簡單額設(shè)計組件之間的組合和連接。而設(shè)計器本身是一個設(shè)計態(tài)的東西，因此只需要將設(shè)計完成的內(nèi)容，即設(shè)計元數(shù)據(jù)存儲為一個獨立的XML文件即可。
后續(xù)基于設(shè)計文件要做的就是進(jìn)行實際的服務(wù)封裝和部署，而這個時候才需要將設(shè)計器的內(nèi)容進(jìn)行解析，進(jìn)行動態(tài)的服務(wù)封裝和部署工作。以實現(xiàn)服務(wù)設(shè)計態(tài)和服務(wù)運行態(tài)的自動銜接能力。
多個服務(wù)組合編排
圖片
服務(wù)組合編排是服務(wù)組合，服務(wù)組裝等，希望通過服務(wù)編排能夠完成這些事情，而不是簡單的完成單一服務(wù)的設(shè)計和開發(fā)。即將多個原子服務(wù)組合或組裝在一起，最終形成一個新的服務(wù)并提供的能力。我們舉例來說明下。
比如存在A，B，C三個原子服務(wù)，我們通過服務(wù)編排形成一個新的D服務(wù)。
三個原子服務(wù)全部是查詢服務(wù)，希望組裝一個新服務(wù)，一次返回A，B，C三個服務(wù)查詢結(jié)果
這個即我們說的服務(wù)組合能力，比如我們可以對合同基本信息查詢，合同條款信息查詢，合同執(zhí)行信息查詢?nèi)齻€基本原子服務(wù)進(jìn)行組合，最終返回一個服務(wù)綜合信息查詢的服務(wù)，一次返回三個查詢結(jié)果。
在這種場景下我們需要考慮查詢結(jié)果是并行返回還是按層次返回即可。
二個查詢類的原子服務(wù)，最終需要返回兩個數(shù)據(jù)集關(guān)聯(lián)查詢的結(jié)果集
這個在微服務(wù)架構(gòu)做了底層數(shù)據(jù)庫拆分后經(jīng)常會遇到，比如對于物料基本信息查詢，和采購訂單明細(xì)查詢是在兩個獨立的數(shù)據(jù)庫獨立服務(wù)提供。而我們希望返回的查詢結(jié)果集是物料編碼，名稱，型號，單位，價格，采購數(shù)量的復(fù)合結(jié)果集。
這種場景下往往一般都是在前端功能開發(fā)的時候進(jìn)行組裝，而實際上可以考慮是否可以在服務(wù)編排層解決這個問題，該問題寫代碼來解決容易，但是要做為可視化服務(wù)編排組態(tài)方式來做實際上有一定的難度。
對單個已有服務(wù)進(jìn)行裁剪和豐富并形成一個新服務(wù)輸出
這個暫時也將其納入到服務(wù)編排的范疇，即仍然是輸入服務(wù)，但是輸出是提供了一個新服務(wù)。
即對單個已有的服務(wù)進(jìn)行服務(wù)裁剪和豐富，比如對于輸出結(jié)果過濾掉一些數(shù)據(jù)項，對于輸入固定輸入一些數(shù)據(jù)項等。這些簡單的服務(wù)裁剪，豐富，或簡單的數(shù)據(jù)轉(zhuǎn)換可以在服務(wù)編排的時候完成，并提供一個新服務(wù)。
對多個原子服務(wù)進(jìn)行流程式的前后串接并形成服務(wù)提供
這個是我們經(jīng)常看到的一種服務(wù)編排場景，即A，B，C三個服務(wù)直接進(jìn)行編排，即A服務(wù)的輸出直接變?yōu)锽服務(wù)的輸入，B服務(wù)的輸出又變?yōu)镃服務(wù)的輸出。如果僅僅是上面假設(shè)的這樣，那么這種流程式的服務(wù)編排仍然很簡單，也很容易去實現(xiàn)。
但是實際上的難點在于A服務(wù)的輸出本身也需要作為C服務(wù)的輸出，同時A，B服務(wù)的輸出也可能是整體輸出的一部分，這本身就加大了服務(wù)編排可視化設(shè)計的難度。
單一業(yè)務(wù)服務(wù)為主體服務(wù)，但是編排多個業(yè)務(wù)規(guī)則邏輯處理類服務(wù)
這也是經(jīng)常會遇到的場景，比如我們在進(jìn)行合同信息導(dǎo)入的時候，首先要調(diào)用合同有效性校驗服務(wù)，同時還有調(diào)用預(yù)算信息檢查和扣減服務(wù)進(jìn)行相關(guān)的完整性和業(yè)務(wù)規(guī)則校驗。在這些校驗完成后再調(diào)用實際的合同信息導(dǎo)入服務(wù)，如果校驗失敗則直接返回失敗結(jié)果。
這類服務(wù)編排往往也正是我們實際在進(jìn)行前端功能開發(fā)時候服務(wù)進(jìn)行組裝的邏輯。
多個導(dǎo)入服務(wù)組裝為一個導(dǎo)入服務(wù)合并導(dǎo)入并形成一個新服務(wù)
這個場景實際上和場景1是對應(yīng)的，既然多個服務(wù)可以組合后形成組合結(jié)果返回，那么自然可以將多個導(dǎo)入服務(wù)合并為一個導(dǎo)入服務(wù)，一次性的完成數(shù)據(jù)導(dǎo)入。
比如有項目信息導(dǎo)入和項目WBS信息導(dǎo)入兩個原子服務(wù)，那么我們就可以提供一個新的項目信息導(dǎo)入服務(wù)，一次完成項目基本信息和項目WBS信息的導(dǎo)入。
圖片
在這些場景里面可以看到，實際上服務(wù)編排就是服務(wù)串聯(lián)，服務(wù)并聯(lián)下的輸入和輸出合并，服務(wù)內(nèi)容豐富和裁剪等常見場景。在一個理想的場景下，我們最希望實現(xiàn)的就是一個業(yè)務(wù)功能點的實現(xiàn)完全能夠通過服務(wù)編排可視化設(shè)計方式來完成。
下面我們來分析和討論下服務(wù)編排的可視化設(shè)計。
a. 定義一個新服務(wù)，需要提前考慮新服務(wù)輸入和輸出結(jié)構(gòu)設(shè)計
要進(jìn)行服務(wù)編排，實際上編排完成后是新產(chǎn)生一個新服務(wù)，那么新服務(wù)一定有輸入和輸出結(jié)構(gòu)，那么就需要對新服務(wù)的輸入和輸出結(jié)構(gòu)進(jìn)行設(shè)計。一種方法是在服務(wù)編排的時候再對輸入和輸出結(jié)構(gòu)進(jìn)行定義，一種方法是提前對新服務(wù)的服務(wù)契約進(jìn)行定義，服務(wù)契約定義好后就形成了標(biāo)準(zhǔn)的服務(wù)輸入和輸出結(jié)構(gòu)。
對于定義的服務(wù)編排產(chǎn)生的新服務(wù)，拖拽到設(shè)計器后應(yīng)該產(chǎn)生輸入和輸出兩個獨立節(jié)點，這個在我們做單服務(wù)的ESB服務(wù)設(shè)計器的時候思路是一致的。
b. 服務(wù)之間的連接，本質(zhì)是服務(wù)輸入和輸出之間的連接和映射
要明白服務(wù)之間的連接本質(zhì)是輸入和輸出之間的連接和映射。以三個原子服務(wù)全部是查詢服務(wù)，我們希望組裝一個新服務(wù)，一次返回A，B，C三個服務(wù)查詢結(jié)果，這個場景來舉例說明。
我們需要拖拽A，B，C三個原子服務(wù)節(jié)點到設(shè)計器里面，然后將新服務(wù)的輸入連線到A，B，C三個原子服務(wù)節(jié)點。在連接完成后，我們需要將新服務(wù)的輸入和ABC三個服務(wù)的輸入之間進(jìn)行數(shù)據(jù)映射。
其次我們需要將ABC三個服務(wù)的輸出連接到新服務(wù)的輸出。對于新服務(wù)的輸出，我們同樣需要完成數(shù)據(jù)項之間的映射。但是這里的復(fù)雜性體現(xiàn)在ABC三個服務(wù)輸出的三個結(jié)果集之間究竟是并行關(guān)系，還是父子層次關(guān)系，在進(jìn)行數(shù)據(jù)映射和合并返回的時候，我們需要提前進(jìn)行三個結(jié)果集的層次關(guān)系定義。這里面場景包括
- 結(jié)果集并行結(jié)構(gòu)返回多個
- 結(jié)果集返回層一個層次結(jié)構(gòu)的結(jié)果集返回
- 對多個結(jié)果集類似Sql一樣進(jìn)行查詢關(guān)聯(lián)，返回一個結(jié)果集作為結(jié)果
以上三種則是我們場景的對服務(wù)查詢結(jié)果進(jìn)行處理，合并或關(guān)聯(lián)的方式。
c. 對服務(wù)流程式的串聯(lián)和順序處理，重點需要解決跨多節(jié)點數(shù)據(jù)映射問題
這個前面已經(jīng)講過，即將A，B，C三個服務(wù)進(jìn)行串聯(lián)方式編排的時候，實際我們看到B結(jié)果的輸入只能夠是A節(jié)點的輸出，但是服務(wù)C的輸入?yún)s可以同時是A或B的輸出。因此在編排完成后進(jìn)行數(shù)據(jù)映射的時候，一定需要支持C節(jié)點的輸入可以同時映射到A或B的輸出數(shù)據(jù)項元素。
d. 對于規(guī)則計算節(jié)點的兩種可能，簡單規(guī)則節(jié)點和復(fù)雜規(guī)則節(jié)點
對于規(guī)則節(jié)點需要考慮兩種可能性，一種是常見的簡單規(guī)則節(jié)點，即進(jìn)行簡單的加減乘除運算得出一個規(guī)則，基于規(guī)則判斷后能夠走不同的分支對結(jié)果進(jìn)行處理。另外一種可能即將輸入送入到規(guī)則引擎進(jìn)行處理，處理完成后返回一個結(jié)果，如果在不連接規(guī)則引擎的情況下，我們可以設(shè)計一個專門的WS服務(wù)節(jié)點，即該節(jié)點可以去調(diào)用外部服務(wù)并返回輸出結(jié)果，并基于輸出結(jié)果情況進(jìn)行判斷，基于判斷走不同的分支。
注意這種規(guī)則WS服務(wù)節(jié)點僅僅是進(jìn)行規(guī)則處理，而非整個服務(wù)編排的主體輸入和輸出。實際我們在進(jìn)行服務(wù)編排設(shè)計的時候，最好不要將這類節(jié)點放在主體服務(wù)編排路徑上面。
NetflixConductor微服務(wù)編排
圖片
對于服務(wù)編排的可視化設(shè)計，其中最核心的還是服務(wù)編排本身任務(wù)或活動節(jié)點對應(yīng)的是原子服務(wù)，連線對應(yīng)的是服務(wù)輸入輸出之間的映射，整個編排完成是形成一個新的接口服務(wù)能力，這就是服務(wù)編排要做的事情。如果無法滿足上面的核心，那談不上服務(wù)編排。
今天談下開源的微服務(wù)編排Netflix Conductor，先說下具體的場景，這個是Netflix內(nèi)容平臺工程團隊運行由微服務(wù)上執(zhí)行的任務(wù)的異步編排驅(qū)動的多個業(yè)務(wù)流程。其中一些是長期運行的流程，跨越幾天。這些流程在準(zhǔn)備好標(biāo)題流式傳輸給全球的觀眾上發(fā)揮關(guān)鍵作用。
這些流程的幾個實例是：
- 用于內(nèi)容提取的Studio合作伙伴集成
- 基于IMF的內(nèi)容提取我們的合作伙伴
- 在Netflix中設(shè)置新標(biāo)題的過程
- 內(nèi)容提取、編碼和部署到CDN
傳統(tǒng)上，這些流程中的一些已經(jīng)以ad-hoc方式使用pub/sub的組合來編排，進(jìn)行直接REST調(diào)用，并使用數(shù)據(jù)庫來管理狀態(tài)。然而，隨著微服務(wù)數(shù)量的增長和進(jìn)程的復(fù)雜性增加，在沒有中央編排器的情況下，獲得對這些分布式工作流的可見性變得困難。我們將Conductor構(gòu)建為一個編排引擎，以滿足以下要求，取出在應(yīng)用程序中需要的樣板，并提供一個反應(yīng)流：
基于藍(lán)圖。基于JSON DSL的藍(lán)圖定義執(zhí)行流程。
- 跟蹤和管理工作流。
- 能夠暫停、恢復(fù)和重新啟動進(jìn)程。
- 能夠擴展到數(shù)百萬個并發(fā)運行的進(jìn)程流。
- 由從客戶端抽象的排隊服務(wù)支持。
- 能夠通過HTTP或其他傳輸方式進(jìn)行操作，如 gRPC。
基于上面介紹可以看到Netflix Conductor最重要的還是實現(xiàn)了基本的工作流定義，任務(wù)定義，任務(wù)的連接，整個工作流的任務(wù)調(diào)度和監(jiān)控等基本能力。
官方參考文檔：https://github.com/Netflix/conductor
實例參考文檔：https://cloud.tencent.com/developer/article/1367734
對于具體的功能說明和介紹參考上面兩篇文章即可，在此不再重復(fù)進(jìn)行描述，只對看完了整個Netflix Conductor功能實現(xiàn)后做一下簡單總結(jié)。
圖片
在Netflix Conductor中任務(wù)節(jié)點的定義雖然可以定義詳細(xì)的輸入和輸出，但是任務(wù)節(jié)點并不是服務(wù)引用節(jié)點，任務(wù)節(jié)點具體需要開發(fā)實現(xiàn)類來進(jìn)行實現(xiàn)。那么我們場景里面說的任務(wù)節(jié)點即服務(wù)節(jié)點，任務(wù)的輸入或輸出就是服務(wù)的輸入或輸出是無法實現(xiàn)的，如果要實現(xiàn)也需要進(jìn)行大量的定制開發(fā)才能夠支持。
微服務(wù)編排完成后可以形成一個新的Http Rest服務(wù)接口，這個是我們需要的。同時對于編排完成的workflow本身是可以實現(xiàn)靈活的任務(wù)監(jiān)控和任務(wù)調(diào)度，滿足基本的流程引擎該有的功能。
圖片
沒有看到可以進(jìn)行可視化服務(wù)編排設(shè)計的地方，但是對于編排完成的模型文件可以展現(xiàn)為可視化的流程圖展示，這個也是很多編排軟件常用的做法。由于沒有可視化設(shè)計，當(dāng)前的輸入輸出數(shù)據(jù)項映射也在手工編寫流程模板文件的時候完成數(shù)據(jù)映射工作。但是可以實現(xiàn)前面多個節(jié)點的輸出朝后續(xù)節(jié)點傳遞的需求。
工作流設(shè)計完成后，可以看到仍然需要寫大量的代碼和實現(xiàn)類才能夠完成工作流的運行，因此可以看到該開源軟件并不能實現(xiàn)完全的面向業(yè)務(wù)或開發(fā)人員的可配置零編碼的效果。
基于以上初步分析可以看到，Netflix Conductor開源微服務(wù)編排框架并不滿足我們前面描述的微服務(wù)編排場景，如果要實現(xiàn)服務(wù)和服務(wù)之間的編排，實際上對該開源軟件的定制和改造工作量相當(dāng)大。因此在我們實現(xiàn)微服務(wù)編排的時候并不建議選擇該開源軟件。其次，在整個微服務(wù)架構(gòu)體系中，也不建議采用Netflix Conductor，至少在前期的改造過程中使用的場景很小，完全可以用其他方式來替代。
