雲端原生通訊模式
在建構雲端原生系統時，通訊會成為重要的設計決策。 前端的用戶端應用程式如何與後端的微服務通訊？ 後端的微服務彼此如何通訊？ 在雲端原生應用程式中實作通訊時，要考慮哪些原則、模式和最佳做法？
通訊考量
在整合型應用程式中，通訊很簡單。 多個程式碼模組會一起在伺服器上的同一個可執行檔空間 (處理序) 中執行。 此方法具有效能優勢，因為所有模組會在共用記憶體中一起執行，但這也會導致程式碼緊密結合，而變得難以維護、演進和調整。
雲端原生系統會實作以微服務為基礎的架構，架構中會有許多小型、獨立的微服務。 每個微服務會在不同的處理序中執行，而且一般會在部署至「叢集」的容器內執行。
叢集會將虛擬機器集區群組在一起，以形成高度可用的環境。 負責部署和管理容器化微服務的協調流程工具可管理這些機器。 圖 4-1 顯示部署至 Azure 雲端且具有完全受控 Azure Kubernetes Services 的 Kubernetes 叢集。
圖 4-1. Azure 中的 Kubernetes 叢集
雖然微服務提供許多優點，但這是有代價的。 元件之間的本機內含式方法呼叫現在已取代為網路呼叫。 每個微服務必須透過網路通訊協定來通訊，這會讓系統變得更複雜：
- 網路壅塞、延遲和暫時性錯誤一直令人擔憂。
- 復原能力 (也就是，重試失敗的要求) 有其必要。
- 某些呼叫必須等冪，才能保持一致的狀態。
- 每個微服務都必須驗證和授權呼叫。
- 每個訊息都必須先序列化再還原序列化，這需要很多成本。
- 訊息加密/解密變得很重要。
可從 Microsoft 免費取得的 .NET 微服務：容器化 .NET 應用程式的架構一書會深入探討微服務應用程式的通訊模式。 在這一章內，我們會概述這些模式以及 Azure 雲端中可用的實作選項。
在這一章，我們會先解決前端的應用程式與後端的微服務之間的通訊。 然後，我們會探討後端的微服務彼此如何通訊。 我們會探索 up 和 gRPC 通訊技術。 最後，我們會探討使用服務網格技術的創新通訊模式。 我們也會了解 Azure 雲端如何提供不同類型的「支援服務」來支援雲端原生通訊。
