最近，同事Spring微服務(wù)技術(shù)架構(gòu)網(wǎng)上應(yīng)用出現(xiàn)了服務(wù)堵塞，監(jiān)控不到服務(wù)運行（業(yè)務(wù)進展情況），以及需求變更困難、維護成本高等情況，再回顧以前數(shù)據(jù)不一致等情況，通過討論分析發(fā)現(xiàn)系統(tǒng)架構(gòu)中沒有使用流程方法的服務(wù)編排。

1. 什么是微服務(wù)？

維基上對其定義為：一種軟件開發(fā)技術(shù)- 面向服務(wù)的體系結(jié)構(gòu)（SOA）架構(gòu)樣式的一種變體，將應(yīng)用程序構(gòu)造為一組松散耦合的服務(wù)。在微服務(wù)體系結(jié)構(gòu)中，服務(wù)是細粒度的，協(xié)議是輕量級的。
微服務(wù)（或微服務(wù)架構(gòu)）是一種云原生架構(gòu)方法，其中單個應(yīng)用程序由許多松散耦合且可獨立部署的較小組件或服務(wù)組成。

微服務(wù)架構(gòu)繼承了服務(wù)架構(gòu)，是與單體應(yīng)用（monolith application）相對的，其構(gòu)成主要是通過多層架構(gòu)完成業(yè)務(wù)，如下圖所示典型微服務(wù)技術(shù)架構(gòu)。

這種架構(gòu)支撐完成某些具體業(yè)務(wù)還是很方便的，如果遇到企業(yè)內(nèi)部全生產(chǎn)流程、信息孤島、數(shù)據(jù)治理等需求時，就顯得力不從心了，需要大量、復(fù)雜的開發(fā)工作。因此，又回到企業(yè)級服務(wù)體系架構(gòu)。

2. 流程編排與服務(wù)編排

對于服務(wù)編排和流程編排這兩個概念，很多時候我們并沒有刻意的去區(qū)分，但是還是結(jié)合具體的使用場景做下個人的一些理解。嚴(yán)格來將服務(wù)編排應(yīng)該是屬于流程編排的一個子集，同時服務(wù)編排更多的有點類似于組合服務(wù)的設(shè)計。而流程編排則面向一個完整業(yè)務(wù)流程的自動化實現(xiàn)。

那么可以看到一個完整的流程里面涉及的節(jié)點要素就比服務(wù)編排要多的多。比如人工處理節(jié)點，通知類節(jié)點，規(guī)則處理或規(guī)則引擎，流程的串行并行回退等處理等，這些往往在簡單的服務(wù)編排里面并不會出現(xiàn)。而服務(wù)編排更多就是多個服務(wù)的組合，可以是串行組合，也可以是并行組合，然后形成一個新的組合服務(wù)能力。

當(dāng)說到流程編排的時候，一般都會說到BPM業(yè)務(wù)流程管理和BPEL業(yè)務(wù)流程執(zhí)行語言和建模設(shè)計器，同時也可以看到流程編排往往最終完成的是一個流程，為了最終實現(xiàn)的流程可用，往往就還涉及到具體的業(yè)務(wù)對象單據(jù)的的設(shè)計，前端界面展現(xiàn)層設(shè)計等一系列的工作。只有這樣才能夠完成一個完整的業(yè)務(wù)人員可用的流程。流程編排完成的結(jié)果可以是一個API服務(wù)接口，也可以就是一個流程模版ID，而服務(wù)編排則最終形成的一定是一個新的API服務(wù)接口，最終的使用方也不是用戶而是開發(fā)人員。

不論是流程編排還是服務(wù)編排可以看到，都具備了基本的流程定義，任務(wù)定義，連接定義，流程啟動和任務(wù)調(diào)度監(jiān)控等基礎(chǔ)能力。以實現(xiàn)對于編排完成的服務(wù)或流程能夠在運行的時候能夠?qū)崿F(xiàn)動態(tài)，端到端可視化監(jiān)控能力。在一個流程啟動后，我們就可以進入到監(jiān)控界面對流程執(zhí)行進行監(jiān)控和調(diào)度控制。

還有一類就是純粹的任務(wù)編排或調(diào)度系統(tǒng)，即我們希望將做的多項工作任務(wù)連接起來形成一個任務(wù)鏈條有序的執(zhí)行，不管是DevOps里面的部署流水線，還是運維工作里面的多步驟自動化運維都符合上面的特征，這種任務(wù)調(diào)度系統(tǒng)的實現(xiàn)也具備了流程定義，任務(wù)定義，任務(wù)調(diào)度監(jiān)控等能力。但是實際上的任務(wù)活動節(jié)點僅僅是觸發(fā)外部的腳本或接口，其本身并不是一個原子服務(wù)節(jié)點，也談不上編排服務(wù)間的時間映射等復(fù)雜功能。

