在微服務架構中，通信是關鍵要素，關於選擇最有效的服務間交互方法的討論也非常廣泛。在這篇介紹性文章中，我們將探討並總結微服務的最佳通信策略，提供關於何時以及如何有效使用每種通信風格的見解。

交互風格

要有效理解服務在微服務架構中如何通信，首先必須熟悉可用的交互風格。每種風格都有其獨特的優點和缺點。深入瞭解這些細微差別對於在選擇適當的通信機制之前做出明智決策至關重要。這一基礎知識確保所選方法能夠很好地與系統的具體要求和挑戰相契合。

交互風格可以分爲兩個維度，第一個維度是交互是 一對一 還是 一對多：

• 一對一 — 每個客戶端請求由一個服務處理。• 一對多 — 每個請求由多個服務處理。

第二個維度是交互是 同步 還是 異步。

• 同步 — 客戶端期望服務及時響應，甚至可能會阻塞等待。• 異步 — 客戶端不會阻塞，響應（如果有的話）不一定會立即發送。

下表展示了不同的維度：

通信維度

讓我們簡要討論每一種。

一對一交互

• 請求 / 響應 — 服務客戶端向服務發送請求並等待響應。客戶端期望響應及時到達，甚至可能會阻塞等待。這種交互風格通常導致服務之間緊密耦合。• 異步請求 / 響應 — 服務客戶端向服務發送請求，服務異步回覆。客戶端不會阻塞等待，因爲服務可能很長時間不發送響應。• 單向通知 — 服務客戶端向服務發送請求，但不期望或發送回覆。

一對多交互

• 發佈 / 訂閱 — 客戶端發佈通知消息，感興趣的服務消費消息。• 發佈 / 異步響應 — 客戶端發佈請求消息，然後等待一段時間，接收感興趣的服務的響應。

請記住，一個服務可以有多種通信方式。

使用同步遠程過程調用模式通信

客戶端向服務發送請求，服務處理請求併發送響應。某些客戶端可能會阻塞等待響應，而其他客戶端可能具有反應式、非阻塞架構。但與使用消息傳遞不同，客戶端假設響應會及時到達。

下圖展示了 RPI 的工作原理。客戶端的業務邏輯調用由 RPI 代理適配器類 實現的 代理接口。RPI 代理 向服務發出請求。

請求由 RPI 服務器適配器類 處理，該類通過接口調用服務的業務邏輯。然後，它將回復發送回 RPI 代理，後者將結果返回給客戶端的業務邏輯。

代理接口 通常封裝了底層通信協議。有很多協議可供選擇，我們重點關注最流行的協議 REST 和 gRPC。

REST API

REST 的一個關鍵概念是資源，它通常代表一個業務對象（如客戶或產品）或一組業務對象。REST 使用 HTTP 動詞來操作資源，這些資源通過 URL 引用。例如，GET 請求返回資源的表示，通常是 XML 文檔或 JSON 對象，儘管也可以使用其他格式（如二進制）。POST 請求創建一個新資源，PUT 請求更新一個資源。

REST API 的挑戰

1. 在單個請求中獲取多個資源 **REST 資源通常關注業務對象，如客戶和訂單，這給一次請求獲取多個相關對象帶來了挑戰。**例如，獲取訂單及其關聯的客戶通常需要多次 API 調用。常見的解決方法是增強 API，使客戶端可以在一次調用中獲取相關資源，例如使用帶有 “expand” 查詢參數的 GET 請求來指定相關資源。雖然在很多情況下有效，但這種方法可能複雜且耗時，這促使了像 GraphQL 這樣的替代技術的興起，以實現更簡化的數據檢索。2. 將操作映射到 HTTP 動詞 *REST API 設計中的一個顯著挑戰是如何將業務對象上的特定操作分配給正確的 HTTP 動詞。例如，更新訂單可能涉及各種操作，如取消或修改 *，並非所有更新都符合使用 HTTP PUT 方法的冪等性要求。常見的方法是爲不同的更新操作創建子資源，例如使用 POST 取消（POST /orders/{orderId}/cancel）或修改訂單（POST /orders/{orderId}/revise）。另一種方法是在 URL 查詢參數中包含操作。然而，這些方法可能並不完全遵循 REST 原則。這種將操作映射到 HTTP 動詞的困難促使了 gRPC 等替代技術的流行。

REST 的優缺點

使用 REST 有很多優點：

• 簡單且熟悉。• 可以在瀏覽器中使用插件（例如 Postman）或在命令行中使用 curl 測試 HTTP API（假設使用 JSON 或其他文本格式）。• 直接支持請求 / 響應風格的通信。•HTTP 當然是防火牆友好的。• 不需要中間代理，簡化了系統架構。

使用 REST 也有一些缺點：

• 僅支持請求 / 響應風格的通信。• 可用性降低。由於客戶端和服務直接通信，沒有中介緩衝消息，它們必須在整個交換期間都在運行。• 客戶端必須知道服務實例的位置（URL）。在現代應用中，這是一個不小的問題。客戶端必須使用所謂的服務發現機制來定位服務實例。• 在單個請求中獲取多個資源具有挑戰性。• 將多個更新操作映射到 HTTP 動詞有時很困難。

使用 gRPC

