在單體應用中，一個組件調用其它組組件時，是通過語言級的方法或者函數調用，而一個基于微服務的應用是運行于多個服務器上的分布式系統，每個服務實例是一個典型的進程。所以，如下圖顯示的，服務必須通過內部進程交互機制（IPC）進行交互。

 

 

交互風格

 

在為一個服務選擇IPC的時候，首先考慮一下這些服務是如何交互的是很有用處的。有多種client/server的交互風格，它們可以通過兩個維度分類，第一種維度是交互是一對一，還是一對多的：

 

• 一對一：每個客戶端的請求只被一個服務實例處理
• 一對多：每個客戶端請求被多個服務實例處理
• 第二種維度是交互是同步的還是異步的：
• 同步：客戶端期望從服務得到及時的返回，并且甚至可以因此阻塞片刻
• 異步：客戶端不會在等待返回結果的時候阻塞，返回結果也沒必要立刻被發送出來

 

下表顯示出各種交互風格：

 

有如下幾種一對一的交互形式：

 

請求/響應：客戶端發送一個請求給一個服務，并且等待響應結果，客戶端期望結果能快速的返回，在一個基于線程的應用中，發送請求的線程甚至可能在等待的時候被阻塞。

• 通知（一種單向請求）：客戶端發送一個請求到服務，但不期望有響應發送回來。
• 請求/異步響應：客戶端往服務發送請求，響應結果異步的返回。客戶端不會在等待的時候阻塞，而且客戶端是基于響應在一段時間之后才返回的假設來設計的。

有如下幾種一對多的交互形式：

• 發布/訂閱：客戶端發布消息，消息被零或者多個感興趣的服務消費
• 發布/異步響應：客戶端發布一個請求消息，等待固定的一段時間，以獲得從感興趣的服務返回的響應結果

 

每個服務一般都使用這幾種交互風格的組合風格。對于一些服務來說，單一的IPC機制就足夠了，而其它的服務可能需要組合使用若干種IPC機制。下面的圖給出當客戶請求行程時，在一個打車應用可能出現的一些交互。

 

 

這些服務使用了通知，請求/響應，發布/訂閱的交互方式。比如說，一個乘客的智能手機向行程管理服務發送了一個上車請求，行程管理服務通過請求/響應方式向乘客服務確認乘客的賬戶是否是活躍賬戶，行程管理服務于是創建一個行程訂單，并且用發布/訂閱方式通知其它的服務，包括一個分發服務，用以定位空閑的司機。

 

定義API

 

服務的API是服務與它所有的客戶端之間的一種契約，不管選用何種IPC機制，使用一些接口定義語言(IDL)，對于精確定義服務API是很重要的，甚至已經有一些關于使用API-first Approach來定義服務的好的討論。

 

開發一個微服務從書寫接口定義以及與客戶端開發人員一起review這些接口定義開始，在不斷的對這些API定義進行迭代，最終才算是實現了一個微服務。這種基于前端的設計方式，增加了構建出符合客戶端需求的機會。

 

在文章的后面你會看到，API定義的特性依賴與你使用的IPC機制，如果你使用消息機制，API就會涉及到消息通道和消息類型；如果你選用HTTP方式，那么API就會包含一些URL和請求/響應的格式，之后我們會詳細的介紹IDL。

 

API的演進

 

一個服務的API會隨著時間而經常變化。在單體應用中，通常是很直接的修改API，再更新所有的調用之處，但在基于微服務的應用中，情況要困難得多，甚至你API的所有消費者是同一個應用中的其它服務。你通常不能強迫所有的客戶端步調一致的升級它們的服務。而且你可能會大量的開發服務的新版本，于是新舊版本的服務會同時運行，制定一個處理這種問題的戰略原則顯得很重要。

 

如何處理一個API的變化，取決于這種變化的多少。有的變化很少，可以向后兼容之前的版本，比如，你可能只是在請求或者響應格式中增加一些屬性。設計出具有魯棒原則的客戶端和服務是有意義的，那些使用更舊的API的客戶端應該能夠繼續和新版本的服務工作得很好，服務會給請求中沒有的屬性提供默認值，客戶端會忽略那些響應中額外的屬性。使用IPC機制和消息格式是重要的，讓你能輕易的演進API。

 

有時候，你不得不對API做一些主要的、不兼容的改動。既然不能強制客戶端立刻升級，那這個服務必須能夠支持舊版本的API一定時期。如果你用的是基于HTTP的機制，如REST，一個好的辦法是在API的URL中嵌入版本號。每個服務實例應該可以同時處理不同版本的API請求，或者是部署不同的服務實例來處理不同的API版本。

 

處理部分失敗

 