3. 微服務(wù)編排方式

目前有3種常見的微服務(wù)編排方式，實現(xiàn)微服務(wù)的組合與協(xié)調(diào)，可根據(jù)開發(fā)項目的實際情況進行選擇。

3.1. Orchestration（編制）

Orchestration面向可執(zhí)行的流程：通過一個可執(zhí)行的流程來協(xié)同內(nèi)部及外部的服務(wù)交互，通過流程來控制總體的目標(biāo)、涉及的操作、服務(wù)調(diào)用順序。

Orchestration和BPM、ESB的思想很相似，首先要有一個流程控制服務(wù)，該服務(wù)接收請求，依照業(yè)務(wù)邏輯規(guī)則，依次調(diào)用各個微服務(wù)，并最終完成處理邏輯。可以把控制服務(wù)視作BPM、ESB引擎，微服務(wù)視作BPM、ESB的各種組件。

Orchestration實現(xiàn)方案多是同步的。

優(yōu)點：
流程控制服務(wù)時時刻刻都知道每一筆業(yè)務(wù)究竟進行到了什么地步，監(jiān)控業(yè)務(wù)成了相對簡單的事情。
缺點：
1）流程控制服務(wù)很容易控制了太多的業(yè)務(wù)邏輯，耦合度過高，變得臃腫。
2）各個微服務(wù)退化為單純的增刪改查，失去自身價值。

如上圖所示的某商用微服務(wù)平臺，以流程服務(wù)方式編制服務(wù)，以及提供服務(wù)運行監(jiān)控能力。

3.2. Choreography（編排）

Choreography面向協(xié)作：通過消息的交互序列來控制各個部分資源的交互，參與交互的資源都是對等的，沒有集中的控制。

Choreography可以看作一種消息驅(qū)動模式，或者說是訂閱發(fā)布模式，每筆業(yè)務(wù)到來后，各個監(jiān)聽改事件的服務(wù)，會主動獲取消息，處理，并可以按需發(fā)布自己的消息。可以把不同隊列看作不同種類的消息，微服務(wù)看作消息處理函數(shù)。

Choreography實現(xiàn)方案多是異步的。

優(yōu)點：
耦合度低，每個服務(wù)都可以各司其職。
缺點：
1）業(yè)務(wù)流程是通過訂閱的方式來體現(xiàn)的，很難直接監(jiān)控每筆業(yè)務(wù)的處理，因此難于調(diào)試。
2）由于沒有預(yù)定義流程，所以很難在事前保證流程正確性，基本靠事后分析數(shù)據(jù)來判斷。
3）當(dāng)一個業(yè)務(wù)流程會嵌入到多個服務(wù)中時，維護會很困難。
建議：
1）小粒度的服務(wù)需要組合，服務(wù)的粒度越小，越需要組合。
2）增加相應(yīng)的監(jiān)控系統(tǒng)，來保證業(yè)務(wù)順暢進行。

3.3. API網(wǎng)關(guān)

API網(wǎng)關(guān)可以看作一種簡單的接口聚合/拆分的方式：每筆業(yè)務(wù)到來后先到達網(wǎng)關(guān)，網(wǎng)關(guān)調(diào)用各微服務(wù)，并最終聚合/拆分需反饋的結(jié)果。

API網(wǎng)關(guān)其實就是一個適配網(wǎng)關(guān)，比如對于Web端，可以一個頁面同時發(fā)起幾十個請求，而對于移動端，最好是一個頁面就幾個請求。而采用API網(wǎng)關(guān)，后面的微服務(wù)可以是相同的。

優(yōu)點：
對外接口相對穩(wěn)定。
缺點：
只適合業(yè)務(wù)邏輯較為簡單的場景，業(yè)務(wù)邏輯過于復(fù)雜時，網(wǎng)關(guān)接口耦合度及復(fù)雜度會急劇升高，變得臃腫。

4. 案例分析

4.1. 京東商城技術(shù)架構(gòu)總覽

1、基本平臺。數(shù)據(jù)存取方面的技術(shù)組件包括：緩存服務(wù)有JFS/Jimstore、圖片服務(wù)JSS、即時服務(wù)JDW、索引服務(wù)Search、數(shù)據(jù)庫服務(wù)DBS。

