原文鏈接:Building Microservices: Inter-Process Communication in a Microservices Architecture

1. 微服務(wù)介紹
2. 構(gòu)建微服務(wù)之使用API網(wǎng)關(guān)
3. 構(gòu)建微服務(wù)之:微服務(wù)架構(gòu)中的進程間通信(本文)
4. 微服務(wù)中的服務(wù)發(fā)現(xiàn)
5. 微服務(wù)之事件驅(qū)動的數(shù)據(jù)管理
6. 選擇一種微服務(wù)部署策略
7. 重構(gòu)單體應(yīng)用到微服務(wù)

這是使用微服務(wù)架構(gòu)構(gòu)建應(yīng)用系列的第三篇文章。第一篇文章介紹了微服務(wù)架構(gòu)模式并討論了使用微服務(wù)的優(yōu)勢和劣勢 ；第二篇文章介紹了應(yīng)用的客戶端如何通過API網(wǎng)關(guān)作為中介實現(xiàn)服務(wù)間的通信渊跋；在這篇文章中我們將看一看同一系統(tǒng)間的服務(wù)如何通信幕与；第四篇文章主要介紹服務(wù)發(fā)現(xiàn)的問題茎刚。

介紹

在傳統(tǒng)單體應(yīng)用中梧却，模塊間使用編程語言級別的方法或功能彼此調(diào)用缘挑。然而微服務(wù)架構(gòu)應(yīng)用本質(zhì)上是運行在多臺機器上的分布式系統(tǒng)氮惯，每個服務(wù)都是一個進程！因此赦役，下圖為我們展示捕传，微服務(wù)必須使用進程間通信（IPC）的機制實現(xiàn)交互：

Paste_Image.png

稍后，我們將看具體的 IPC 技術(shù)實現(xiàn)扩劝，但首先讓我們探討不同方案設(shè)計中的問題庸论。

交互風(fēng)格

當我們?yōu)榉?wù)選擇一種IPC機制的時候，我們首先要考慮服務(wù)間如何交互棒呛，技術(shù)上存在多種 client?service 交互風(fēng)格：它們可以按照兩大維度分類：第一維度是服務(wù)間交互是一對一還是一對多聂示；

• 一對一：每個客戶端請求只會被一個服務(wù)實例處理。
• 一對多：每個請求將會被多個服務(wù)實例處理

第二個維度是交互是同步模式還是異步模式：

• 同步：客戶端期望來自服務(wù)端的及時響應(yīng)簇秒，甚至可能阻塞并等待鱼喉。
• 異步：客戶端等待響應(yīng)時不會阻塞，對異步來講趋观，及時響應(yīng)并不是必須的扛禽。

下列表格展示了兩種方式的不同

有下面幾種一對一的交互方式：

• 請求/響應(yīng)模式： 客戶端向服務(wù)端發(fā)送請求并等待響應(yīng)，并期望服務(wù)端可以及時的返回響應(yīng)皱坛。在一個基于線程的應(yīng)用中编曼，發(fā)出請求的線程可能在等待時阻塞線程的執(zhí)行。
• 通知（也就是單向請求）：客戶端往服務(wù)端發(fā)送請求剩辟，但并不等待響應(yīng)返回
• 請求/異步響應(yīng)：客戶端往一個異步返回響應(yīng)的服務(wù)發(fā)送請求掐场。客戶端等待式并不會阻塞線程贩猎，因為設(shè)計時就假設(shè)請求不會立即返回（js回調(diào)）

有下面幾種一對多的交互方式：

• 發(fā)布/訂閱模式：客戶端發(fā)布一個通知消息熊户，消息將會被0或多個感興趣的服務(wù)消費
• 發(fā)布/異步響應(yīng)：客戶端發(fā)布一個請求消息，并在一定時間內(nèi)等待消費消息的服務(wù)響應(yīng)吭服。

每個服務(wù)通常會使用多種交互風(fēng)格的組合：對一些服務(wù)來講嚷堡，簡單的IPC機制可能已經(jīng)足夠了，但另外一些服務(wù)可能需要幾種IPC機制的組合艇棕。下圖展示了在taxi-hailing應(yīng)用中蝌戒，當用戶請求行程時绿饵，服務(wù)是如何交互的：

