https://www.jianshu.com/p/54e2e223dbac
目錄：
一、微服務編排的必要性
二：3種常見的微服務編排方式
1、Orchestration（編制）
2、Choreography（編排）
3、API網關
三、微服務編排的框架（Orchestration方式）
1、流程編排的思路
2、流程編排的模型
3、適配參數
4、流水號
5、調用鏈分析
四、微服務編排的事務一致性
五、微服務編排的監控工具支撐
一、微服務編排的必要性
微服務是目前流行的一種新興的軟件架構風格，在微服務體系結構中，可以將應用分解為多個更小顆粒度的服務, 各個服務可以由不同的團隊並行獨立開發、部署。
（圖片來源：https://www.nginx.com/blog/introduction-to-microservices/）
以一個出租車調度軟件為例，最開始是一個單體應用，應用核心是業務邏輯，由定義服務、域對象和事件的模塊完成。盡管也是模塊化邏輯，但是最終它還是會打包並部署為單體式應用。隨着時間增加，功能逐漸增多，代碼越來越多，這個軟件就會越來越難維護。這時使用微服務架構就是不錯的選擇。一個微服務一般完成某個特定的功能，比如定單管理、客戶管理等等。每一個微服務都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個微服務實例可能是一個Docker容器。
《The Art of Scalability》(中文書名：架構即未來) 一書介紹了一個應用橫向擴展所需要遵守的AKF擴展模型。根據AKF擴展模型，橫向擴展實際上包含了三個維度，而橫向擴展解決方案則是這三個維度上所做工作的結合。X軸表示水平復制，Y軸表示應用功能拆解，Z軸表示按數據拆分。微服務架構模式對應於代表可擴展模型的Y軸。
當一個系統采用了微服務架構后，原有的業務可能並沒有發生變化，但系統已被拆分成了很多新的微服務，與傳統架構相比，微服務架構下會更依賴通過各微服務之間的協作來實現一個完整的業務流程，這種協作就是服務編排。編排涉及到RPC、分布式事務等，需要有完善的編排框架來支撐。
二：3種常見的微服務編排方式
目前有3種常見的微服務編排方式，實現微服務的組合與協調，可根據開發項目的實際情況進行選擇。
1、Orchestration（編制）
Orchestration面向可執行的流程：通過一個可執行的流程來協同內部及外部的服務交互，通過流程來控制總體的目標、涉及的操作、服務調用順序。
Orchestration和BPM、ESB的思想很相似，首先要有一個流程控制服務，該服務接收請求，依照業務邏輯規則，依次調用各個微服務，並最終完成處理邏輯。可以把控制服務視作BPM、ESB引擎，微服務視作BPM、ESB的各種組件。
Orchestration實現方案多是同步的。
優點：
流程控制服務時時刻刻都知道每一筆業務究竟進行到了什么地步，監控業務成了相對簡單的事情。
缺點：
1）流程控制服務很容易控制了太多的業務邏輯，耦合度過高，變得臃腫。
2）各個微服務退化為單純的增刪改查，失去自身價值。
2、Choreography（編排）
Choreography面向協作：通過消息的交互序列來控制各個部分資源的交互，參與交互的資源都是對等的，沒有集中的控制。
Choreography可以看作一種消息驅動模式，或者說是訂閱發布模式，每筆業務到來后，各個監聽改事件的服務，會主動獲取消息，處理，並可以按需發布自己的消息。可以把不同隊列看作不同種類的消息，微服務看作消息處理函數。
Choreography實現方案多是異步的。
優點：
耦合度低，每個服務都可以各司其職。
缺點：
1）業務流程是通過訂閱的方式來體現的，很難直接監控每筆業務的處理，因此難於調試。
2）由於沒有預定義流程，所以很難在事前保證流程正確性，基本靠事后分析數據來判斷。
3）當一個業務流程會嵌入到多個服務中時，維護會很困難。
建議：
1）小粒度的服務需要組合，服務的粒度越小，越需要組合。
2）增加相應的監控系統，來保證業務順暢進行。
3、API網關
API網關可以看作一種簡單的接口聚合/拆分的方式：每筆業務到來后先到達網關，網關調用各微服務，並最終聚合/拆分需反饋的結果。
API網關其實就是一個適配網關，比如對於Web端，可以一個頁面同時發起幾十個請求，而對於移動端，最好是一個頁面就幾個請求。而采用API網關，后面的微服務可以是相同的。
優點：
對外接口相對穩定。
缺點：
只適合業務邏輯較為簡單的場景，業務邏輯過於復雜時，網關接口耦合度及復雜度會急劇升高，變得臃腫。
三、微服務編排的框架（Orchestration方式）
對編排流程、適配參數、調用鏈分析等方面思路的考量，構成微服務編排的框架思路。
1、編排流程的思路
原子服務提供REST接口或者監聽事件，通過流程編排這些原子服務來實現一個新的復雜服務。
2、編排流程的模型
- 活動模型。例如（賦值、invoke（調用）、空）
- 控制模型。例如（順序、分支、循環、異常拋出、異常捕獲、並行）
當然，有很多編排框架提供了更多方便的活動，比如普元的編排框架提供了本地調用、rest調用、webservice調用等活動，從而在使用上更加的方便，有了這些基本的模型，我們就能方便的編排出復雜的業務流程。（如下圖）
在invoke（調用）的時候我們知道有同步和異步的區別。同步實現起來簡單，但是在多級級聯編排的時候要避免因為某個服務的長響應時間導致雪崩效應，一般可以通過設置合理的超時時間限流和服務熔斷策略來避免；同樣，在異步調用的時候，應該能自動緩存上下文和避免緩存爆掉，能自動建立異步響應和請求之間的關聯。同樣，提到並行也必須考慮不同的聚合方式，比如是部分聚合還是全部聚合。（如下圖）
3、適配參數
流程編排完成之后，我們還需要給每個被編的服務提供正確的參數，是一個適配的過程。
一個編排服務（abcd）由a、b、c、d服務編排而成，每個服務都會有自己的出參入參。適配的過程就是從上下文中給入參賦值以及將出參的結果寫入到上下文中。（如下圖）
編排服務執行到不同階段，組成上下文的模型也是不一樣的。從最初服務的開始執行的時候，上下文中只有系統級的參數和入參（請求報文），到執行完一個被編服務后上下文就會增加這個被編服務的出參（響應報文），執行上下文是一個不斷增大的過程。所以適配不僅僅存在於編排服務的入參和被編服務的入參之間，還存在於被編服務和在其之前的服務出參之間。（如下圖）
實現適配最直接的方式是用手工編碼完成點到點的映射賦值，但有更高效的方式，通過使用元數據對所有的出參和入參標記着色，然后就可以自動完成同樣顏色之間的自動映射。這種標志着色可以靠數據字典實現。（如下圖）
這里的數據字典是指抽象出業務含義的基本數據項，如賬戶，交易額等。通過這些數據字典可以定義出服務所需的的數據結構（服務參數和服務返回值），這樣不同的數據結構之間可以按照數據字典進行自動適配。（如下圖）
4、流水號
編排服務在執行上下文的組成模型過程中，框架也會產生一部分數據，這一部分數據主要是流水號(id)和安全方面的考量。按照《基於微服務的企業應用架構設計范式》流水號的生成應該遵循GAIR模式。
GlobalID: 全局流水號，如果請求中的globalId為空，則編排服務生成，否則保持不變。
AnswerID:響應流水號，服務提供者生成，可以作為提供者受理的憑證
InRequestID: 前台流水號，由前台生成
RequestID:請求流水號，編排服務的協調器生成，生成規則由服務提供者定義。（如下圖）
5、調用鏈分析
隨着服務的增多，對調用鏈的分析也會越來越復雜。在一個由很多微服務組成的系統中，他們之間的調用關系會形成復雜的網絡。
Google針對服務化應用全鏈路追蹤的問題發表了Dapper論文，介紹了他們如何進行服務追蹤分析，其基本思路是在服務調用的請求和響應中加入ID，標明上下游請求的關系，利用這些信息，可以可視化地分析服務調用鏈路和服務間的依賴關系。（如下圖）
通過服務調用追蹤生成的服務調用棧，可以查看在哪一步出現了錯誤，以及發現哪里的調用較慢，進行系統優化。（如下圖）
能編排流程，能適配參數，這個編排框架已經具備運行的能力，接下來要考慮的就是事務的一致性問題。
四、微服務編排的事務一致性
依據CAP理論，分布式系統需要在可用性和一致性之間做出選擇。如果選擇提供一致性，就需要付出在滿足一致性之前阻塞其他並發訪問的代價，阻塞持續的時間往往不能確定，尤其是在系統已經表現出高延遲時或者網絡故障導致失去連接時，因此，可用性一般是更多人的選擇，但是在服務和數據庫之間維護數據一致性是非常根本的需求，編排框架應該選擇滿足最終一致性。
補償模式是一種很好的實現最終一致性的途徑。 補償模式核心思想是：針對每個操作，都要注冊一個與其對應的補償（撤銷）操作，一般來說操作本身和其補償操作會在一個事務里完成，當其后續操作失敗后，需要按相反順序完成前面注冊的所有撤銷操作。
通過一個實例來說明：一家旅行公司提供預訂行程的業務，可以通過公司的網站提前預訂飛機票、火車票、酒店等。假設一位客戶規划的行程是，(1)上海-北京6月19日9點的某某航班，(2)某某酒店住宿3晚，(3)北京-上海6月22日17點火車。在客戶提交行程后，旅行公司的預訂行程業務按順序串行的調用航班預訂服務、酒店預訂服務、火車預訂服務。最后的火車預訂服務成功后整個預訂業務才算完成。如果火車票預訂服務沒有調用成功，那么之前預訂的航班、酒店都得取消。取消之前預訂的酒店、航班即為補償過程。（如下圖）
在補償模式中，我們要求參與補償的微服務必須提供補償操作，並且補償操作必須是冪等的，補償框架可以在異常時自動調用補償操作完成補償。
跟RPC比，補償模式的核心價值是少了鎖資源的代價，流程也相對簡單，但實際操作中，補償操作不太好定義，其中間狀態處理也會比較棘手。
現在RESTful作為一個輕量級的rpc協議已經被廣泛采用，能不能很好的支持RESTful服務的事務一致性也是衡量編排框架的是否成熟的一個標准。
一個通過RESTful擴展規范來支持補償模式事務一致性的思路：通過PATCH的HTTP Method來表示compensation操作，並且支持通過服務來查詢編排服務執行的狀態。（如下圖）
補償模式一個常見的坑：由於是通過rpc的調用，因為網絡和調度的關系，可能出現補償請求比原交易先到達的情況，這會導致補償操作直接會失敗，因為此時原交易尚未發生，最終原交易到達時會被成功的執行，最終就導致了事務不一致。
填這個坑的辦法就是在編排框架發現補償操作補償的原交易不存在時，補記錄一條原交易的流水，從而保證原交易晚到時會因為記錄流水失敗而不會成功。（如下圖）
五、微服務編排的監控工具支撐
在生產環境中，我們需要通過查看日志來排除故障，應該有支持日志全路徑回放的工具，來幫助我們快速定位故障。
本文所講的編排實際是編制，是一種集中式的控制，也就意味着如果被編排的服務有響應緩慢的情況，可能會影響到其他服務。這時候我們需要更快的監控來幫助我們發現這類服務，從而盡早優化。監控工具需要具備以下功能：
-
通過可視化分布式系統的模塊和他們之間的相互聯系來理解系統拓撲。點擊某個節點會展示這個模塊的詳情，比如它當前的狀態和請求數量。
-
實時監控應用內部的活動線程。
-
可視化請求和響應數量來定位潛在問題（請求時間段分布、錯誤請求、響應時長等）。
-
在分布式環境中為每個調用生成可視圖，定位瓶頸和失敗點。
-
查看應用上的其他詳細信息，比如CPU使用率，內存/垃圾回收，TPS，和JVM參數。
作者：沉落的星星
鏈接：https://www.jianshu.com/p/54e2e223dbac
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。