2、集成層。服務(wù)流程引擎PAF、服務(wù)中間件SAF、MQ服務(wù)JDMQ、數(shù)據(jù)庫中間件JDAL、調(diào)度服務(wù)JDWorker、業(yè)務(wù)規(guī)則服務(wù)JDRules、配置服務(wù)JDCenter、推送服務(wù)JMP。

3、質(zhì)量層。監(jiān)控服務(wù)UMP、日志服務(wù)Loghub、風(fēng)控系統(tǒng)JDriskM、應(yīng)用管理jdcenter。

其它還包括治理層、虛擬平臺、運營管理等等。

4.2. 阿里業(yè)務(wù)中臺技術(shù)架構(gòu)

所謂的業(yè)務(wù)中臺就是：通過制定標(biāo)準(zhǔn)和機制，把不確定的業(yè)務(wù)規(guī)則和流程通過工業(yè)化和市場化的手段確定下來，以減少人與人之間的溝通成本，同時還能最大程度地提升協(xié)作效率。

集中管控，分布式執(zhí)行，構(gòu)建業(yè)務(wù)中臺的基共享服務(wù)體系：

• 回歸SOA的本質(zhì)一服務(wù)重用
• 服務(wù)需要不斷的業(yè)務(wù)滋養(yǎng)
• 共享服務(wù)體系是培育業(yè)務(wù)創(chuàng)新的土壤
• 賦予業(yè)務(wù)快速創(chuàng)新和試錯能力
• 為真正發(fā)揮大數(shù)據(jù)威力做好儲備
• 改變組織陣型會帶來組織效能的提升

4.3. 人工智能中臺

我們可以把人工智能中臺看成是基于 IaaS 基礎(chǔ)上的人工智能 PaaS 平臺。在人工智能中臺上靈活搭建各種人工智能基礎(chǔ)服務(wù)，如人臉識別算法能力、語義識別算法能力、語音合成算法能力、布局決策能力等。然后在這些基礎(chǔ)人工智能能力之上，進行服務(wù)編排和組織，就可以形成語音轉(zhuǎn)文本、文本轉(zhuǎn)語音、智能推薦等帶有業(yè)務(wù)色彩的人工智能服務(wù)。包裝和組織這些帶有業(yè)務(wù)色彩的人工智能服務(wù)，最后就能包裝出各種垂直的人工智能解決方案。從 IaaS 到人工智能統(tǒng)一門戶這幾個層次，我們統(tǒng)稱為人工智能中臺。

5. 微服務(wù)編排組件

1、zeebe-io/zeebe

Zeebe是一個用于微服務(wù)編排的工作流引擎。Zeebe是一個免費的、源代碼可用的微服務(wù)編制工作流引擎，它提供：

• 對公司端到端的工作流狀態(tài)的可見性，包括正在運行的工作流的數(shù)量、平均工作流持續(xù)時間、工作流中的當(dāng)前錯誤，等等。
• 根據(jù)工作流的當(dāng)前狀態(tài)編制工作流;Zeebe將“命令”作為事件發(fā)布，可以由一個或多個微服務(wù)使用，確保工作流按照其定義進行。
• 監(jiān)視超時或其他流程錯誤，以及配置錯誤處理路徑的能力，例如有狀態(tài)重試或向能夠手動解決問題的團隊升級，確保工作流始終按計劃完成。

Zeebe被設(shè)計用來解決非常大規(guī)模的微服務(wù)編排問題，為了實現(xiàn)這一點，它提供:

• 橫向可伸縮性，不依賴于外部數(shù)據(jù)庫;相反，Zeebe直接將數(shù)據(jù)寫入部署它的服務(wù)器上的文件系統(tǒng)，并且可以輕松地跨計算機集群分發(fā)處理，從而提供高吞吐量。
• 通過易于配置的復(fù)制機制實現(xiàn)容錯，確保Zeebe可以從機器或軟件故障中恢復(fù)，而不會造成數(shù)據(jù)丟失和最小的停機時間。
• 一種消息驅(qū)動的體系結(jié)構(gòu)，其中所有與工作流相關(guān)的事件都被寫入僅用于追加的日志。這些事件可以導(dǎo)出到外部系統(tǒng)進行長期存儲，以提供一個完整的工作流審計日志。
• 發(fā)布-訂閱交互模型，它允許連接到Zeebe的微服務(wù)在提供處理反壓力機制的同時保持高度的控制。
  在iso標(biāo)準(zhǔn)BPMN 2.0中建模的可視化工作流，使得技術(shù)和非技術(shù)涉眾可以用一種公共語言協(xié)作進行工作流設(shè)計。
