使用無 Proxy gRPC 服務的 Cloud Service Mesh 總覽

本指南將概略說明 Cloud Service Mesh 的架構,包括使用案例和架構模式,並說明如何使用無 Proxy gRPC 服務。

Cloud Service Mesh 的代管控制層可為服務網格和負載平衡用途提供全球路由、負載平衡和區域容錯移轉功能。這包括整合補充 Proxy 和閘道 Proxy 的部署作業。Cloud Service Mesh 支援無 Proxy gRPC 應用程式,提供額外的部署模型,讓 gRPC 應用程式不必使用附加 Proxy 就能參與服務網格。

在一般情況下,gRPC 用戶端會與代管後端邏輯的 gRPC 伺服器建立連線。Cloud Service Mesh 會向 gRPC 用戶端提供資訊,說明要聯絡哪些伺服器、如何將要求負載平衡至多個伺服器執行個體,以及如果伺服器未執行,該如何處理要求。

如需 Cloud Service Mesh 運作方式的完整總覽,請參閱 Cloud Service Mesh 總覽

Cloud Service Mesh 如何與 gRPC 應用程式搭配運作

Cloud Service Mesh 會使用支援的 gRPC 版本設定 gRPC 用戶端,這與 Envoy 等附加 Proxy 的設定方式類似。不過,直接連線至 Cloud Service Mesh 的無 Proxy gRPC 應用程式不需要附加 Proxy。相反地,Cloud Service Mesh 會使用開放原始碼 xDS API 直接設定 gRPC 應用程式。這些 gRPC 應用程式會充當 xDS 用戶端,連線至 Cloud Service Mesh 的全球控制層。連線後,gRPC 應用程式會從控制層接收動態設定,啟用端點探索、負載平衡、區域容錯移轉和健康狀態檢查。這種做法可支援其他 Cloud Service Mesh 部署模式。

在第一個插圖中,服務網格是透過使用附屬 Proxy 啟用。

使用補充 Proxy 啟用的服務網格。
使用側邊 Proxy 啟用的服務網格 (按一下可放大)

如要設定附加 Proxy,Cloud Service Mesh 會使用 xDS API。用戶端會透過 Sidecar Proxy 與伺服器通訊。

在第二個插圖中,使用無 Proxy gRPC 用戶端,不需側邊 Proxy 就能啟用服務網格。

使用無 Proxy gRPC 啟用的服務網格。
使用無 Proxy gRPC 啟用的服務網格 (按一下即可放大)

如果您只部署 Cloud Service Mesh 所設定的 gRPC 服務,就可以建立服務網格,而無須部署任何 Proxy。這樣一來,您就能更輕鬆地將服務網格功能帶入 gRPC 應用程式。

名稱解析

名稱解析功能可透過下列方式為無 Proxy 部署作業提供服務:

  1. 連線至服務時,您會在 gRPC 用戶端管道中將 xds 設為名稱解析方案。目標 URI 的格式為 xds:///hostname:port。如未指定通訊埠,預設值為 80,例如在目標 URI xds:///example.hostname 中。
  2. gRPC 用戶端會傳送 監聽器探索服務 (LDS) 要求至 Cloud Service Mesh,藉此解析目標 URI 中的 hostname:port
  3. Cloud Service Mesh 會查詢已設定的轉送規則,找出符合的連接埠。接著,系統會查詢對應的網址對應,找出與 hostname:port 相符的主機規則。它會將相關聯的轉送設定傳回給 gRPC 用戶端。

您在 Cloud Service Mesh 中設定的主機規則,必須在所有網址對應中皆不重複。例如 example.hostnameexample.hostname:80example.hostname:8080 都是不同的規則。

使用不同部署類型的名稱解析

無 Proxy 部署和使用 Envoy Proxy 的部署,其名稱解析配置方式不同。

gRPC 用戶端會使用 xds 名稱解析方案連線至服務,讓用戶端能從 Cloud Service Mesh 接收服務設定。接著,gRPC 用戶端會直接與 gRPC 伺服器通訊。

您可以結合副駕駛 Proxy 和無 Proxy 部署模式,提高彈性。如果您的機構和網路支援多個團隊,且各團隊有不同的功能需求、作業需求和 gRPC 版本,結合模式就特別實用。

在下圖中,無 Proxy gRPC 用戶端和附掛 Proxy 的 gRPC 用戶端都會與 gRPC 伺服器通訊。搭配側邊 Proxy 的 gRPC 用戶端會使用 dns 名稱解析配置。

服務網格,由無 Proxy gRPC 用戶端和附屬 Proxy 的 gRPC 用戶端組成。
由無 Proxy gRPC 用戶端和附掛 Proxy 的 gRPC 用戶端組成的服務網格 (按一下可放大)

用途

下列用途有助您瞭解何時應搭配無 Proxy gRPC 應用程式使用 Cloud Service Mesh。部署項目可包含無 Proxy gRPC 應用程式、含輔助 Proxy 的 gRPC 應用程式,或兩者皆有。