REST API 通常在使用有限的 HTTP 動詞處理多個更新操作時遇到困難。gRPC 通過使用二進制消息協議提供了一個替代方案，強調 API 優先的方法。它利用谷歌開發的 Protocol Buffers（Protobuf），這是一種語言中立的序列化系統，允許開發人員使用基於 Protocol Buffers 的接口定義語言（IDL）定義 API。此設置使得可以使用 Protocol Buffer 編譯器自動生成各種編程語言（如 Java、C#、NodeJS 和 GoLang）的客戶端和服務器代碼。gRPC API 運行在 HTTP/2 之上，支持簡單的請求 / 響應和流式 RPC，服務器可以向客戶端發送消息流或反之亦然。此技術支持創建具有強類型方法的明確服務接口，爲處理微服務架構中的各種複雜通信模式提供了強大的框架。

gRPC 的優缺點

gRPC 有幾個優點：

• 設計具有豐富更新操作的 API 非常簡單。• 具有高效、緊湊的 IPC 機制，特別是在交換大型消息時。• 雙向流支持 RPI 和消息傳遞風格的通信。• 使客戶端和服務在各種編程語言之間的互操作性成爲可能。

gRPC 也有一些缺點：

•JavaScript 客戶端使用 gRPC API 比使用 REST/JSON API 工作量更大。• 較舊的防火牆可能不支持 HTTP/2。

gRPC 是 REST 的一個有力替代方案，但像 REST 一樣，它也是一種同步通信機制，因此也存在部分失敗的問題。

使用異步消息傳遞模式通信

使用消息傳遞時，服務通過異步交換消息進行通信。基於消息傳遞的應用通常使用消息代理，其作爲服務之間的中介。服務客戶端通過發送消息向服務請求。如果服務實例預期要回復，它會通過發送單獨的消息回覆客戶端。由於通信是異步的，客戶端不會阻塞等待回覆。相反，客戶端假設回覆不會立即收到。

消息傳遞概述

根據 Gregor Hohpe 和 Bobby Woolf 的《企業集成模式》一書，

消息通過消息通道交換。發送者（應用程序或服務）將消息寫入通道，接收者（應用程序或服務）從通道讀取消息。讓我們先看一下消息，然後再看通道。

關於消息

消息由消息頭和消息體組成。

消息頭 是一組名稱 - 值對，以及描述所發送數據的元數據。除了由消息發送者提供的名稱 - 值對外，消息頭還包含名稱 - 值對，例如由發送者或消息傳遞基礎設施生成的唯一消息 ID，以及一個可選的返回地址，指定應將回複寫入的消息通道。

消息體 是以文本或二進制格式發送的數據。

消息有幾種不同類型：

• 文檔 — 包含僅數據的通用消息。接收者決定如何解釋它。命令的回覆是文檔消息的一個例子。• 命令 — 包含指示接收者執行某些操作的數據。客戶端發出的消息是命令的一個例子。

• 事件 — 包含描述發生的事件的數據。發佈 / 訂閱消息通常是事件的一個例子。

關於消息通道

消息通過消息通道 發送。消息通道是消息傳遞基礎設施的關鍵組成部分。雖然消息是邏輯上的概念，但消息通道通常是由消息代理實例化的具體、物理概念。消息通道有兩種類型：點對點通道和發佈 - 訂閱通道。

下圖展示了它們是如何工作的：

點對點通道 將消息從一個發送者傳遞到一個接收者。消息代理確保每條消息恰好被一個接收者消費。這種類型的通道適用於發送命令和發佈單一消費者事件。消息代理通常通過將消息放入隊列實現這一點。

發佈 - 訂閱通道 將消息從一個發送者傳遞到多個接收者。消息代理確保每條消息被所有接收者消費。這種類型的通道適用於發佈事件。消息代理通常通過將消息放入主題實現這一點。

消息傳遞的優缺點

使用消息傳遞有幾個優點：

• 它是異步的，不需要客戶端和服務在通信期間都運行。• 它使您能夠實現發佈 / 訂閱和發佈 / 異步響應風格的通信。• 它解耦了客戶端和服務。客戶端通過寫入通道請求服務，服務通過從通道讀取消息提供服務。客戶端和服務不直接通信，因此無需相互瞭解位置。• 客戶端可以將請求寫入負載均衡器或消息代理上的虛擬隊列，實現服務實例的負載均衡。• 消息代理會自動將消息發送到服務實例，因此服務實例崩潰時消息不會丟失。

使用消息傳遞有一些缺點：

• 複雜性增加。使用消息傳遞時，您必須編寫代碼來處理消息發送和接收。• 調試複雜。消息傳遞引入了一種新形式的通信，您必須跟蹤消息的狀態和流動來調試系統。• 遇到傳遞消息的基礎設施開銷。消息傳遞基礎設施可能會引入開銷，導致某些消息傳遞方案的性能下降。• 使用消息傳遞時，調試和測試系統變得更復雜。

最後

微服務通信方法的選擇取決於系統的具體需求和設計考量。同步方法（如 REST 和 gRPC）適用於需要及時響應的場景，而異步消息傳遞則在解耦服務、提高系統可靠性和擴展性方面表現出色。理解這些方法的優缺點以及適用場景，是設計高效、可擴展和可靠的微服務架構的關鍵。希望本文能爲您的微服務通信方法選擇提供有價值的指導和參考。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-X75FChGAQ359JarczOYxQ