gRPC

提示

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

下載 PDF

本書目前著重於 REST 型通訊。 REST 一直是彈性的架構樣式，可針對實體資源定義 CRUD 型作業。 用戶端可利用要求/回應通訊模型，與 HTTP 上的資源互動。 在 REST 獲得廣泛採用的同時，gRPC 這項新的通訊技術也已在雲端原生社群中獲得極大的發展動力。

什麼是 gRPC？

gRPC 是現代化、高效能的架構，可使歷史悠久的遠端程序呼叫 (RPC) 通訊協定進化。 在應用層級，gRPC 可簡化用戶端與後端服務之間的傳訊。 gRPC 是源自 Google 的開放原始碼，屬於雲端原生供應項目的 Cloud Native Computing Foundation (CNCF) 生態系統。 CNCF 將 gRPC 視為孵化中的專案。 孵化中的意思是終端使用者在實際執行應用程式中使用該技術，而且專案有適當的參與者數目。

典型的 gRPC 用戶端應用程式會公開用於執行業務營運的本機同處理序函式。 實際上，該本機函式會在遠端電腦上叫用另一個函式。 看似在本機進行的呼叫，本質上會成為遠端服務的透明處理序外呼叫。 RPC 管道會將電腦之間的點對點網路通訊、序列化和執行抽象化。

在雲端原生應用程式中，開發人員通常會使用不同的程式設計語言、架構和技術。 這種「互通性」使跨平台通訊所需的訊息合約和管道變得複雜。 gRPC 提供「統一的水平層」，將這些考量抽象化。 開發人員在其原生平台中撰寫程式碼，並專注於商務功能，gRPC 則處理通訊管道。

gRPC 為最熱門的開發堆疊提供完整支援，包括 JAVA、JavaScript、C#、Go、Swift 和 NodeJS。

gRPC 優點

gRPC 使用 HTTP/2 作為傳輸通訊協定。 除了與 HTTP 1.1 相容，HTTP/2 還提供許多進階功能：

• 用於資料傳輸的二進位框架通訊協定，不同於以文字為基礎的 HTTP 1.1。
• 透過相同連線傳送多個平行要求的多工處理支援；HTTP 1.1 限制一次處理一個要求/回應訊息。
• 雙向全雙工通訊，可同時傳送用戶端要求和伺服器回應。
• 內建串流可讓要求和回應以非同步方式串流大型資料集。
• 減少網路使用量的標頭壓縮。

gRPC 輕量且高效能。 相較於 JSON 序列化，其速度最多快 8 倍，訊息則小了 60-80%。 在 Microsoft Windows Communication Foundation (WCF) 架構中，gRPC 的速度和效率超越已大幅優化的 NetTCP 繫節。 gRPC 跨平台適用，與偏好 Microsoft 堆疊的 NetTCP 不同。

通訊協定緩衝區

gRPC 採用一種稱為通訊協定緩衝區的開放原始碼技術。 這些緩衝區提供高效率且不限平台的序列化格式，可將服務傳送給彼此的結構化訊息序列化。 開發人員會使用跨平台介面定義語言 (IDL)，為每個微服務定義服務合約。 合約以文字型 .proto 檔案實作，描述每個服務的方法、輸入和輸出。 相同的合約檔案可用於以不同開發平台建置的 gRPC 用戶端和服務。

Protobuf 編譯 protoc 程式會使用 proto 檔案，產生目標平台的用戶端和服務程式碼。 程式碼包括下列元件：

• 強型別物件，由用戶端和服務共用，代表訊息的服務作業和資料元素。
• 強型別基底類別，具有遠端 gRPC 服務可以繼承和擴充的必要網路管道。
• 用戶端虛設常式，包含叫用遠端 gRPC 服務所需的管道。

在執行階段，每個訊息都會序列化為標準 Protobuf 標記法，並在用戶端與遠端服務之間交換。 不同於 JSON 或 XML，Protobuf 訊息會序列化為已編譯的二進位位元組。

.NET 中的 gRPC 支援

gRPC 已整合到 .NET Core 3.0 SDK 和更新版本中。 下列工具提供支援：

• 已安裝 ASP.NET 與 Web 開發工作負載的 Visual Studio 2022
• Visual Studio Code
• dotnet CLI