在之前關于API網關的文章中曾經提到，在分布式系統中，總會存在部分失敗的風險，既然客戶端和服務是分開的進程，一個服務可能不能對一個客戶端請求及時的返回結果，服務也可能因為錯誤或者是維護停止了，亦或是因為過載而對請求響應緩慢。

 

比如說，如上篇文章中提到的那個產品詳頁的場景，試想一下如果那個推薦服務失去響應了，客戶端的一個本地實現就可能在無限的等待響應中被阻塞了，這不僅會帶來劣質的用戶體驗，而且在很多應用中，這會消耗寶貴的資源，如一個線程，最終運行時環境會線程耗盡，變成無法響應，正如下圖所示。

 

 

 

為了避免這種問題，把你的服務設計成能處理部分失敗是很有必要的。

 

Netfix給我們提出了一個可以遵循的好辦法，其中處理部分失敗的原則包括：

 

• 網絡超時：永遠不要無限的阻塞，總是在等待響應中使用超時，使用超時來確保資源不會被無限綁定。
• 限制未解決的請求數量：對一個客戶端持有的對一個服務沒有完成的請求，應該設定上限值，這個上限一旦達到，發送更多的請求就會是無意義的，而且這些新的請求需要立刻返回為失敗。
• 回路中斷器模式：跟蹤成功請求和失敗請求的數量，如果錯誤率超過了一個事先配置的閾值就開啟回路中斷器，讓進一步的嘗試立刻失敗。如果大量的請求正處在失敗中，那就預示服務不可用，而且發送請求也是無意義的。經過超時周期之后，客戶端應該再進行嘗試發送請求，如果請求成功，就關閉回路中短器。
• 提供回滾機制：一個請求失敗時，執行回滾邏輯，比如說返回緩存的數據或者是默認值，也或者諸如一個關于推薦商品的空集合。

 

Netfix Hystrix是這些模式的一種開源實現，如果你正在使用JVM，你肯定會考慮使用Hystrix的，如果你運行的是一個非JVM的環境，同樣需要考慮使用一個類似的庫。

 

IPC技術

 

有許多IPC技術可供選擇，如同步的請求/響應機制，這里面有基于HTTP方式的REST和Thrift，另外有基于消息的異步通信機制，如AMQP和STOMP。其中消息的格式也是多種多樣的，有一些是人可讀的，比如JSON和XML，有些是二進制格式的（這種更高效），如Avro和緩存協議。稍后我們介紹同步的IPC機制，但在這之前，先討論異步的IPC機制。

 

異步(基于消息的通信)

當使用消息時，進程間通過異步的交換消息來通信。客戶端通過向服務發送消息來發送請求，如果期望服務返回應答，那么它發送回一個獨立的消息給客戶端。由于通信是異步的，客戶端不會阻塞在等待返回結果上，客戶端應該是基于不會立刻收到返回結果的假設來實現。

 

消息包含消息頭（如發送者這樣的元數據）和消息體，各種消息在通道上交換，任意數量的生產者都能往通道上發送消息，同樣，任意數量的消費者也能從這個通道接收消息。有兩種類型的通道：點對點通道和發布/訂閱通道。點對點的通道只給連接到這個通道上的眾多消費者中的一個發送消息，服務使用這種通道往往是采用前面提到的一對一的交互風格。發布/訂閱這種通道，是給連接到它之上的所有消費者發送消息，這種通道往往被一對多風格的服務采用。

 

下圖描述的是，在打車應用中，發布/訂閱的通道是如何使用的

 

 

 

行程管理服務向發布/訂閱通道發送一個行程創建的消息，以此告訴那些對此感興趣的服務（比如說分發器服務），一個新行程創建了。分發器服務找到一個可用的司機，將一個需要提名司機的消息寫入發布/訂閱通道，這樣其它的服務就能得到這個通知。

 

有許多消息系統可供選擇，你應該選擇那些能支持多種開發語言的。一些消息系統支持AMQP和STOMP這些標準協議，其它的系統是一些專有而且文檔化的協議。現在有不少開源的消息系統，其中包括RabbitMQ，Apache Kafka，Apache ActiveMQ和NSQ。總體上看，他們都支持消息格式和通道，都是可靠的、高性能的和可擴展的，但它們在消息模型細節方面有著巨大的差異。

 

使用消息有諸多優點：

 

