使用無 Proxy gRPC 服務的 Cloud Service Mesh 總覽
本指南提供 Cloud Service Mesh 搭配無 Proxy gRPC 服務的架構總覽，包括用途和架構模式。
Cloud Service Mesh 的代管控制層可為服務網格和負載平衡用途啟用全域路由、負載平衡和區域容錯移轉。包括整合補充 Proxy 和閘道 Proxy 的部署作業。Cloud Service Mesh 支援無 Proxy gRPC 應用程式，提供額外的部署模型，讓 gRPC 應用程式參與服務網格，無須使用 Sidecar 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 應用程式不需要 Sidecar Proxy。Cloud Service Mesh 則使用開放原始碼 xDS API，直接設定 gRPC 應用程式。這些 gRPC 應用程式會做為 xDS 用戶端，連線至 Cloud Service Mesh 的全域控制層。連線後，gRPC 應用程式會從控制層接收動態設定，進而啟用端點探索、負載平衡、區域容錯移轉和健康狀態檢查。這種做法可啟用其他 Cloud Service Mesh 部署模式。
在第一張插圖中，服務網格是透過 Sidecar Proxy 啟用。
如要設定 Sidecar Proxy，Cloud Service Mesh 會使用 xDS API。用戶端會透過 Sidecar Proxy 與伺服器通訊。
在第二張插圖中，服務網格已啟用，但未使用無 Proxy gRPC 用戶端，因此沒有 Sidecar Proxy。
如果您只部署 Cloud Service Mesh 設定的 gRPC 服務，可以建立服務網格，完全不必部署任何 Proxy。這項功能可讓您更輕鬆地為 gRPC 應用程式提供服務網格功能。
名稱解析
名稱解析適用於無 Proxy 部署作業，方式如下：
- 連線至服務時，您會在 gRPC 用戶端通道中將
xds設為名稱解析機制。目標 URI 的格式為xds:///hostname:port。 如未指定通訊埠，預設值為 80，例如目標 URIxds:///example.hostname。 - gRPC 用戶端會將接聽項探索服務 (LDS) 要求傳送至 Cloud Service Mesh，藉此解析目標 URI 中的
hostname:port。 - Cloud Service Mesh 會查詢設定的轉送規則，找出相符的連接埠。接著，系統會查詢與
hostname:port相符的主機規則所對應的網址對應。並將相關聯的轉送設定傳回 gRPC 用戶端。
您在 Cloud Service Mesh 中設定的主機規則，在所有網址對應中都不得重複。舉例來說，example.hostname、example.hostname:80 和 example.hostname:8080 都是不同的規則。
使用不同部署類型的名稱解析
無 Proxy 部署項目和使用 Envoy Proxy 的部署項目，名稱解析配置不同。
gRPC 用戶端會使用 xds 名稱解析配置連線至服務，讓用戶端從 Cloud Service Mesh 接收服務設定。接著，gRPC 用戶端會直接與 gRPC 伺服器通訊。
您可以結合 Sidecar Proxy 和無 Proxy 部署模式，提高彈性。如果貴機構和網路支援多個團隊，且這些團隊有不同的功能需求、作業需求和 gRPC 版本，結合模式就特別實用。
在下圖中，無 Proxy gRPC 用戶端和具有 Sidecar Proxy 的 gRPC 用戶端都會與 gRPC 伺服器通訊。使用 Sidecar Proxy 的 gRPC 用戶端會採用 dns 名稱解析機制。
用途
下列應用情境有助於瞭解何時適合搭配無 Proxy gRPC 應用程式使用 Cloud Service Mesh。部署項目可包含無 Proxy gRPC 應用程式、附有 Sidecar Proxy 的 gRPC 應用程式，或兩者的混合。
大型服務網格的資源效率
如果服務網格包含數百或數千個用戶端和後端，您可能會發現執行 Sidecar Proxy 的資源耗用量開始增加。使用無 Proxy gRPC 應用程式時，您不需要在部署項目中導入 Sidecar Proxy。無 Proxy 方法可提高效率。
高效能 gRPC 應用程式
在某些用途中，要求和回應延遲時間的每一毫秒都很重要。在這種情況下，使用無 Proxy gRPC 應用程式時，延遲時間可能會縮短，因為不必透過用戶端輔助容器 Proxy (以及可能透過伺服器端輔助容器 Proxy) 傳送每個要求。
適用於無法部署 Sidecar Proxy 的環境的服務網格
在某些環境中，您可能無法將 Sidecar Proxy 做為額外程序，與用戶端或伺服器應用程式一起執行。或者，您可能無法設定機器的網路堆疊，以攔截及重新導向要求 (例如使用 iptables)。在這種情況下，您可以搭配無 Proxy gRPC 應用程式使用 Cloud Service Mesh，為 gRPC 應用程式導入服務網格功能。
異質服務網格
由於無 Proxy gRPC 應用程式和 Envoy 都會與 Cloud Service Mesh 通訊，因此服務網格可以同時包含這兩種部署模型。同時納入這兩種模型，可滿足不同應用程式和不同開發團隊的特定作業、效能和功能需求。
從有 Proxy 的服務網格遷移至無 Proxy 的網格
如果您已有透過 Cloud Service Mesh 設定的 gRPC 應用程式和補充 Proxy，可以改用無 Proxy gRPC 應用程式。
使用 Sidecar Proxy 部署 gRPC 用戶端時，用戶端會使用 DNS 解析要連線的主機名稱。補充 Proxy 會攔截流量，提供服務網格功能。
您可以修改 gRPC 用戶端使用的名稱解析架構，定義該用戶端與 gRPC 伺服器通訊時，要使用無 Proxy 路徑還是 Sidecar Proxy 路徑。無 Proxy 用戶端會使用 xds 名稱解析配置，而 Sidecar Proxy 則會使用 dns 名稱解析配置。有些 gRPC 用戶端甚至可能在與某個 gRPC 伺服器通訊時使用無 Proxy 路徑，但與另一個 gRPC 伺服器通訊時則使用 Sidecar Proxy 路徑。這可讓您逐步遷移至無 Proxy 部署。
如要從有 Proxy 的服務網格遷移至沒有 Proxy 的網格，請建立新的 Cloud Service Mesh 服務，供無 Proxy gRPC 用戶端使用。您可以使用相同的 API，為現有和新版本設定 Cloud Service Mesh。
架構與資源
無 Proxy gRPC 服務的設定資料模型會擴充 Cloud Service Mesh 設定模型，並新增一些項目和限制，詳情請參閱本指南。部分限制是暫時性的，因為無代理程式 gRPC 不支援所有 Envoy 功能，其他限制則是使用 RPC 時的固有問題。舉例來說，系統不支援使用 gRPC 的 HTTP 重新導向。為協助您瞭解本指南中的設定模型，建議您先熟悉 Cloud Service Mesh 概念和設定。
下圖顯示您必須為無代理程式 gRPC 應用程式設定的資源。
健康狀態檢查
gRPC 健康狀態檢查可檢查後端虛擬機器 (VM) 執行個體或網路端點群組 (NEG) 上執行的 gRPC 服務狀態。
如果 gRPC 伺服器未實作 gRPC 健康狀態檢查通訊協定，而無法使用 gRPC 健康狀態檢查，請改用 TCP 健康狀態檢查，不要使用 HTTP、HTTPS 或 HTTP/2 健康狀態檢查。
詳情請參閱 gRPC 健康狀態檢查和 gRPC 健康狀態檢查的其他旗標。
後端服務
後端服務定義 gRPC 用戶端與 gRPC 伺服器之間的通訊方式。為 gRPC 建立後端服務時，請將通訊協定欄位設為 GRPC。
如果後端服務設定的通訊協定為
GRPC，gRPC 應用程式也可以透過 Sidecar Proxy 存取該服務。在這種情況下，gRPC 用戶端不得使用xds名稱解析配置。在所有 Cloud Service Mesh 部署作業中，後端服務的負載平衡機制都必須是
INTERNAL_SELF_MANAGED。
後端
後端會代管 gRPC 伺服器執行個體。您可以在 Compute Engine 中使用代管或非代管執行個體群組，以及在 Google Kubernetes Engine 中使用區域 NEG，做為後端來代管 gRPC 伺服器執行個體。
後續步驟
- 如要瞭解服務路徑 API 及其運作方式，請參閱總覽。
- 如要準備設定 Cloud Service Mesh 與無 Proxy gRPC 應用程式，請參閱「準備使用 Envoy 和無 Proxy 工作負載進行設定」。
- 如要瞭解無 Proxy gRPC 部署項目的限制，請參閱「無 Proxy 的 gRPC 限制與規定」。