本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
目錄：
一、微服務需要編排嗎？
二、微服務編排的流程
三、微服務編排的一致性
四、微服務編排的監控工具支撐
一、微服務需要編排嗎？
微服務是一種新的軟件架構風格。在微服務體系結構中，可以將應用分解爲多個較小服務, 各個服務可以由獨立的團隊進行開發、部署。①
（圖片來源於：https://www.nginx.com/blog/introduction-to-microservices/
《The Art of Scalability》(架構即未來)）
以一個出租車調度軟件爲例，最開始是一個單體應用，應用核心是業務邏輯，由定義服務、域對象和事件的模塊完成。儘管也是模塊化邏輯，但是最終它還是會打包並部署爲單體式應用，隨着時間增加，功能逐漸增多，代碼越來越多，這個軟件就會越來越難維護。②
這時使用微服務架構就是不錯的選擇。一個微服務一般完成某個特定的功能，比如定單管理、客戶管理等等。每一個微服務都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個微服務實例可能是一個Docker容器。
《The Art of Scalability》(架構即未來) 一書則介紹了一個應用橫向擴展所需要遵守的AKF擴展模型。根據AKF擴展模型，橫向擴展實際上包含了三個維度，而橫向擴展解決方案則是這三個維度上所做工作的結合。X軸表示水平復制，Y軸表示應用功能拆解，Z軸表示按數據拆分。
微服務架構模式對應於代表可擴展模型的Y軸。③
當一個系統採用了微服務架構後，會拆分成很多新的微服務，但原有的業務可能還是沒有變化，如何在微服務架構下實現原有的業務？相對於傳統架構，微服務架構下更需要通過各微服務之間的協作來實現一個完整的業務流程，可以說服務編排是微服務架構下的必備技能。但是，編排涉及到RPC、分佈式事務等等，編排的質量不能僅僅取決於老師傅的手藝，需要有完善的編排框架來支撐。
關於微服務的組合(協調)：
編制（Orchestration）—— 面向可執行的流程：通過一個可執行的流程來協同內部及外部的服務交互。通過中心流程來控制總體的目標，涉及的操作，服務調用順序。
編排（Choreography）—— 面向合作：通過消息的交互序列來控制各個部分資源的交互。參與交互的資源都是對等的，沒有集中的控制。④
編制看起來好像沒有編排自由，靈活。但是編排也有不完美的地方，編排難調試，並且由於沒有預定義流程，所以很難事前保證流程正確性，基本靠事後分析數據來判斷。當一個業務流程會嵌入到多個服務中，維護會困難重重。
所以我們認爲服務的粒度越小，服務需要組合的可能性越大。
二、微服務編排的流程
在這短短的120行代碼中，有25行註釋，12行空行，83行功能，包括12次參數校驗，18此rpc（包括14次寫操作），包括6大業務步驟，主要功能是實現添加一個用戶。但是啊但是，這裏面絕大部分是沒有事務控制的，可想而知，當真的出現數據不一致的時候我們修復的過程是有多頭疼。我們不能把代碼質量完全寄託於老師傅的手藝，編排完全是有章可循的。
（圖片來源：https://www.slideshare.net/）
相比於前面的手工編碼的編排，採用圖形化的編排，即可以屏蔽代碼細節處理，也讓整理流程一目瞭然，下面的是一個個原子服務，原子服務可以提供REST接口或者監聽事件，可以通過流程編排這些原子服務來實現一個新的複雜服務。
編排的模型包含：
活動模型（賦值、invoke（調用）、空）
控制模型（順序、分支、循環、異常拋出、異常捕獲、並行）。
編排框架提供了更多方便的活動，比如本地調用、REST調用、同異步調用等活動，從而在使用上更加的方便。
有了這些基本的模型，我們就能方便的編排出複雜的業務流程。
（圖片來源：https://www.nginx.com/blog/introduction-to-microservices/）
在調用的時候我們知道有同步和異步的區別，同步實現起來簡單，但是在多級級聯編排的時候要避免因爲某個服務的長響應時間導致雪崩效應，一般可以通過設置合理的超時時間限流和服務熔斷策略來避免。
流程編排完成之後，我們還需要給每個被編的服務提供正確的參數，是一個適配的過程。一個編排服務（abcd）由a、b、c、d服務編排而成，每個服務都會有自己的出參入參。適配的過程就是從上下文中給入參賦值以及將出參的結果寫入到上下文中。
編排服務執行到不同階段，組成上下文的模型也是不一樣的。從最初服務的開始執行的時候，上下文中只有系統級的參數和入參（請求報文）。到執行完一個被編服務後上下問就會增加這個被編服務的出參（響應報文），執行上下文是一個不斷增大的過程。所以適配不僅僅存在與編排服務的入參和被編服務的入參之間，還存在於被編服務和在其之前的服務出參之間。
最直接的莫過於依靠手工編碼，完成點到點的映射賦值。只是這種工作沒有什麼成就感，大多數都是重複勞動。當然，我們作爲老師傅還是有一些過人之處的，我們有一種解放雙手的武器。這個武器就是元數據，我們通過使用元數據對所有的出參和入參標記着色，然後就可以自動完成同樣顏色之間的自動映射。這種標誌着色可以靠數據字典實現。
這裏的數據字典是指抽象出業務含義的基本數據項，如賬戶，交易額等。通過這些數據字典可以定義出服務所需的的數據結構（服務參數和服務返回值），這樣不同的數據結構之間可以按照數據字典進行自動適配。
（圖片來源：https://skyao.gitbooks.io/learning-pinpoint/content/）
隨着服務的增多，對調用鏈的分析也會越來越複雜。在一個由很多微服務組成的系統中，他們之間的調用關係會形成複雜的網絡。針對服務化應用全鏈路追蹤的問題，Google發表了Dapper論文，介紹了他們如何進行服務追蹤分析。其基本思路是在服務調用的請求和響應中加入ID，標明上下游請求的關係。利用這些信息，可以可視化地分析服務調用鏈路和服務間的依賴關係。⑤
（圖片來源：https://github.com/naver/pinpoint）
通過服務調用追蹤生成的服務調用棧，可以查看在哪一步出現了錯誤，以及發現哪裏的調用較慢，進行系統優化。
三、微服務編排的一致性
依據CAP理論，分佈式系統需要在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。
可用性一般是更好的選擇，但是在服務和數據庫之間維護數據一致性是非常根本的需求，我們的編排框架應該選擇滿足最終一致性。補償模式就是就是一種很好的實現最終一致性的途徑。
補償模式，其核心思想是:針對每個操作，都要註冊一個與其對應的補償操作。一般來說操作本身和其補償（撤銷）操作會在一個事務裏完成。當其後續操作失敗後，需要按相反順序完成前面註冊的所有撤銷操作。
跟2PC比，他的核心價值應該是少了鎖資源的代價。流程也相對簡單一點。但實際操作中，補償操作不太好定義，其中間狀態處理也會比較棘手。⑥
現在RESTful作爲一個輕量級的rpc協議已經被廣泛採用，能不能很好的支持RESTful服務的事務一致性也是衡量一個編排框架的是否成熟的一個標準。我們公司的王博士設計了一套RESTful擴展規範來支持補償模式的事務一致性。通過PATCH的HTTP Method來表示compensation操作，並且支持通過服務來查詢編排服務執行的狀態。
四、微服務編排的監控工具支撐
這裏不給出具體的工具了，只是列出了監控工具可能需要具備的功能：
通過可視化分佈式系統的模塊和他們之間的相互聯繫來理解系統拓撲。點擊某個節點會展示這個模塊的詳情，比如它當前的狀態和請求數量。
實時監控應用內部的活動線程。
可視化請求和響應數量來定位潛在問題（請求時間段分佈、錯誤請求、響應時長等）。
在分佈式環境中爲每個調用生成可視圖，定位瓶頸和失敗點。
查看應用上的其他詳細信息，比如CPU使用率，內存/垃圾回收，TPS，和JVM參數。⑦
我們所講的編排實際是編制，是一種集中式的控制，也就意味着如果被編排的服務有響應緩慢的情況，可能會影響到其他服務。這時候我們需要更快的監控來幫助我們發現這類服務，從而儘早優化。
參考資料：
《服務都微了，編排怎麼整》
① https://yq.aliyun.com/articles/2764
② http://dockone.io/article/394
③ http://www.cnblogs.com/loveis715/p/5097475.html
④ http://blog.sciencenet.cn/home.php?mod=space&uid=298436&do=blog&id=278887
⑤ https://yq.aliyun.com/articles/60165
⑥ https://zhuanlan.zhihu.com/p/25933039
⑦ https://skyao.gitbooks.io/learning-pinpoint/content/
王文斌
普元高級軟件工程師，代碼高手，開源技術愛好者，容器技術專家，曾參與浦發BPM項目、銀聯PAASV1等項目。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