Paste_Image.png

這個服務(wù)使用了通知、請求/響應(yīng)瓶颠、發(fā)布/訂閱風(fēng)格的組合。比如刺桃，乘客使用智能手機向行程管理服務(wù)發(fā)送一個接送需求的通知粹淋，行程管理服務(wù)將使用請求/響應(yīng)模式調(diào)用乘客服務(wù)來驗證乘客賬號是否為活動狀態(tài)，然后行程管理服務(wù)創(chuàng)建行程并使用發(fā)布/訂閱方式來通知諸如分發(fā)器（用來定位空閑司機）等服務(wù)瑟慈。

我們已經(jīng)討論了交互風(fēng)格桃移，那么再來看下如何定義API。

定義API

服務(wù)API是服務(wù)與客戶之間的契約葛碧。拋開選擇哪種IPC機制的選擇借杰，使用一些接口定義語言interface definition language (IDL)準確定義服務(wù)API是很重要的！.當然进泼，最好考慮使用API優(yōu)先的方式來定義服務(wù)蔗衡，通過先寫接口定義語言來開始開發(fā)，并與客戶端開發(fā)者（服務(wù)消費者）一起review你的設(shè)計乳绕，先對API定義進行迭代绞惦，再去實現(xiàn)這些服務(wù)。這樣做設(shè)計的話將會使你構(gòu)建更加符合客戶需求的服務(wù)洋措！

后續(xù)文章你將會發(fā)現(xiàn)济蝉，服務(wù)定義和你選擇哪種IPC機制息息相關(guān)，如果你是要消息機制菠发，API就由消息頻道和消息類型組成王滤；如果你使用http，API就是由URLs以及request/response格式組成滓鸠。稍后我們將會討論更多關(guān)于接口定義語言的細節(jié)雁乡。

API進化

服務(wù)API將會不可避免的隨著時間進化，在傳統(tǒng)單體應(yīng)用中糜俗，我們可以很直接的去修改服務(wù)并更新所有服務(wù)的調(diào)用者（refactor）蔗怠。但是在基于微服務(wù)架構(gòu)的應(yīng)用中，哪怕服務(wù)API的其他消費者都是在一個應(yīng)用中吩跋，去更新所有服務(wù)也是相當困難的寞射。你通常不能強制讓所有的客戶端升級來保持和服務(wù)端升級維持步調(diào)一致，而且锌钮，你還可能會增量部署新服務(wù)使得新老服務(wù)同時運行桥温，尋找一種處理此種情況的策略是很重要的。

你是如何根據(jù)更改的大小來處理服務(wù)API的變化的呢梁丘？一些變化很小侵浸，通惩拢可以與之前版本做到向后兼容，比如掏觉，你為請求或相應(yīng)添加了一個屬性区端；對此，設(shè)計服務(wù)時考慮服務(wù)和客戶消費者的魯棒性原則是很有必要的：使用就版本服務(wù)API的客戶端可以在新版本服務(wù)API下正常工作澳腹，服務(wù)端為客戶端缺失的屬性提供默認值织盼，客戶端自動忽略額外添加的響應(yīng)屬性。最后強調(diào)酱塔，注意使用IPC機制和定義消息格式使你的API可以簡單方便的進化沥邻！

當然，有時候我們不得不對API做一些較大的羊娃，不再兼容的變化唐全，而我們這時候又不可能強制每個客戶端升級，因此我們的服務(wù)就要繼續(xù)支持運行一段時間的老版本API蕊玷。如果使用http邮利，我們可以在URL里嵌入服務(wù)版本，每個服務(wù)實例可能同時處理多個版本的服務(wù)垃帅，當然近弟，你也可以選擇為每個服務(wù)版本部署單獨的服務(wù)實例。

處理局部故障

就像前面關(guān)于API網(wǎng)關(guān)文章提到的那樣：在分布式系統(tǒng)中總會有無時無刻的局部故障的風(fēng)險挺智。由于客戶端和服務(wù)在不同的進程中祷愉，服務(wù)可能由于掛掉或者維護原因而不能及時響應(yīng)客戶端的請求，或者服務(wù)由于過載原因?qū)е马憫?yīng)緩慢赦颇。