• 把客戶端從服務中解耦出來：客戶端只需要簡單的往正確的通道里發消息，它完全不用感知服務實例，它不需要通過發現機制來定位服務實例所在的位置。
• 消息緩沖：在使用HTTP這種同步的請求/響應協議時，客戶端和服務都必須在交換數據的時候保持可用。與此相反，消息代理會將寫到通道里面的消息隊列化，直到消費者能夠處理這些消息。這意味著，比如，對訂單的消息進行簡單的隊列化之后，即使是訂單填寫系統響應緩慢或者不可用，一個在線商店仍然可以接收到來自客戶的訂單。
• 靈活的客戶——服務交互：消息機制支持之前提到的所有交互風格。
• 顯式的進程間通信：基于RPC的機制能夠讓調用遠端的服務看起來如同調用本地服務，但由于存在物理規則和部分失敗的可能，這些機制都有較大不同。消息機制讓這些不同之處變得很顯式，這樣程序員不用陷于安全失誤當中。

 

當然，消息機制也有缺點：

 

• 額外的操作復雜性：消息系統是另外一個系統，必須安裝，配置和操作，消息代理必須高可用，要不然整個個系統的可靠性將受到影響。
• 實現基于請求/響應的交互比較復雜：請求/響應風格的交互要求一些實現上的工作，每個請求消息必須包含一個應答通道ID和關聯ID，服務將相關ID包含在響應的消息中，并發送到響應通道，客戶端就通過這個相關ID來將響應和請求匹配起來。使用IPC機制來直接支持請求/響應通常簡單一些。

 

現在我們已經討論完了基于消息的IPC，接下來探討一下基于請求/響應的IPC

 

同步的請求/響應IPC

在同步的、基于請求/響應的IPC機制中，客戶端向服務發送一個請求，服務處理這個請求，并將響應發回。在許多客戶端的實現中，發送請求的線程會在等待響應的時候阻塞。

 

而另一些客戶端的實現，可能使用異步的、事件驅動的方式，請求相關的代碼會被封裝在Futrues或者Rx Observables這樣的庫中。和前面介紹的消息機制不同，在這種IPC里客戶端是假設響應會及時返回。有很多協議可供選擇，其中有兩種很流行：REST和Thrift。我們先來看看REST

 

REST

目前，使用RESTful風格來開發API是很流行的做法，REST是使用HTTP的IPC機制，REST的一個關鍵概念是資源，資源代表一個業務對象，比如說一個客戶，一個產品，或者是一些業務對象的集合。REST使用HTTP的方法來操作資源，通過URL來引用資源。比如，GET請求會返回一個資源的信息，返回結果用XML文檔或者JSON對象來表示，POST請求創建一個資源，PUT請求是更新一個資源。REST的創建者Roy Fielding的描述如下：

 

“REST提供一個架構約束的集合，當被整體應用時，強調組件交互的擴展性、接口的普遍性，組件的獨立部署，減少交互延時的中間組件，增強的安全性以及對遺留系統的封裝。”

 

下圖展示了打車應用中使用REST的一個場景。

 

 

 

乘客的智能手機向行程管理服務發送創建行程的請求，這個時候一個POST請求發送到服務端，請求創建一個/trips資源，行程管理服務隨后發送一個GET請求到乘客管理服務，來獲取乘客的信息，在確認了這個乘客是一個授權過可以創建行程的用戶之后，行程管理服務正式的創建出行程，并且返回一個201結果給智能手機。

 

很多開發者都聲稱他們的HTTP API都是RESTful的，但如Fielding在他的這篇博客里描述的，其實他們不一定都是。Leonard Richardson給出了一個很有用的REST成熟度模型，包含如下一些級別：

 

• 級別0：客戶端通過發送基于HTTP的POST請求到唯一的URL服務端，每個請求指定要執行的動作，動作的對象（比如業務對象），以及其它任何參數。
• 級別1：支持資源的概念，為了在一個資源上執行動作，客戶端需要在POST請求中指定執行的動作和所有的參數。
• 級別2：API使用HTTP的動詞來執行動作：GET用來獲取，POST用來創建，PUT用來修改。請求要求參數和請求體，如果有，還需要指定動作的參數，這樣服務就可以利用頁面系統的一些基礎設施，如緩存GET請求。
• 級別3：這個級別的API是基于HATEOAS（超文本應用狀態引擎）原則的，基本思想是在GET請求返回的代表資源的響應中，需要包含一些鏈接，這些鏈接對應與可對這個資源執行的動作。舉個例子，訂單的GET請求的返回結果中會包含操作的鏈接，其中有取消訂單的操作鏈接，客戶端可以從結果中找到這個鏈接，使用它取消訂單。
• HATEOAS的優勢在于不再需要將URL硬編碼到客戶端的代碼里面去了，另一個好處是由于資源的返回結果中已經包含允許的操作的鏈接，客戶端不用去猜測當前狀態下能對資源做哪些操作了。

 

使用基于HTTP的協議的好處有：

 

• HTTP對與大家來說簡單而熟悉。
• 可以用一些有Postman這種插件的瀏覽器來測試API，也可以用curl這種命令行工具來測試（返回結果是用JSON或者其它類型的文本格式）
• 直接支持請求/響應風格的通信
• HTTP是防火墻友好的
• 不需要有中間代理，這讓系統的架構得到簡化

 

