進階流量管理總覽

本文適用於網格或平台管理員，以及對 Cloud Service Mesh 和服務網格概念有中高階程度瞭解的服務開發人員。這些人員負責決定及設定 Cloud Service Mesh 部署作業中的流量管理方式。

注意： 本指南僅支援使用 API 的 Cloud Service Mesh，不支援 Istio API。 Google Cloud 詳情請參閱 Cloud Service Mesh 總覽。

Cloud Service Mesh 提供進階流量管理功能，可讓您精細控管流量的處理方式。Cloud Service Mesh 支援下列用途：

• 將要求精細地轉送至一或多項服務。
• 根據權重拆分流量，將流量分配給多項服務。
• 流量鏡射政策，可將要求傳送至一個偵錯服務，並將副本傳送至另一個服務。TCPRoute 或 TLSRoute 資源不支援流量鏡像。
• 微調服務後端的流量分配，提升負載平衡效果。

這些進階流量管理功能可協助您達成可用性和效能目標。在這些用途中使用 Cloud Service Mesh 的優點之一，就是您可以更新流量管理方式，而不必修改應用程式程式碼。

Cloud Service Mesh 服務網格中的流量管理功能會使用下列資源：

• Mesh 資源，可識別服務網狀網路，並代表負責轉送流量和套用政策的元件。Mesh 資源也會識別流量攔截埠。
• Gateway 資源，用於識別中間 Proxy，並代表在 IP 位址：通訊埠配對清單上接聽、轉送流量及套用政策的元件。
• Route 資源，可以是多種型別之一，並包含網格的流量路徑資訊。Route 資源會識別主機名稱和通訊埠，供用戶端將流量導向後端服務。以下是 Route 資源的類型：
  • HTTPRoute，這項功能僅適用於使用 Envoy Proxy 的網格。使用 HTTPRoute 資源設定 Envoy Proxy 傳送 HTTP 要求時，您可以使用本文中的所有功能。
  • TCPRoute，僅適用於使用 Envoy Proxy 的網格。
  • TLSRoute，僅適用於使用 Envoy Proxy 的網格。
  • GRPCRoute，適用於使用 Envoy Sidecar Proxy 和無 Proxy gRPC 的網格。透過 Cloud Service Mesh 使用無 Proxy gRPC 服務或應用程式時，無法使用本文所述的部分功能。
• 與 Route 資源相關聯的後端服務。

設定

如要設定進階流量管理，請使用設定 Cloud Service Mesh 時使用的相同 Route 和後端服務資源。Cloud Service Mesh 會設定 Envoy Proxy 和無 Proxy gRPC 應用程式，強制執行您設定的進階流量管理政策。

整體來說，您需要執行以下操作：

1. 設定 Mesh 資源，以識別服務網格。

2. 根據外送要求的特性，設定 Route 資源以執行下列操作：

   1. 選取要求轉送到的後端服務。

   2. 視需要執行其他動作。

3. 設定後端服務，控管流量在選取目的地服務後，如何分配至後端和端點。

流量轉送和動作

在 Cloud Service Mesh 中，系統會根據 Mesh 資源、Route 資源和後端服務資源中的值，轉送流量。所有與路徑和動作相關的進階流量管理功能，都是使用 Route 物件設定。

下列各節說明可在 Route 物件中設定的進階流量管理功能。

處理要求

用戶端傳送要求時，系統會按照下列步驟處理要求：

