在微服務架構中，會將一個完整的應用程序拆分成一組服務。這些服務之間需要經過協作，通過接口調用，才能組成一個完整的應用。

不同的服務部署在不同的機器上，或者同一個機器的多個容器中，進程間進行通信就不可避免了，也變得非常重要。

按種類來分，進程間的通信方式有很多種，比如遠程過程調用的 RESTful API 和 gRPC 、基于消息機制的異步方式等。

• RESTful API ：現在前后端分離比較流行，RESTful API 大家應該都比較熟悉。REST 是一種使用 HTTP 協議的進程間通信機制，一般使用 Json 來傳遞數據;
• gRPC ：是一個高性能、開源和通用的 RPC 框架，基于 ProtoBuf ( Protocol Buffers ) 序列化協議開發，支持眾多開發語言。面向服務端和移動端，基于 HTTP/2 設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特性;
• 異步消息：使用消息中間件來實現，比如 RabbitMQ、Kafka 等。

按照交互方式來分，會有同步、異步。

• 同步：客戶端向服務端發起請求、等待服務端響應，等待的過程會造成阻塞;
• 異步：客戶端向服務端發起請求，服務端立即響應，不會造成阻塞，比如說消息隊列的發布、訂閱方式。

這里有幾個概念需要統一下語言：接口、客戶端、服務端

• 接口：如果使用的是消息機制，那么接口就是由消息通道、類型和消息格式組成的;如果是基于 HTTP ，則是由 URL、HTTP 動詞和請求響應的格式來組成;當然，也可以是提供一組方法的類;
• 客戶端、服務端：說起客戶端，第一印象容易想到瀏覽器、移動 APP ，這里的客戶端是指在調用和被調用的調用方，服務端就是被調用方。而接口的定義是由服務端來進行定義。

在前后端分離之前的單體應用中，當接口方法有變化時，進行代碼編譯就知道哪些地方需要調整，或者在 IDE 中進行接口方法引用的查找，也能很容易處理。

在微服務中，不同的服務可能是不同的團隊來進行開發，服務端接口的修改、滾動發布等都需要有很好的兼容性和可用性。

一種方式是在接口中向下兼容，但時間越長代碼就會變得越復雜，比如：

• 添加一些控制性的參數。
• 接口方法新添加的參數需要給默認值。
• 返回值可能也需要進行特殊處理。

另一種方式就是不向下兼容，所有的客戶端需要進行代碼的調整來適應新的接口。在客戶端代碼還沒有完全調整完之前，新老接口需要共存，共存有兩種方式：

• 使用 URL 地址中添加版本號，比如：/api/v1/xxx , /api/v2/xxx 。
• 在請求頭或消息體中添加版本號，接口方法中根據版本號來進行適配，調用對應版本的邏輯然后返回給客戶端。

所以，一個設計良好的接口可以在暴露有用功能的同時隱藏實現細節，對于細節，可以進行擴展，修改，并不會影響到客戶端的調用，這就要求在接口設計之前，需要先進行定義，經過多輪評審后再進行編碼實現。

好的設計自帶防腐層。

因為客戶端和服務端是互相獨立的，服務端有時在特定時間內無法完全響應客戶端的請求，可能是自己本身的故障，也可能是超過了負載。這時，客戶端請求就會被阻塞，無限地等待。

有幾種方式可以來解決這個問題：

• 設置超時：在等待請求響應時，不要無限阻塞，設置一個超時時間，超過時間就返回。
• 根據負載能力，限制客戶端請求的數量，超過上限，后面的請求直接返回失敗。
• 對客戶端請求進行監控，如果失敗的比例超過閾值，就進行熔斷，讓調用立即失敗。

現在有一些成熟的框架可以方便進行熔斷的處理，比如：.NET 中的 Polly、Spring Cloud 中的 Sentinel、Hystrix 。

在傳統軟件中，經常使用環境變量和配置文件來進行靜態地址的配置，而部署在云端的分布式微服務程序中，地址是動態的，那客戶端怎么能找到這些地址呢?這就需要用到服務發現。

服務發現就是客戶端不再依賴一個靜態的固定地址去尋找服務端，而是根據一個路由名稱在服務注冊表去尋找服務端地址，服務端部署后會將地址寫入服務注冊表。

在微服務框架中，也有相關的框架來實現服務發現，比如：.NET 中的 consul 、Spring Cloud 中的 Eureka、Nacos 等。

對于實時性要求不高的場景，可以采用異步消息的方式來實現。比如刪除數據時，需要刪除數據中對應的附件信息、各種操作的日志記錄、流程流轉中需要發送消息通知等。

使用異步消息有下面幾個好處：

• 不需要知道是接收方的地址，只需要將消息發出去就行，發送方和接收方充分解耦。
• 消息的消費者可以是一個，也可以是多個，當處理速度不夠時，可以橫向擴展多個消費者來進行處理。
• 消息中間件在發送方和接收方中間起到一個緩沖的作用。

現在流行的開源中間件有 RabbitMQ、ActiveMQ、RokcetMQ、Kafka 等，選擇這些中間件時需要考慮：

• 支持的編程語言。
• 支持的消息標準;。
• 是否支持持久化?
• 延遲是否在接受范圍之內?
• 消息在處理時能否保持順序?

很多工作流引擎使用的是消息驅動機制，流程在流轉過程中需要保證消息是順序處理的，否則流程數據可能出現錯亂，如何在保證消息順序處理的情況下又能橫向進行擴展，這是一個挑戰。在 Kafka 中可以使用分片的方式進行解決。

上面介紹的是服務間通信的一些常用方式，了解了基本邏輯，在具體實踐時，無論是使用 .NET 技術棧還是 Java 技術棧來做微服務，就都不是什么難事了。