比如二鳄，讓我們考慮之前文章提到的Product details場景，假設(shè)推薦服務(wù)沒有響應(yīng)了媒怯，一個簡單的客戶端實現(xiàn)可能無期限的等待服務(wù)響應(yīng)并阻塞订讼，這樣不僅導(dǎo)致糟糕的用戶體驗，在很多應(yīng)用中還會消耗比如線程這樣寶貴的資源扇苞，最終就像下圖展示的那樣欺殿，運行時將會用盡所有線程使得服務(wù)不再響應(yīng)任何請求：

Paste_Image.png

為解決此類問題，設(shè)計上處理局部故障是很有必要的鳖敷。

Netflix給出了一些處理局部故障比較好的方法：

• 網(wǎng)絡(luò)超時：等待響應(yīng)時不要一直阻塞脖苏，而是使用超時，超時能夠保證資源不會一直被占用
• 限制未完成請求的數(shù)量：針對一個請求某服務(wù)的客戶端定踱，需要設(shè)置其未處理請求數(shù)量的上限棍潘，一旦超過限制就不再處理任何請求，這樣就做到快速失敗。
• 斷路器模式：跟蹤成功和失敗請求的數(shù)量亦歉，如果比率超過了設(shè)置的閥值恤浪，打開斷路器使得后續(xù)請求快速失敗。如果大量請求失敗肴楷，就建議服務(wù)為不可以狀態(tài)并決絕處理新請求水由，過一段時間之后，客戶端可以再次重試赛蔫，一旦成功砂客，關(guān)閉斷路器。
• 提供fallback機制：請求失敗時提供fallback濒募，比如返回緩存值或者為失敗的推薦服務(wù)返回默認空集合作為默認值。
  Netflix Hystrix是一個實現(xiàn)了這些模式的開源工具包圾结，如果你使用JVM那么一定要考慮使用它瑰剃！如果你的服務(wù)不是運行在JVM中，那也要考慮有等效的實現(xiàn)來處理此類問題筝野。

IPC 技術(shù)

我們有不同的IPC技術(shù)可供選擇：服務(wù)可以使用基于請求/響應(yīng)的同步通信模式晌姚，比如基于Http的REST或者Thrift，當然歇竟，也可以使用異步基于消息的通信模式挥唠，比如AMQP、STOMP焕议。這些通信模式有不同的消息格式宝磨，服務(wù)可以使用基于文本格式、方便閱讀的JSON 或者 XML格式盅安，也可以使用效率更高的二進制格式（比如Avro或Protocol Buffers）唤锉。稍后我們將討論同步IPC機制，現(xiàn)在我們先討論下異步的IPC機制：

異步别瞭，基于消息的通信

使用消息時窿祥，進程間通過異步交換消息來通信。一個客戶端通過發(fā)送消息的方式請求服務(wù)蝙寨，如果期望服務(wù)有響應(yīng)晒衩，也是服務(wù)通過向客戶端發(fā)送另外的消息來實現(xiàn)。由于通信是異步的墙歪，客戶端不會為了響應(yīng)等待并阻塞听系，相反的，客戶端編程時就是以服務(wù)不會立即返回響應(yīng)來處理的虹菲。

一條消息包含消息頭（元數(shù)據(jù)和發(fā)送者）和消息體跛锌，消息通過頻道進行交換，任意數(shù)量的消費者都可以往頻道中發(fā)消息，任意數(shù)量的消費者也可以消費頻道中的消息髓帽。有point?to?point和publish?subscribe兩種頻道：point?to?point模式下菠赚，頻道的消息只會被交付到某一個消費者，這種模式用于前面提到的一對一的交互郑藏；publish?subscribe 模式下衡查，頻道的消息將會交付到所有感興趣的消費者，使用于前面提到的一對多交互風(fēng)格必盖。

下圖展示了taxi-hailing 應(yīng)用可能是一publish-subscribe模式：

Paste_Image.png