使用HTTP也有缺點：

 

• 只支持請求/響應的交互風格，這使得在使用HTTP來發送通知的時候，服務端必須總是發送HTTP響應回來。
• 因為客戶端和服務端直接通信（中間沒有緩沖消息），他們在交換信息期間必須同時處于運行狀態。
• 客戶端必須知道每個服務實例的地址（比如URL），正如在上一篇文章中描述的，在現代應用中，這倒不是個重要的問題，一般客戶端都需要使用服務發現機制來定位服務實例的位置。

 

開發者社區最近發現了接口定義語言對RESTful API的新價值，這方面有一些選擇，包括RAML和Swagger。一些諸如Swagger的IDL允許定義出請求和響應消息的格式，其它一些諸如RAML的IDL則要求使用獨立的規范，如JSON schema。在描述API的同時，IDL一般也有工具來給接口定義生成客戶端樁和服務端骨架。

 

Thrift

Apache Thrift是REST的一種有趣的替代方案，它是開發跨語言RPC客戶端和服務端的框架，Thrift提供C語言風格的IDL來定義你的API，使用Thrift編譯器生成客戶樁和服務骨架，編譯器能夠生成各種語言的代碼，包括C++，JAVA，Python，php，Ruby，Erlang和Node.js。

 

一個Thrift接口包含一個或多個服務，定義服務與定義Java接口類似，是一些強輸入方法的集合，Thrift方法可以定義城返回一個值（也可能是void的），或者定義成單向方法。返回一個值的方法都會實現請求/響應的交互風格。客戶端等待請求，并且有可能拋出異常。單向方法其實是符合通知風格的交互，服務端不會發送響應。

 

Thrift支持多鐘消息格式：JSON，二進制，緊湊的二進制。二進制格式通常比JSON更高效一些，因為解析它更快。對于緊湊二進制格式，如它的名字一樣，它是節省空間的消息。而JSON，當然是對人和瀏覽器友好的一種格式。在Thrift中，也可以自己選擇傳輸協議，其中包括原始TCP和HTTP。TCP一般比HTTP更高效一些，當然，HTTP是對防火墻、瀏覽器和人友好的。

 

消息格式

前面已經討論過HTTP和Thrift，現在介紹消息格式的問題。如果使用消息系統或者REST，需要確定消息格式。其它一些如Thrift這種IPC機制只支持有限的集中消息格式，或許就一種而已。在任何一種情況中，使用跨語言的消息格式是很重要的。甚至你現在只是用一種語言來實現你的微服務，很可能你將來會使用其它的語言。

 

有兩種主要的消息格式：文本和二進制碼。基于文本的格式有JSON，XML這些。它們的優點在于是人可讀的，而且是自描述的。在JSON中，對象的屬性被表示成名稱-值對的集合。類似的，在XML中，屬性被表示成名字元素和值。這可以讓消息消費者能夠找到感興趣的值，同時忽略其它的。而且，對格式的小量改動可以容易的兼顧到后向兼容性。

 

XML文檔的結構是在XML schema文件中定義的，漸漸的社區的開發者意識到JSON也需要類似的機制，其中一個解決辦法是使用JSON schema，以獨立方式存在或者是如Swagger這種IDL的一部分。

 

基于消息的格式的一個缺點是比較繁瑣，尤其是XML。因為消息是自描述的，除了包含屬性的值之外，消息里還包含屬性的名稱。另外一個劣勢是，解析消息文本需要開銷。基于這些，你可能更想使用二進制碼格式

 

有幾種二進制格式可供選擇。當用Thrift RPC，你可以選擇二進制的Thrift。如果使用消息格式，比較流行的選擇是Protocol Buffers和Apache Avro。這兩種格式都提供輸入的IDL來定義消息結構。不同之處在于，Protocol Buffers使用標簽域，而Avro，它的消費者在翻譯消息前，需要提前知道消息的schema。這篇博客完美解釋了Thrift， Protocol Buffers和Avro的異同之處。

 

總結

 

微服務必須使用一種進程間通信機制，當設計你的服務如何通信時，需要考慮各種問題：服務如何交互，如何為每個服務設計API，如何演進API，以及如何處理部分失敗問題。有兩種微服務可用的IPC機制，異步的消息機制和同步的請求/響應機制。在這一系列文章的下一篇文章中，我們會研究在微服務架構中的服務發現問題。

英文原文：https://www.Nginx.com/blog/building-microservices-inter-process-communication/

原文：https://mp.weixin.qq.com/s/0DxXxtMEWKnxZVg_xcbwvA

作者：朱曉廝的博客

來源：微信公眾號