共用方式為


雲端原生通訊模式

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書,您可以在 .NET Docs 找到此電子書,或免費下載可離線閱讀的 PDF。

Cloud Native .NET apps for Azure eBook cover thumbnail.

在建構雲端原生系統時,通訊會成為重要的設計決策。 前端的用戶端應用程式如何與後端的微服務通訊? 後端的微服務彼此如何通訊? 在雲端原生應用程式中實作通訊時,要考慮哪些原則、模式和最佳做法?

通訊考量

在整合型應用程式中,通訊很簡單。 多個程式碼模組會一起在伺服器上的同一個可執行檔空間 (處理序) 中執行。 此方法具有效能優勢,因為所有模組會在共用記憶體中一起執行,但這也會導致程式碼緊密結合,而變得難以維護、演進和調整。

雲端原生系統會實作以微服務為基礎的架構,架構中會有許多小型、獨立的微服務。 每個微服務會在不同的處理序中執行,而且一般會在部署至「叢集」的容器內執行。

叢集會將虛擬機器集區群組在一起,以形成高度可用的環境。 負責部署和管理容器化微服務的協調流程工具可管理這些機器。 圖 4-1 顯示部署至 Azure 雲端且具有完全受控 Azure Kubernetes ServicesKubernetes 叢集。

A Kubernetes cluster in Azure

圖 4-1. Azure 中的 Kubernetes 叢集

在叢集中,微服務會透過 API 和傳訊技術彼此通訊。

雖然微服務提供許多優點,但這是有代價的。 元件之間的本機內含式方法呼叫現在已取代為網路呼叫。 每個微服務必須透過網路通訊協定來通訊,這會讓系統變得更複雜:

  • 網路壅塞、延遲和暫時性錯誤一直令人擔憂。

  • 復原能力 (也就是,重試失敗的要求) 有其必要。

  • 某些呼叫必須等冪,才能保持一致的狀態。

  • 每個微服務都必須驗證和授權呼叫。

  • 每個訊息都必須先序列化再還原序列化,這需要很多成本。

  • 訊息加密/解密變得很重要。

可從 Microsoft 免費取得的 .NET 微服務:容器化 .NET 應用程式的架構一書會深入探討微服務應用程式的通訊模式。 在這一章內,我們會概述這些模式以及 Azure 雲端中可用的實作選項。

在這一章,我們會先解決前端的應用程式與後端的微服務之間的通訊。 然後,我們會探討後端的微服務彼此如何通訊。 我們會探索 up 和 gRPC 通訊技術。 最後,我們會探討使用服務網格技術的創新通訊模式。 我們也會了解 Azure 雲端如何提供不同類型的「支援服務」來支援雲端原生通訊。