服務網格通訊基礎結構
在本章中，我們探索了微服務通訊的挑戰。 我們曾說明開發小組必須對後端服務彼此通訊的方式保持敏感。 在理想情況下，服務間的通訊愈少愈好。 不過，因為後端服務通常會互相依賴以完成作業，所以彼此通訊是不可避免的。
我們探索了實作同步 HTTP 通訊和非同步傳訊的不同方法。 在每個案例中，開發人員都會負擔實作通訊程式碼的責任。 但通訊程式碼十分複雜，且非常耗時。 不正確的決策可能會導致顯著的效能問題。
微服務通訊中心採用更現代化的方法，其圍繞名為 Service Mesh 之全新且快速演進的技術。 Service Mesh 是一種可設定的基礎結構層，其內建功能可處理服務對服務通訊、復原和許多跨領域考量。 其會將這些考量的責任移出微服務，並移至服務網格層。 因此，通訊功能便抽離於微服務。
Service Mesh 的主要元件是 Proxy。 在雲端原生應用程式中，Proxy 的執行個體通常會與每個微服務共置。 雖然它們會在不同的處理序中執行，但兩者會緊密連結，並共用相同的生命週期。 此模式稱為 Sidecar 模式，如圖 4-24 所示。
圖 4-24： Service Mesh 與 sidecar
請注意上圖中與每項微服務一起執行的 Proxy 如何攔截訊息。 您可以使用微服務特定的流量規則來設定每個 Proxy。 其了解訊息，並可跨服務和外部世界路由訊息。
除了管理服務對服務通訊之外，Service Mesh 也提供服務探索和負載平衡的支援。
設定之後，Service Mesh 功能非常正常。 網格可以從服務探索端點擷取對應的執行個體集區。 其會將要求傳送至特定服務執行個體，記錄結果的延遲和回應類型。 其可選擇最可能根據不同因素傳回快速回應的執行個體，包括觀察到的最近要求延遲。
Service Mesh 會管理應用程式層級的流量、通訊和網路考量。 其可了解訊息和要求。 Service Mesh 通常會與容器協調器整合。 Kubernetes 支援可擴充的架構，其中可新增服務網格。
在第 6 章中，我們會深入探討 Service Mesh 技術，包括其架構和可用開放原始碼實作的討論。
摘要
在本章中，我們討論了雲端原生通訊模式。 我們一開始探究了前端用戶端如何與後端微服務通訊。 在過程中，我們討論了 API 閘道平台和即時通訊。 接著，我們探討了微服務如何與其他後端服務通訊。 我們探討了跨服務的同步 HTTP 通訊和非同步傳訊。 我們涵蓋了 gRPC，這是雲端原生世界中即將推出的技術。 最後，我們簡介了名為 Service Mesh 的全新且快速演進的技術，其可簡化微服務通訊。
並特別強調受控 Azure 服務，可協助在雲端原生系統中實作通訊：
接下來，我們會移至雲端原生系統中的分散式資料，以及其呈現的優點和挑戰。
