在本章中，我們已探索微服務通訊的挑戰。 我們說，開發小組需要對後端服務彼此通訊的方式敏感。 在理想情況下，服務間通訊越少越好。 不過，避免並非總是可能，因為後端服務通常會依賴彼此來完成作業。
我們探索了實作同步 HTTP 通訊和異步傳訊的不同方法。 在每種情況中，開發人員都需要撰寫通訊程式碼。 通訊程式代碼很複雜且需要大量時間。 不正確的決策可能會導致顯著的效能問題。
微服務通訊採用了一種更現代化的方法，圍繞著一項名為 Service Mesh 的新興且快速演進的技術，來促進微服務之間的交流。 服務網格是一種可設定的基礎結構層，內建功能可處理服務對服務通訊、復原，以及許多跨領域考慮。 它會將這些問題的責任移出微服務，並移至服務網格層級。 通訊已從您的微服務中被抽象化。
服務網格的主要元件是 Proxy。 在雲端原生應用程式中，Proxy 的實例通常會與每個微服務共置。 在個別進程中執行時，兩者會緊密連結並共用相同的生命週期。 此模式稱為 側車模式，如圖 4-24 所示。
圖 4-24。 側車的服務網格
請注意，在上圖中，訊息如何被與每個微服務一起執行的 Proxy 攔截。 每個 Proxy 都可以使用微服務專屬的流量規則來設定。 它瞭解訊息，並可跨服務與外界路由傳送訊息。
除了管理服務對服務通訊之外，Service Mesh 也支援服務探索和負載平衡。
設定好之後，服務網狀結構就具有高度功能。 網格會從服務探索端點擷取對應的實例集區。 它會將要求傳送至特定服務實例，記錄結果的延遲和回應類型。 它會根據不同因素選擇最有可能快速響應的實例，其中包括最近要求所觀察到的延遲。
服務網格會管理應用層級的流量、通訊和網路問題。 它會瞭解訊息和要求。 服務網格通常會與容器協調器整合。 Kubernetes 支援可延伸的架構，可在其中新增服務網格。
在第 6 章中，我們深入探討 Service Mesh 技術，包括其架構和可用開放原始碼實作的討論。
總結
在本章中，我們已討論雲端原生通訊模式。 我們一開始會檢查前端用戶端與後端微服務的通訊方式。 一路上，我們談到了 API 閘道平臺和實時通訊。 然後，我們查看了微服務與其他後端服務通訊的方式。 我們已探討跨服務的同步 HTTP 通訊和異步傳訊。 我們介紹了 gRPC，這是在雲端原生世界中的一項新興技術。 最後，我們引進了一項名為 Service Mesh 的全新且快速進化的技術，可簡化微服務通訊。
特彆強調的是受控 Azure 服務，可協助在雲端原生系統中實作通訊：
接下來，我們會移至雲端原生系統中的分散式數據，以及其呈現的優點和挑戰。
