筆者做過公司多個專案的微服務架構和改造，就微服務間的通訊這個問題來發表一下自己的看法。

首先需要明確一點，微服務間的通訊，其實就是不同程序之間的通訊。通訊模式的具體應用：遠端過程呼叫、斷路器、客戶端發現、自注冊、服務端發現、第三方註冊、非同步訊息、事務性發件箱、事務日誌拖尾、輪詢釋出者。

筆者從三點來講述如何選擇微服務間的通訊方式：

基於同步遠端過程呼叫模式的通訊

基於非同步訊息模式的通訊

使用非同步訊息提高可用性

1 基於同步遠端過程呼叫模式的通訊

使用基於遠端過程呼叫（RPI）的程序間通訊機制時，客戶端想服務傳送請求，服務處理該請求併發迴響應。有些客戶端可能會處在堵塞狀態並等待響應，而其他客戶端可能會有一個響應式的非阻塞架構。但與使用訊息機制不同，客戶端假定響應將及時到達。

上圖是典型的遠端過程呼叫的工作原理。上圖中的代理介面通常封裝底層通訊協議。比如常用的REST和gRPC。

1.1 使用REST

使用REST有如下優點：

簡單、大眾認可可以使用瀏覽器擴充套件或者curl之類的命令列來測試http api支援直接請求/響應方式的通訊；HTTP對防火牆友好；不需要中間代理，簡化系統架構。

不過也存在如下的不足：

只支援請求/響應方式的通訊；可能導致可用性降低；客戶端必須知道服務例項地址endpoint；在單個請求中獲取多個資源具有挑戰性。

1.2 使用gRPC

gRPC是一個用於編寫跨語言客戶端和服務端的框架，是一種基於二進位制訊息的框架。使用gRPC有如下優點：

設計具有負責更新操作的API非常簡單；

高效、緊湊的程序間通訊機制，尤其是在交換大量資訊時更能體現其優勢；

支援在遠端過程呼叫和訊息傳遞過程中使用雙向流式訊息方式；

實現了客戶端和用各種語言編寫的服務端之間的互操作性。

不過也存在不足：

與基於REST/JSON的API機制相比，js客戶端使用基於gRPC的API需要增加很多工作量；舊式防火牆可能不支援HTTP/2

2 基於非同步訊息模式的通訊

使用訊息機制時，服務之間的通訊採用非同步交換訊息的方式完成。基於訊息機制的應用程式通常使用訊息代理，它充當服務之前的中介。另一種選擇是使用無代理架構，透過直接向服務傳送訊息來執行服務請求。由於通訊是非同步的，因此客戶端不會阻塞和等待回覆。

我們一般使用訊息代理來進行訊息傳遞。有許多訊息代理可供選擇，比如：

Apache ActiveMQ

RabbitMQ

Apache Kafka

還有基於雲的訊息服務

基於代理的訊息有很多好處：松耦合、訊息快取、靈活的通訊、明確的程序間通訊。不妥也有一些潛在的效能瓶頸，比如潛在的單點故障、操作複雜性等。3 使用非同步訊息提高可用性

透過上面的描述，我們大致瞭解了兩類通訊機制。通常需要根據實際的需求在不同的程序間通訊機制之間權衡利弊。其中一個重要權衡因子，就是程序間通訊機制與系統的可用性之間的關係。

與其他服務採用同步通訊機制作為請求處理的一部分，會對系統的可用性帶來影響。因此應儘可能選擇一部通訊機制來處理服務間的呼叫。