1. 要求會與特定 Route 資源相符，如下所示：

   • 如果使用 Envoy：
     • 系統會比對 HTTP 要求中的主機標頭與每個 HTTPRoute 或 GRPCRoute 資源中的 hostnames 欄位，為要求選取正確的 Route 資源。只有 HTTPRoute 和 GRPCRoute 資源有 hostnames 欄位。
     • 系統會比對 IP 位址，並使用 TCPPRoute 路由傳輸控制通訊協定 (TCP) 流量。
     • SNI 和 ALPN 用於透過 TLSRoute 進行 TLS 直通。
     • 與 Mesh 或 Gateway 相關聯的 HTTPRoute 和 GRPCRoute 資源必須有不重複的主機名稱。如果您嘗試附加多個主機名稱衝突的路徑，系統會拒絕設定。
     • 同樣地，TCPRoute 的 IP:Port 欄位不得重複，否則系統會拒絕設定。
     • 同樣地，SNI 和 ALPN 對於 TLSRoute 來說不得重複。
     • 如果主機名稱重疊 (例如 a.example.com 和 *.example.com)，要求會與較明確的路徑相符。
   • 如果您使用無 Proxy gRPC：
     • 無 Proxy gRPC 用戶端會使用 xds 名稱解析機制。這些服務會向 Cloud Service Mesh 傳送要求，藉此解析目標 URI 中的 hostname[:port]。
     • 系統只會比較 GRPCRoute 資源的通訊埠與目標 URI 中的通訊埠 (例如 xds:///example.hostname:8080)。目標 URI 必須與 GRPCRoute 的 hostnames 欄位中的字串完全相符。

2. Route 資源可包含進一步的路由資訊和規則。

3. 選取目的地後端服務後，系統會根據後端服務資源中的設定，在該目的地後端服務的後端或端點之間分配流量。

第二個步驟請參閱下一節「根據主機和路徑進行簡單轉送」。第三個步驟請參閱「進階路徑和動作」。

根據主機和路徑進行簡單轉送

Cloud Service Mesh 支援簡化和進階的轉送機制。在簡單配置中，您可以指定主機，並視需要指定路徑。系統會評估要求的主機和路徑，判斷要求要轉送至哪個後端服務。

• 要求的「主機」是網址的網域名稱部分，例如網址 http://example.com/video/ 的主機部分為 example.com。
• 要求的路徑是網址中主機名稱後面的部分；例如，網址 http://example.com/video/ 的路徑部分是 /video。

您可以在轉送規則對應中，根據主機和路徑設定簡單的轉送規則，包括：

• 全球Mesh
• HTTPRoute 或 GRPCRoute

大部分的設定都是在 HTTPRoute 中完成。建立初始轉送規則對應後，您只需要修改 HTTPRoute 資源。

最簡單的規則是預設規則，您只需指定萬用字元 (*) 主機規則和含有預設服務的路徑比對條件。建立預設規則後，您可以新增其他規則，指定不同的主機和路徑。系統會根據這些規則評估外送要求，方式如下：

• 如果要求的主機 (例如 example.com) 與 HTTPRoute 的主機名稱相符：

  1. 接著評估 RouteRule。RouteRule 檔案會指定如何比對流量，以及比對流量時如何轉送流量。
  2. 每個 RouteRule 都包含一或多個路徑相符項目，這些項目會根據要求路徑進行評估。
  3. 如果找到相符項目，要求會轉送至 RouteAction 中指定的服務。

如要進一步瞭解 HTTPRoute's 資源欄位和運作方式，請參閱網路服務 API 說明文件。

進階路徑和動作

如要執行更多操作，而不只是根據要求的主機和路徑轉送要求，可以設定進階規則來轉送要求及執行動作。

進階路徑和動作的運作方式大致如下：

1. 與簡單的路由設定一樣，系統會將要求的主機與您在 HTTPRoute 或 GRPCRoute 中設定的主機規則進行比較。如果要求的 主機與主機名稱相符，系統會評估 HTTPRoute 或 GRPCRoute。
2. 選取路線後，即可套用動作。

進階轉送

進階轉送與先前說明的簡易轉送類似，但您可以指定其他比對條件。舉例來說，您可以指定規則，在標題名稱完全或部分相符時 (例如根據前置字串或後置字串)，比對要求標題。規則可以根據評估標頭名稱是否符合規則運算式，或根據其他條件 (例如檢查標頭是否存在) 進行比對。

如要瞭解 headerMatches 和 queryParameterMatches 的其他比對條件和詳細資料，請參閱 network services REST API 頁面。

結合主機、路徑、標頭和查詢參數與比對條件，即可建立符合流量管理需求的規則。詳情請參閱下表。

	以 HTTP 為基礎的應用程式	以 gRPC 為基礎的應用程式
HTTP 主機與 gRPC 主機	主機是應用程式呼叫的網址網域名稱部分。 舉例來說，網址 http://example.com/video/ 的主機部分是 example.com。	主機是用戶端在管道 URI 中使用的名稱，可連線至特定服務。 舉例來說，頻道 URI xds:///example.com 的主機部分為 example.com。
HTTP 路徑與 gRPC 路徑	路徑是指網址中主機名稱後面的部分。 舉例來說，網址 http://example.com/video 的路徑部分為 /video。	路徑位於 HTTP/2 要求的 :path 標頭中，看起來像 /SERVICE_NAME/METHOD_NAME。 舉例來說，如果您在 Example gRPC 服務上呼叫 Download 方法，:path 標頭的內容會類似 /Example/Download。
其他 gRPC 標頭 (中繼資料)		gRPC 支援在 gRPC 用戶端和 gRPC 伺服器之間傳送中繼資料，提供 RPC 呼叫的額外資訊。這類中繼資料會以鍵/值組合的形式，在 HTTP/2 要求中以標頭形式傳送。

動作

Cloud Service Mesh 可讓您指定 Envoy Proxy 或無 Proxy gRPC 應用程式在處理要求時採取的動作。您可以使用 Cloud Service Mesh 設定下列動作。

注意： 搭配 Cloud Service Mesh 使用 Envoy 時，可使用下列所有功能。將無 Proxy gRPC 應用程式與 Cloud Service Mesh 搭配使用時，部分功能無法使用。詳情請參閱「功能」頁面和「無 Proxy gRPC 的限制」頁面。

動作	API 欄位名稱	說明
重新導向	redirect [pathredirect?]	傳回可設定的 3xx 回應碼。此外，它也會使用適當的 URI 來設定 Location 回應標頭，以取代重新導向動作中所指定的主機和路徑。
網址重寫	urlRewrite	重新編寫網址的主機名稱部分、網址的路徑部分或兩者均重新編寫，然後再傳送要求至選取的後端服務。
標頭轉換	requestHeaderModifier/responseHeaderModifier?	在將要求傳送至後端服務前，新增或移除要求標頭。從後端服務收到回應後，這項設定也可以新增或刪除回應標頭。
流量鏡像	requestMirrorPolicy	除了將要求轉送到所選的後端服務外，也會以射後不理的模式，將完全相同的要求傳送至設定的鏡射後端服務。負載平衡器不會等待後端回應，而是將鏡像要求傳送至後端。 鏡射很適合用來測試新版本的後端服務。 您也可以使用這項功能，針對後端服務的偵錯版本 (而不是正式版本) 偵錯實際工作環境的錯誤。
根據權重拆分流量	weightDestination.serviceName	可將相符規則的流量分配給多個後端服務，並與指派給個別後端服務的使用者定義權重成正比。 此功能對於設定分階段部署或 A/B 測試非常實用。例如，轉送動作可以設定為將 99% 的流量傳送到執行穩定版應用程式的服務，而將 1% 的流量傳送到執行較新版應用程式的不同服務。
重試	retryPolicy	設定負載平衡器重試失敗要求的條件、負載平衡器在重試前等待的時間，以及允許的重試次數上限。
逾時	timeout	指定所選路徑的逾時時間。逾時時間的計算方式是從要求完全處理完畢開始，到回應完全處理完畢為止。逾時包括所有重試。
錯誤植入	faultInjectionPolicy	處理模擬故障的要求時，會產生高延遲、服務超載、服務故障和網路分區等錯誤。這項功能可用於測試服務對模擬故障的彈性。
安全性政策	corsPolicy	跨源資源共享 (CORS) 政策會處理用於強制執行 CORS 要求的設定。

如要進一步瞭解動作及其運作方式，請參閱網路服務 API 頁面。

在每個路由規則中，您可以指定下列其中一個路由動作：

• 將流量轉送至單一服務 (destination.serviceName)
• 利用流量拆分技巧，將流量導向多項服務 (destination.weight)
• 重新導向網址 (redirect)

此外，您可以將上述任一轉送動作與下列一或多個轉送動作合併使用 (在 Google Cloud 控制台中稱為「附加動作」)：

• 操控要求或回應標頭 (requestHeaderModifier/responseHeaderModifier)
• 鏡像流量 (requestMirrorPolicy)
• 重寫網址主機、路徑或兩者 (urlRewrite)
• 重試失敗的要求 (retryPolicy)
• 設定逾時 (timeout)
• 對一定比例的流量導入錯誤 (faultInjectionPolicy)
• 新增 CORS 政策 (corsPolicy)

由於動作與特定規則相關聯，因此 Envoy Proxy 或無 Proxy gRPC 應用程式可以根據處理的要求套用不同動作。

在服務的後端之間分配流量

如「要求處理」一節所述，當用戶端處理外送要求時，會先選取目的地服務。選取目的地服務後，需要找出應接收要求的後端或端點。

在後端之間分配流量 (按一下即可放大)

在上圖中，規則已簡化。「規則」通常是主機規則、路徑比對器，以及一或多個路徑或路徑規則。目的地服務是(後端) 服務。後端 1、… 和「後端 n」會接收並處理要求。舉例來說，這些後端可能是代管伺服器端應用程式碼的 Compute Engine 虛擬機器 (VM) 執行個體。

根據預設，處理要求的用戶端會將要求傳送至最近且容量充足的健康後端。為避免特定後端過載，系統會使用循環制負載平衡演算法，在目的地服務的其他後端之間，平衡後續要求。不過，在某些情況下，您可能需要更精細地控管這項行為。

負載平衡、工作階段相依性和保護後端

您可以在每項服務中設定下列流量分配政策。

政策	API 欄位名稱	說明
負載平衡模式	balancingMode	控制在選取目的地服務後，如何選取網路端點群組 (NEG) 或代管執行個體群組 (MIG)。您可以設定平衡模式，根據並行連線和要求比率分配負載。
負載平衡政策	localityLbPolicy	設定用於在 NEG 或 MIG 內的後端之間分配流量的負載平衡演算法。如要提升效能，您可以選擇各種演算法 (例如循環式或最少要求)。
工作階段相依性	sessionAffinity	盡可能將特定用戶端的要求傳送至同一個後端，只要該後端健康狀態良好並具有容量即可。 Cloud Service Mesh 支援四種工作階段相依性選項：用戶端 IP 位址、HTTP Cookie 型、HTTP 標頭型，以及產生的 Cookie 相依性 (由 Cloud Service Mesh 本身產生)。
一致的雜湊	consistentHash	根據 HTTP 標頭、Cookie 或其他屬性提供軟性工作階段相依性。
斷路器	circuitBreakers	設定後端服務連線量以及每個後端服務連線的要求數量上限。
離群值偵測	outlierDetection	指定條件，以便 (1) 從 MIG 或 NEG 移除健康狀態不良的後端或端點，以及 (2) 在後端或端點健康狀態良好到足以再次接收流量時，將其加回。與服務相關聯的健康狀態檢查會判斷後端或端點是否健康。

如要進一步瞭解不同的流量分配選項和運作方式，請參閱下列文件：

• backendServices REST API 頁面
• 後端服務總覽。

應用實例範例

進階流量管理功能可因應許多用途，本節提供幾個高階範例。

如需更多範例 (包括範例程式碼)，請參閱「透過 Envoy 設定進階流量管理」和「透過無 Proxy gRPC 服務設定進階流量管理」。

精細的流量路徑，可提供個人化服務

您可以根據要求的參數，將流量導向服務。舉例來說，您可能會使用這項服務，為 Android 使用者提供更貼近需求的體驗。在下圖中，Cloud Service Mesh 會設定服務網格，將含有 user-agent:Android 標頭的要求傳送至 Android 服務，而非一般服務。

根據設為 Android 的 user-agent 標頭進行轉送 (按一下即可放大)

根據權重分配流量，確保部署作業安全無虞

部署現有正式版服務的新版本可能會有風險。即使測試環境中的測試通過，您可能也不想立即將所有使用者導向新版本。

Cloud Service Mesh 可讓您定義以權重為依據的流量拆分，將流量分配給多個服務。舉例來說，您可以將 1% 的流量傳送到新版服務，監控一切是否正常運作，然後逐漸增加傳送到新版服務的流量比例。

Cloud Service Mesh 根據權重分配流量 (按一下即可放大)

流量鏡像功能，用於偵錯

偵錯問題時，將正式版流量副本傳送至偵錯服務，或許有助於解決問題。Cloud Service Mesh 可讓您設定要求鏡射政策，將要求傳送至某項服務，並將這些要求的副本傳送至另一項服務。

Cloud Service Mesh 流量鏡像 (按一下即可放大)

微調負載平衡以提升效能

視應用程式特性而定，您可能會發現微調流量在服務後端的分配方式，有助於提升效能和可用性。透過 Cloud Service Mesh，您可以套用進階負載平衡演算法，根據需求分配流量。

與先前的圖表相比，下圖同時顯示目的地後端服務 (「Production Service」) 和該後端服務的後端 (「Virtual Machine 1」、「Virtual Machine 2」、「Virtual Machine 3」)。透過進階流量管理，您可以設定目的地後端服務的選取方式，以及流量在該目的地服務後端之間的分配方式。

Cloud Service Mesh 負載平衡 (按一下可放大)

如要進一步瞭解如何使用 Cloud Service Mesh 進行負載平衡，請參閱進階負載平衡總覽。

後續步驟

• 如要將網格外部的流量導向網格，請參閱「適用於網格的輸入流量」。