• 與語言無關(guān)的客戶機模型，使得用組織用來構(gòu)建微服務(wù)的幾乎任何編程語言構(gòu)建Zeebe客戶機成為可能。
  
  2、netflix/conductor

來自netflix 的為微服務(wù)編排引擎，支持的功能很豐富，同時文檔也比較全

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

3、uber/cadence

Cadence 是 Uber 開發(fā)的一個分布式，可擴展，持久且高度可用的編排引擎，以可擴展和彈性的方式執(zhí)行異步長期運行的業(yè)務(wù)邏輯。

業(yè)務(wù)邏輯被建模為工作流和活動。工作流程是協(xié)調(diào)邏輯的實現(xiàn)。其唯一目的是協(xié)調(diào)活動執(zhí)行。活動是業(yè)務(wù)邏輯中特定任務(wù)的實現(xiàn)。工作流和活動實現(xiàn)在工作進程中托管和執(zhí)行。這些工作人員長期輪詢Cadence服務(wù)器以執(zhí)行任務(wù)，通過調(diào)用工作流或活動實現(xiàn)來執(zhí)行任務(wù)，并將任務(wù)結(jié)果返回給Cadence服務(wù)器。此外，工作人員可以實現(xiàn)為完全無狀態(tài)的服務(wù)，這反過來允許無限制的水平擴展。

Cadence服務(wù)器代理并持久保存在工作流執(zhí)行期間生成的任務(wù)和事件，這為工作流執(zhí)行提供了某些可伸縮性和可靠性保證。單個活動執(zhí)行不具有容錯能力，因為它可能由于各種原因而失敗。但是，確定在哪種順序以及如何（位置，輸入?yún)?shù)，超時等）活動被執(zhí)行的工作流程保證在各種故障條件下繼續(xù)執(zhí)行。

其他還有Activiti、JBPM等，以及很多商用工作流或BPM標(biāo)準(zhǔn)的業(yè)務(wù)流程工具。

6. 總結(jié)

微服務(wù)做為服務(wù)架構(gòu)家族的一員，是構(gòu)建服務(wù)架構(gòu)中一種方法，服務(wù)的粒度不僅僅是技術(shù)的問題，更多的是業(yè)務(wù)問題，我們需要把服務(wù)粒度放到全業(yè)務(wù)流程環(huán)境中去解耦，按業(yè)務(wù)流程解耦服務(wù)、編排服務(wù)，在數(shù)據(jù)隔離、服務(wù)隔離的條件下，還要避免產(chǎn)生新的信息孤島，共享是未來的主題。

參考：

【1】ccww，微服務(wù)中的編排，具體指的是什么？ ，知乎，2019.11
【2】人月神話的博客，服務(wù)編排和流程編排(7.5)，新浪博客，2019.07
【3】沉落的星星，微服務(wù)核心研究之–編排 ，簡書，2019.07
【4】rongfengliang-榮鋒亮，幾個微服務(wù)編排工具，博客園， 2019.02
【5】intelligentx，【BPM技術(shù)】Zeebe是一個用于微服務(wù)編排的工作流引擎，首席架構(gòu)師，2020.06
【6】純潔的微笑，一文讀懂 Spring Boot、微服務(wù)架構(gòu)和大數(shù)據(jù)治理三者之間的故事，2018.05
【7】鹿鳴天涯，淘寶技術(shù)架構(gòu)變遷，CSDN博客，2019.07
【8】nicholas.wu，京東架構(gòu)專家分享京東架構(gòu)之路，CSDN博客，2018.04
【9】技術(shù)領(lǐng)導(dǎo)力，京東商城，超大型電商系統(tǒng)架構(gòu)設(shè)計原則與實踐！8頁ppt詳解，CSDN博客，2020.03
【10】火雨_Nick，淘寶網(wǎng)技術(shù)架構(gòu)介紹，CSDN博客，2015.12
【11】博文視點Broadview，人工智能工程化丨中小企業(yè)AI中臺落地指南，知乎，2020.10
【12】人月神話的博客，微服務(wù)編排NetflixConductor(7.4)，新浪博客，2019.07
【13】java圈，微服務(wù)編排引擎Cadence簡介，CSDN博客，2020.11

總結(jié)

以上是生活随笔為你收集整理的谈谈服务编排的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。