在微服務(wù)架構(gòu)中，通信是關(guān)鍵要素，關(guān)于選擇最有效的服務(wù)間交互方法的討論也非常廣泛。在這篇介紹性文章中，我們將探討并總結(jié)微服務(wù)的最佳通信策略，提供關(guān)于何時以及如何有效使用每種通信風(fēng)格的見解。

交互風(fēng)格

要有效理解服務(wù)在微服務(wù)架構(gòu)中如何通信，首先必須熟悉可用的交互風(fēng)格。每種風(fēng)格都有其獨特的優(yōu)點和缺點。深入了解這些細(xì)微差別對于在選擇適當(dāng)?shù)耐ㄐ艡C制之前做出明智決策至關(guān)重要。這一基礎(chǔ)知識確保所選方法能夠很好地與系統(tǒng)的具體要求和挑戰(zhàn)相契合。

交互風(fēng)格可以分為兩個維度，第一個維度是交互是 一對一 還是 一對多：

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

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

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

下表展示了不同的維度：

通信維度

讓我們簡要討論每一種。

一對一交互：

• 請求/響應(yīng) — 服務(wù)客戶端向服務(wù)發(fā)送請求并等待響應(yīng)。客戶端期望響應(yīng)及時到達(dá)，甚至可能會阻塞等待。這種交互風(fēng)格通常導(dǎo)致服務(wù)之間緊密耦合。
• 異步請求/響應(yīng) — 服務(wù)客戶端向服務(wù)發(fā)送請求，服務(wù)異步回復(fù)。客戶端不會阻塞等待，因為服務(wù)可能很長時間不發(fā)送響應(yīng)。
• 單向通知 — 服務(wù)客戶端向服務(wù)發(fā)送請求，但不期望或發(fā)送回復(fù)。

一對多交互

• 發(fā)布/訂閱 — 客戶端發(fā)布通知消息，感興趣的服務(wù)消費消息。
• 發(fā)布/異步響應(yīng) — 客戶端發(fā)布請求消息，然后等待一段時間，接收感興趣的服務(wù)的響應(yīng)。

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

使用同步遠(yuǎn)程過程調(diào)用模式通信

客戶端向服務(wù)發(fā)送請求，服務(wù)處理請求并發(fā)送響應(yīng)。某些客戶端可能會阻塞等待響應(yīng)，而其他客戶端可能具有反應(yīng)式、非阻塞架構(gòu)。但與使用消息傳遞不同，客戶端假設(shè)響應(yīng)會及時到達(dá)。

下圖展示了RPI的工作原理。客戶端的業(yè)務(wù)邏輯調(diào)用由 RPI代理適配器類 實現(xiàn)的 代理接口。RPI代理 向服務(wù)發(fā)出請求。

請求由 RPI服務(wù)器適配器類 處理，該類通過接口調(diào)用服務(wù)的業(yè)務(wù)邏輯。然后，它將回復(fù)發(fā)送回 RPI代理，后者將結(jié)果返回給客戶端的業(yè)務(wù)邏輯。

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

1.REST API

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

REST API的挑戰(zhàn)：

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

使用REST有很多優(yōu)點：

• 簡單且熟悉。
• 可以在瀏覽器中使用插件（例如Postman）或在命令行中使用curl測試HTTP API（假設(shè)使用JSON或其他文本格式）。
• 直接支持請求/響應(yīng)風(fēng)格的通信。
• HTTP當(dāng)然是防火墻友好的。?不需要中間代理，簡化了系統(tǒng)架構(gòu)。

使用REST也有一些缺點：

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

2.使用gRPC

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

gRPC有幾個優(yōu)點：

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

gRPC也有一些缺點：

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

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

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

使用消息傳遞時，服務(wù)通過異步交換消息進(jìn)行通信。基于消息傳遞的應(yīng)用通常使用消息代理，其作為服務(wù)之間的中介。服務(wù)客戶端通過發(fā)送消息向服務(wù)請求。如果服務(wù)實例預(yù)期要回復(fù)，它會通過發(fā)送單獨的消息回復(fù)客戶端。由于通信是異步的，客戶端不會阻塞等待回復(fù)。相反，客戶端假設(shè)回復(fù)不會立即收到。

1.消息傳遞概述

根據(jù)Gregor Hohpe和Bobby Woolf的《企業(yè)集成模式》一書：

消息通過消息通道交換。發(fā)送者（應(yīng)用程序或服務(wù)）將消息寫入通道，接收者（應(yīng)用程序或服務(wù)）從通道讀取消息。讓我們先看一下消息，然后再看通道。

2.關(guān)于消息

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

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

消息體 是以文本或二進(jìn)制格式發(fā)送的數(shù)據(jù)。

消息有幾種不同類型：

• 文檔 — 包含僅數(shù)據(jù)的通用消息。接收者決定如何解釋它。命令的回復(fù)是文檔消息的一個例子。
• 命令 — 包含指示接收者執(zhí)行某些操作的數(shù)據(jù)。客戶端發(fā)出的消息是命令的一個例子。
• 事件 — 包含描述發(fā)生的事件的數(shù)據(jù)。發(fā)布/訂閱消息通常是事件的一個例子。

3.關(guān)于消息通道

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

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

• 點對點通道 將消息從一個發(fā)送者傳遞到一個接收者。消息代理確保每條消息恰好被一個接收者消費。這種類型的通道適用于發(fā)送命令和發(fā)布單一消費者事件。消息代理通常通過將消息放入隊列實現(xiàn)這一點。
• 發(fā)布-訂閱通道 將消息從一個發(fā)送者傳遞到多個接收者。消息代理確保每條消息被所有接收者消費。這種類型的通道適用于發(fā)布事件。消息代理通常通過將消息放入主題實現(xiàn)這一點。

4.消息傳遞的優(yōu)缺點

使用消息傳遞有幾個優(yōu)點：

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

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

• 復(fù)雜性增加。使用消息傳遞時，您必須編寫代碼來處理消息發(fā)送和接收。
• 調(diào)試復(fù)雜。消息傳遞引入了一種新形式的通信，您必須跟蹤消息的狀態(tài)和流動來調(diào)試系統(tǒng)。
• 遇到傳遞消息的基礎(chǔ)設(shè)施開銷。消息傳遞基礎(chǔ)設(shè)施可能會引入開銷，導(dǎo)致某些消息傳遞方案的性能下降。
• 使用消息傳遞時，調(diào)試和測試系統(tǒng)變得更復(fù)雜。

最后

微服務(wù)通信方法的選擇取決于系統(tǒng)的具體需求和設(shè)計考量。同步方法（如REST和gRPC）適用于需要及時響應(yīng)的場景，而異步消息傳遞則在解耦服務(wù)、提高系統(tǒng)可靠性和擴展性方面表現(xiàn)出色。理解這些方法的優(yōu)缺點以及適用場景，是設(shè)計高效、可擴展和可靠的微服務(wù)架構(gòu)的關(guān)鍵。希望本文能為您的微服務(wù)通信方法選擇提供有價值的指導(dǎo)和參考。