有多種消息系統(tǒng)供我們選擇歌粥，當然我們盡量選擇一個支持多種編程語言的來使用塌忽。一些消息系統(tǒng)支持標準的協(xié)議比如 AMQP和STOMP，另一些消息系統(tǒng)有專有但是文檔化的協(xié)議失驶，大量的開源消息系統(tǒng)可供我們挑選土居，包括RabbitMQ、Apache Kafka嬉探、Apache ActiveMQ和NSQ擦耀。統(tǒng)一的來看，他們都支持某種形式的消息和頻道涩堤，都致力于高可靠眷蜓，高性能和高擴展性，但是每個消息中介在實現(xiàn)細節(jié)上還是有很大的不同：
使用消息系統(tǒng)有很多優(yōu)點：

• 客戶端與服務(wù)端解耦： 客戶端只需要向合適的頻道發(fā)送消息就實現(xiàn)簡單的請求胎围，客戶端完全感知不到服務(wù)實例的存在吁系，因此不需要再去使用一套服務(wù)發(fā)現(xiàn)機制去決定服務(wù)實例的位置。
• 緩存消息：在同步的請求/響應(yīng)協(xié)議白魂，比如HTTP下垮抗，客戶端和服務(wù)端在交互的階段必須保證雙方都可用，然而碧聪，消息中介會把消息寫入隊列直到消息被消費者處理位置冒版，這意味著，盡管 在訂單履行系統(tǒng)響應(yīng)緩慢甚至不可用情況下逞姿，在線商城仍然可以接受來自客戶的訂單辞嗡，只需要先把訂單消息簡單的入隊即可。
• 靈活的客戶-服務(wù)端交換風(fēng)格滞造，消息支持前面提到的所有交互風(fēng)格续室。
• 顯示的進程間通信：基于 RPC的通信機制試圖使調(diào)用遠程服務(wù)等同于調(diào)用本地服務(wù)。然而谒养，由于物理定律和局部故障的可能性挺狰，事實上他們相當不同。消息使這些差異非常明顯，因此開發(fā)人員不被虛假的安全感所迷惑丰泊。

當然消息系統(tǒng)也有缺點：

• 額外的運維復(fù)雜度：消息系統(tǒng)畢竟也是額外的系統(tǒng)組件薯定，也要求安裝、配置瞳购、運維等操作话侄，有必要保證消息系統(tǒng)的高可用，否則會影響整個系統(tǒng)的穩(wěn)定性学赛。
• 實現(xiàn)請求/響應(yīng)交互的復(fù)雜度：要實現(xiàn)請求/響應(yīng)的交互風(fēng)格還是要做些額外工作的：每條請求消息必要要包含回復(fù)頻道的標志符以及關(guān)聯(lián)標志符 年堆，服務(wù)回寫包含關(guān)聯(lián)ID的消息到回復(fù)頻道，客戶端使用關(guān)聯(lián)ID去匹配請求對應(yīng)的響應(yīng)盏浇。當然变丧，如果使用直接支持請求/響應(yīng)的基于IPC機制的方式，將會特別簡單绢掰。

我們已經(jīng)討論了基于消息的IPC痒蓬，再看檢驗下基于請求/響應(yīng)的IPC吧：

同步，基于請求/響應(yīng)的IPC

當使用同步曼月，基于請求/響應(yīng)的IPC機制的時候谊却，客戶端向服務(wù)端發(fā)送請求柔昼，服務(wù)端處理請求并返回響應(yīng)哑芹，很多客戶端，發(fā)出請求的線程會在等待響應(yīng)過程中阻塞捕透，另外有一些客戶端也會使用異步聪姿、事件驅(qū)動的代碼，比如封裝好的Futures 或 Rx Observables乙嘀。然而末购，和使用消息不一樣，客戶端假設(shè)請求會立即返回虎谢。有幾種方案供我們選擇盟榴，比較流行就是REST和 Thrift，我們先看下REST：

REST