大規模服務網格中的資源效率

如果服務網狀結構包含數百或數千個用戶端和後端,您可能會發現,執行附屬 Proxy 時的總資源用量開始累積。使用無 Proxy gRPC 應用程式時,您不需要在部署中導入附加 Proxy。無 Proxy 方法可提高效率。

高效能 gRPC 應用程式

在某些用途中,每毫秒的請求和回應延遲時間都很重要。在這種情況下,如果您使用無 Proxy gRPC 應用程式,而不是將每個要求都傳送至用戶端側邊 Proxy (可能還有伺服器端側邊 Proxy),可能會發現延遲時間縮短。

適用於無法部署 Sidecar 代理程式的環境的服務網格

在某些環境中,您可能無法將附加 Proxy 當作額外程序,與用戶端或伺服器應用程式一併執行。或者,您可能無法設定機器的網路堆疊,以便攔截及重新導向要求,例如使用 iptables。在這種情況下,您可以使用 Cloud Service Mesh 搭配無 Proxy gRPC 應用程式,為 gRPC 應用程式引入服務網格功能。

異質服務網格

由於無 Proxy gRPC 應用程式和 Envoy 都會與 Cloud Service Mesh 通訊,因此服務網格可以包含這兩種部署模式。加入這兩種模型,您就能滿足不同應用程式和開發團隊的特定作業、效能和功能需求。

從含有 Proxy 的服務網格遷移至不含 Proxy 的網格

如果您已擁有含有 Cloud Service Mesh 所設定附加 Proxy 的 gRPC 應用程式,可以改用無 Proxy gRPC 應用程式。

當 gRPC 用戶端搭配附加 Proxy 部署時,會使用 DNS 解析要連線的主機名稱。補充 Proxy 會攔截流量,以提供服務網格功能。

您可以修改 gRPC 用戶端使用的名稱解析方案,定義 gRPC 用戶端是否使用無 Proxy 路徑或附加 Proxy 路徑與 gRPC 伺服器通訊。無 Proxy 的用戶端會使用 xds 名稱解析配置,而側邊 Proxy 會使用 dns 名稱解析配置。有些 gRPC 用戶端甚至可能在與某個 gRPC 伺服器通訊時使用無 Proxy 路徑,但在與其他 gRPC 伺服器通訊時使用附屬 Proxy 路徑。這樣您就能逐步遷移至無 Proxy 的部署作業。

如要從含有 Proxy 的服務網格遷移至不含 Proxy 的服務網格,您必須建立新的 Cloud Service Mesh 服務,供無 Proxy gRPC 用戶端使用。您可以使用相同的 API,為現有和新版本設定 Cloud Service Mesh。

服務網格搭配 gRPC 用戶端,可透過無 Proxy 和 Proxy 的機制與不同服務通訊。
含有 gRPC 用戶端的服務網格,可透過無 Proxy 和 Proxy 機制與不同服務通訊 (按一下可放大)

架構與資源

無 Proxy gRPC 服務的設定資料模型會擴充 Cloud Service Mesh 設定模型,並提供本指南所述的部分新增項目和限制。其中部分限制是暫時性的,因為無代理 gRPC 不支援 Envoy 的所有功能,而其他限制則是使用 RPC 的固有限制。舉例來說,系統不支援使用 gRPC 的 HTTP 重新導向。為協助您瞭解本指南中的設定模型,建議您先熟悉 Cloud Service Mesh 的概念設定

下圖顯示您必須為無 Proxy 的 gRPC 應用程式設定的資源。

無 Proxy gRPC 負載平衡功能支援的資源。
無 Proxy gRPC 負載平衡功能支援的資源 (按一下可放大)

健康狀態檢查

gRPC 健康狀態檢查可檢查在後端虛擬機器 (VM) 執行個體或網路端點群組 (NEG) 上執行的 gRPC 服務狀態。

如果 gRPC 伺服器未實作 gRPC 健康狀態檢查通訊協定,則無法使用 gRPC 健康狀態檢查,請改用 TCP 健康狀態檢查,不要使用 HTTP、HTTPS 或 HTTP/2 健康狀態檢查。

詳情請參閱「gRPC 健康狀態檢查」和「gRPC 健康狀態檢查的其他旗標」。

後端服務

後端服務會定義 gRPC 用戶端與 gRPC 伺服器的通訊方式。建立 gRPC 後端服務時,請將通訊協定欄位設為 GRPC

  • 如果後端服務的通訊協定設為 GRPC,gRPC 應用程式也可以透過補充 Proxy 存取該服務。在這種情況下,gRPC 用戶端不得使用 xds 名稱解析配置。

  • 在所有 Cloud Service Mesh 部署中,後端服務的負載平衡機制必須為 INTERNAL_SELF_MANAGED

後端

後端會代管 gRPC 伺服器執行個體。您可以使用 Compute Engine 中的代管或非代管執行個體群組,以及 Google Kubernetes Engine 中的區域 NEG 做為後端,用於託管 gRPC 伺服器執行個體。

後續步驟