SDK 包含端點路由、內建 IoC 和記錄的工具。 開放原始碼 Kestrel 網頁伺服器支援 HTTP/2 連線。 圖 4-20 顯示 Visual Studio 2022 範本，該範本為 gRPC 服務 Scaffold 基本架構專案。 請注意 .NET 如何完整支援 Windows、Linux 和 macOS。

圖 4-20： Visual Studio 2022 中的 gRPC 支援

圖 4-21 顯示從 Visual Studio 2022 包含的內建 Scaffolding 產生的基本架構 gRPC 服務。

圖 4-21： Visual Studio 2022 中的 gRPC 專案

在上圖中，請注意 proto 描述檔案和服務程式碼。 您很快就會看到，Visual Studio 會在 Startup 類別和基礎專案檔中產生額外組態。

gRPC 使用方式

在下列情況下，建議使用 gRPC：

• 需要立即回應才能繼續處理的同步後端微服務對微服務通訊。
• 需要支援混合程式設計平台的 Polyglot 環境。
• 極為重視效能的低延遲和高輸送量通訊。
• 點對點即時通訊：gRPC 可以即時推送訊息，而不需要輪詢，而且有優異的雙向串流支援。
• 網路受限環境：二進位 gRPC 訊息總是小於同等的文字型 JSON 訊息。

截至本文撰寫時間，gRPC 主要用於後端服務。 新式瀏覽器無法提供支援前端 gRPC 用戶端所需的 HTTP/2 控制層級。 也就是支援適用於 .NET 的 gRPC-Web，以從利用 JavaScript 或 Blazor WebAssembly 技術建置的瀏覽器型應用程式進行 gRPC 通訊。 gRPC-Web 可讓 ASP.NET Core gRPC 應用程式在瀏覽器應用程式中支援 gRPC 功能：

• 強型別、程式碼產生的用戶端
• 精簡的 Protobuf 訊息
• 伺服器串流

gRPC 實作

Microsoft 的微服務參考架構 eShop on Containers 示範如何在 .NET 應用程式中實作 gRPC 服務。 圖 4-22 顯示後端架構。

圖 4-22。 eShop on Containers 的後端架構

在上圖中，請注意 eShop 如何藉由公開多個 API 閘道，採用前端的後端模式 (BFF)。 我們在本章稍早討論過 BFF 模式。 請密切注意位於 Web-Shopping API 閘道與後端 Shopping 微服務之間的灰色 Aggregator 微服務。 Aggregator 會從用戶端接收單一要求、將其分派給各種微服務、彙總結果，然後傳回提出要求的用戶端。 這類作業通常需要同步通訊，才能產生立即回應。 在 eShop 中，來自 Aggregator 的後端呼叫是使用 gRPC 執行，如圖 4-23 所示。

圖 4-23： eShop on Containers 中的 gRPC

gRPC 通訊需要用戶端和伺服器元件。 在上圖中，請注意 Shopping Aggregator 如何實作 gRPC 用戶端。 用戶端會對後端微服務進行同步 gRPC 呼叫 (紅色)，而每個呼叫都會實作 gRPC 伺服器。 用戶端和伺服器都利用來自 .NET SDK 的內建 gRPC 管道。 用戶端「虛設常式」提供用來叫用遠端 gRPC 呼叫的管道。 伺服器端元件提供 gRPC 管道，讓自訂服務類別可以繼承及取用。

公開 RESTful API 和 gRPC 通訊的微服務需要多個端點來管理流量。 您會開啟一個端點接聽 RESTful 呼叫的 HTTP 流量，另一個端點接聽 gRPC 呼叫。 gRPC 端點必須針對 gRPC 通訊所需的 HTTP/2 通訊協定進行設定。

雖然我們努力將微服務與非同步通訊模式分離，但某些作業還是需要直接呼叫。 gRPC 應是微服務之間直接同步通訊的首選。 其高效能通訊協定以 HTTP/2 和通訊協定緩衝區為基礎，使其成為完美的選擇。

展望

展望未來，gRPC 在雲端原生系統會愈來愈受歡迎。 效能優勢和開發的簡易度都很吸引人。 不過，REST 可能還會存在很長一段時間。 其長處在於公開的 API 及回溯相容性。

上一個下一個