限制使用REST風(fēng)格暴露API很流行婴噩，REST基本就是使用HTTP的IPC 機制擎场，REST的關(guān)鍵理念是資源，也就是通常代表諸如用戶或產(chǎn)品的某個或一組業(yè)務(wù)對象几莽，REST使用HTTP verbs維護URL指向的資源迅办，比如 GET返回某資源的表示，可能是XML也可能是JSON對象章蚣， POST會創(chuàng)建新資源站欺，PUT更新資源··· 引用自Roy Fielding，提出REST的大牛：

“REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”
—Fielding, Architectural Styles and the Design of Network-based Software Architectures

下圖展示了**taxi-hailing **應(yīng)用使用REST的場景：

Paste_Image.png

乘客向行程服務(wù)/trips發(fā)送POST請求，行程服務(wù)通過向乘客管理服務(wù)發(fā)送GET請求獲取乘客信息矾策，在驗證完乘客授權(quán)之后磷账，創(chuàng)建行程，行程服務(wù)創(chuàng)建行程后返回201響應(yīng)給手機.

很多用了HTTP暴露服務(wù)API的開發(fā)就說自己是REST蝴韭，其實按照 Fielding 在blog post描述的規(guī)定够颠，他們根本不是REST。 Leonard Richardson (no relation)定義了非常有用的 maturity model for REST組成了下面幾個級別：

• Level 0 :客戶端使用HTTP POST調(diào)用服務(wù)固定的URL榄鉴，每次請求指定動作和參數(shù)
• Level 1：支持資源的概念履磨，請求通過POST，并且要制定要做的動作和參數(shù)
• Level 2：充分使用 HTTP verbs 執(zhí)行動作GET獲取資源 POST創(chuàng)建資源PUT更新資源庆尘，還是要請求參數(shù)和請求體剃诅，還可以指定請求的參數(shù)，使得服務(wù)充分使用web基礎(chǔ)架構(gòu)的功能驶忌，比如緩存請求等
• Level 3: API定義按照HATEOAS (Hypertext As The Engine Of Application State) 原則矛辕。基本的定義就是GET請求返回表示資源的body中包含一些對資源允許動作的鏈接付魔。比如聊品，客戶端可以使用get訂單返回的訂單body中的一個超鏈接取消一個訂單。HATEOAS 優(yōu)點之一是：客戶端不用在代碼中硬編碼URL了几苍，另外翻屈，由于返回的body中包含允許對資源所作動作的超鏈接，客戶端就不需要再猜測當前資源狀態(tài)下他可以做哪些操作了妻坝。

使用基于HTTP的協(xié)議的優(yōu)點有：

• HTTP 簡單而且大家都熟悉
• 可以用瀏覽器測試伸眶，配合比如Postman插件更佳，命令行curl也很方便（假設(shè)使用json或其他數(shù)據(jù)格式）
• 直接就支持請求/響應(yīng)風(fēng)格的通信
• HTTP很友好
• 無需中介刽宪，簡化架構(gòu)

使用HTTP的缺點：

• HTTP只支持請求/響應(yīng)風(fēng)格的交互厘贼，你可以使用HTTP請求向服務(wù)器發(fā)送通知，但是服務(wù)器一定要返回HTTP響應(yīng)圣拄。
• 客戶端和服務(wù)端沒有消息buffer機制嘴秸，交互都是直接的，這就要求交換消息的時候雙方必須同時運行庇谆。
• 客戶端必須知道每個服務(wù)實例的地址岳掐，比如URL，正如前面的API網(wǎng)關(guān)文章描述的那樣，在現(xiàn)代流行的應(yīng)用架構(gòu)中，這已經(jīng)不再是一個問題挤渐，我們可以使用服務(wù)發(fā)現(xiàn)機制來定位服務(wù)實例矢洲。

開發(fā)者論壇最近又重新發(fā)掘了RESTful API風(fēng)格接口定義語言的價值，我們可以選擇使用RAML或者Swagger等工具沥匈， Swagger允許定義請求響應(yīng)的消息格式碟狞，RAML則要求你使用額外的諸如JSON Schema這樣的定義.IDL除了描述API律罢，通常還會提供根據(jù)接口定義生產(chǎn)客戶端Stub或服務(wù)端骨架的工具耕姊。

Thrift

Apache Thrift是REST的一個很有意思的替代品桶唐，它是一個實現(xiàn)跨語言客戶端與服務(wù)端RPC通信的框架。Thrift提供C語言風(fēng)格的接口定義語言來定義API茉兰，你可以通過編譯生成客戶端Stub和服務(wù)端的骨架尤泽，編譯器可以為 C++、Java规脸、Python坯约、PHP、Ruby莫鸭、Erlang闹丐、Node.js等不同語言生產(chǎn)代碼。

一個Thrift接口包含一個或多個服務(wù)被因，一個服務(wù)定義可以類比java的接口：都是一組強類型方法的集合卿拴。Thrift方法可以返回值也可以被定義為單向通信，如果方法需要返回值就需要實現(xiàn)請求/響應(yīng)風(fēng)格的交互梨与，客戶端等待響應(yīng)的時候可能會拋出異常堕花；單向通信就是我們前面講到的通知風(fēng)格的交互，服務(wù)端不需要返回響應(yīng)粥鞋。

Thrift支持不同的消息格式：JSON缘挽、binary以及compact binary。 Binary相對JSON更加高效陷虎，因為解碼速度更快到踏，compact binary比JSON空間利用率高杠袱，見名知意嘛尚猿，JSON則對人和瀏覽器更加的友好 ；Thrift也支持不同的通信協(xié)議選擇：原生TCP或者HTTP楣富，原生TCP相比HTTP肯定更加高效凿掂，但是HTTP對防火墻、人以及瀏覽器更加的友好纹蝴。

消息格式

既然我們已經(jīng)討論了HTTP和Thrift庄萎，現(xiàn)在再來探討下消息格式的問題吧：如果你需要消息系統(tǒng)或者REST風(fēng)格交互，你就必須選擇消息格式塘安。其他類似Thrift的IPC機制可能只支持一小部分的消息格式糠涛，甚至只會支持一種！在某些情況下兼犯，使用一種支持跨語言的消息格式非常重要忍捡，哪怕你現(xiàn)在只有一種語言實現(xiàn)微服務(wù)集漾，誰又能保證你以后不會使用新的語言呢？

主要有文本和二進制兩種格式：文本格式包括JSON和XML等砸脊，文本格式不僅僅方便閱讀具篇，而且是自描述的，JOSN中對象屬性是采用一組鍵值對的組合來表示的凌埂；同樣驱显，XML的屬性是采用命名元素和值來表示的，這樣允許消費者只挑選感興趣的消息摒棄其他消息瞳抓，因而這種方式也可以方便的做到向后兼容埃疫。

XML文檔的結(jié)構(gòu)是由XML schema來指定的，隨著時間的流逝孩哑，開發(fā)者論壇逐步意識到JSON也需要類似的機制：一種選擇是使用JSON Schema熔恢，要么單獨使用，要么作為類似Swagger這種IDL的一部分使用臭笆。

文本格式消息的缺點是非常的冗長叙淌，尤其是XML格式：由于消息是自描述的，每條消息除了值之外還包含屬性的名稱愁铺，另一個缺點就是解析文本開銷略大鹰霍，這時候可以考慮下二進制格式。

二進制格式也有多種選擇：如果使用Thrift茵乱，你可以選擇Thrift binary茂洒，如果選擇其他的消息格式，比較流行的還有Protocol Buffers和Apache Avro瓶竭，兩種格式都提供了IDL來定義消息的結(jié)構(gòu)督勺。區(qū)別是，Protocol Buffers使用標記字段斤贰，而Avro 消費者則需要了解Schema才能解析消息智哀，因此使用Protocol Buffers時，API進化比Avro更容易荧恍。這篇 文章是一個對Thrift瓷叫、 Protocol Buffers以及 Avro非常好的比較。

總結(jié)

微服務(wù)需要使用進程間通信的機制進行交互送巡，當設(shè)計你的服務(wù)如何通信的時候摹菠，需要考慮多個問題：服務(wù)如何交互、如何為服務(wù)定義API骗爆、如何處理API進化次氨、如何處理局部故障。有兩種微服務(wù)可以使用的IPC機制：異步消息和同步的請求/響應(yīng)摘投。該系列的下一篇文章煮寡，將會講解微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)問題屉佳。