本頁將概略介紹傳統版應用程式負載平衡器的流量管理功能。本頁面僅適用於傳統版應用程式負載平衡器。如果您使用其他模式的負載平衡器，並支援擴充的流量管理功能集，請參閱下列其中一個頁面：
傳統版應用程式負載平衡器支援流量管理功能，可讓您使用下列功能：
- 流量導向。根據 HTTP(S) 參數智慧地傳送流量：
- 流量動作。根據要求執行動作：
- 流量政策。微調負載平衡行為：
您可以使用負載平衡器的網址對應設定這些功能。如需背景資訊，請參閱下列主題：
流量管理元件
從高層次來看，外部應用程式負載平衡器會使用全域網址對應來管理流量。
負載平衡器提供下列互斥的主要動作：
- 將要求轉送至後端服務
- 執行重新導向
設定負載平衡器時，您可以設定網址重寫動作，負載平衡器就會在將要求傳送至後端服務或後端值區前執行該動作。
您可以在網址對應中，於三個層級套用重寫或重新導向：
- 在路徑相符時，動作生效的
pathRule - 在
pathMatcher中，當沒有路徑與這個pathMatcher相符時，動作會生效 urlMap：如果沒有任何主機規則中指定的主機相符，系統就會在此處執行動作
在 pathMatcher 中使用 routeRules 可替代 pathRules。pathRules 和 routeRules 不得同時出現在同一個 pathMatcher 中。
與 pathRules 不同，routeRules 會依序檢查。routeRule 可以測試網址路徑、HTTP 標頭和網址查詢參數。
應用實例範例
流量管理適用於許多用途。本節提供幾個高階範例。
重寫
網址重寫功能可讓您向外部使用者顯示與服務所用網址不同的網址。
網址重新編寫會將網址與資源分開。您可以將使用者容易記憶及使用的網址，轉換為搜尋引擎容易找到的網址，或是轉換為內部實作專用的網址。
網址重新編寫功能會執行下列作業：
- 讀取要求中的傳入網址。
- 取代主機、路徑，或主機和路徑，在將流量導向後端服務或後端值區前轉換網址。
在下圖中：
- 日本的使用者傳送網址要求
www.mydomain.com/static/images/someimage.jpg。 - 當要求抵達外部應用程式負載平衡器時，負載平衡器會使用網址對應中的資訊，將網址重新編寫為
www.myorigin.com/august_snapshot/images/someimage.jpg。 - (選用) 在這個範例中，網址對應會將要求傳送至外部後端。
如需設定範例，請參閱「重寫」。
重新導向
透過網址重新導向，您可以將用戶端要求從一個網址重新導向至另一個網址。
包括：
- 將所有 HTTP 要求重新導向至 HTTPS 要求。
- 重新導向至其他網址，該網址是透過修改網址的主機、路徑，或主機和路徑部分而形成，並可選擇移除或保留任何查詢參數。
- 選擇要發布的重新導向回應代碼。
網址重新導向可用於下列功能：
- 提供網址縮短服務。用戶端網址可以大幅縮短。這項服務會將使用者重新導向至含有長網址的網頁。
- 避免網頁移動或過時時出現無效連結。
- 允許屬於同一位擁有者的多個網域名稱參照單一網站。
- 避免在後端伺服器設定因應措施，以支援必要的重新導向，進而減少繁瑣作業和提升效率。
- 減少延遲時間。與在後端端點建立的重新導向相比，在邊緣建立的重新導向可縮短延遲時間。
HTTP 至 HTTPS 的重新導向功能可進一步協助您：
- 符合加密流量的法規遵循要求 (例如《健康保險流通與責任法案》)。
- 使用 HTTPS 重新導向要求，而非拒絕以 HTTP 通訊協定傳送的要求。
- 在第 7 層負載平衡器本身重新導向流量，而非在後端伺服器實作重新導向，可提升應用程式的安全設定檔。
在下圖中：
- 日本使用者傳送
GET http://example.com/img1要求。 - 根據網址對應中定義的重新導向，負載平衡器會傳回
HTTP/1.1 302 Found Location: https://example.com/img1重新導向，將 HTTP 要求重新導向至 HTTPS 要求。 - 使用者的瀏覽器會傳送
GET https://example.com/img1要求。
如需設定範例，請參閱「重新導向」。
支援的回應代碼
下表列出支援的重新導向回應代碼。
| 回應碼 | 數字 | 附註 |
|---|---|---|
| MOVED_PERMANENTLY_DEFAULT | 301 | |
| FOUND | 302 | |
| PERMANENT_REDIRECT | 308 | 在這種情況下，要求方法會保留。 |
| TEMPORARY_REDIRECT | 307 | 在這種情況下，要求方法會保留。 |
| SEE_OTHER | 303 |
根據標頭和參數轉送
負載平衡器可根據 HTTP 標頭和網址查詢參數，透過標頭型和參數型轉送做出轉送決策。
有了這項功能，您不必部署額外的 Proxy 層 (例如 NGINX) 進行路由，即可簡化雲端架構。
您可以使用外部應用程式負載平衡器執行下列操作：
- A/B 測試
- 將顧客指派給後端執行的不同服務組合
- 根據要求來源裝置的不同類別，提供不同的網頁和體驗
根據主機字串選取 pathMatcher 後，routeRules 會在 pathMatcher 中選取網址路徑。詳情請參閱 URL 地圖總覽。
範例：使用查詢參數式轉送設定 A/B 測試
以下範例說明如何透過比對查詢字串來指定實驗和輸入內容，進行 A/B 測試。
假設您希望要求按照下列方式處理：
- 所有查詢參數值為
A的要求，都會傳送至名為BackendServiceForProcessingOptionA的後端服務。 - 所有查詢參數值為
B的要求，都會傳送至名為BackendServiceForProcessingOptionB的後端服務。
下表匯總了這些規定。
| 要求 | 後端服務 |
|---|---|
http://test.mydomain.com?ABTest=A |
BackendServiceForProcessingOptionA |
http://test.mydomain.com?ABTest=B |
BackendServiceForProcessingOptionB |
如要在全域網址對應中設定這項功能，可以建立下列設定。
| 比對 | 動作 |
|---|---|
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTestpathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA |
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTestpathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB |
如需設定範例，請參閱「根據標頭和參數進行路由」。
將要求轉送至後端
系統會採用兩階段式做法，決定流量的後端：
負載平衡器會選取具有後端的後端服務。後端可以是下列項目：
- 非代管執行個體群組中的 Compute Engine 虛擬機器 (VM) 執行個體
- 代管執行個體群組 (MIG) 中的 Compute Engine VM
- 容器 (透過區域網路端點群組 (NEG) 中的 Google Kubernetes Engine (GKE) 節點)
- 網際網路 NEG 中的 Google Cloud 外部後端
- 後端 bucket 中的 Cloud Storage
- 無伺服器 NEG 中的 App Engine、Cloud Run functions 或 Cloud Run 服務
負載平衡器會根據全域網址對應中定義的規則選擇後端服務。
後端服務會根據全域後端服務中定義的政策，選取後端執行個體。
設定路徑時，您可以選擇下列模式：
- 使用
pathRules進行簡易主機與路徑測試 - 使用
routeRules進行進階要求測試
您可以為每個網址對應選擇使用簡易型主機與路徑規則，或是進階型主機、路徑與轉送規則。這兩種模式互斥。每個網址對應只能包含其中一種模式。
簡易型主機與路徑規則
在簡易型主機與路徑規則中，網址對應的運作方式如網址對應總覽所述。
下圖顯示簡易型主機與路徑規則的邏輯流程。
系統一開始會使用主機規則評估要求。主機是要求指定的網域。如果要求 host 符合 hosts 欄位中的其中一個項目，系統就會使用相關聯的路徑比對器。
接著，系統會評估路徑比對器。路徑規則會依據「優先比對最長路徑」原則來進行評估，且可採任意順序指定。找到最符合條件的規則後，要求會轉送至對應的後端服務。如果要求不符，系統會使用預設後端服務。
典型的簡易主機與路徑規則可能如下所示，其中影片流量會前往 video-backend-service，所有其他流量則會前往 web-backend-service。
$ gcloud compute url-maps describe ext-https-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: global/backendServices/video-backend-service
如需設定範例，請參閱「主機和路徑」。
進階主機、路徑和轉送規則
相較於簡易型主機與路徑規則，進階型主機、路徑與轉送規則提供更多設定選項。這些選項可啟用更進階的流量管理模式，並修改部分語意。舉例來說，系統會依序執行路徑規則 (而非使用最長路徑優先比對語意)。
如先前簡單的主機和路徑規則範例所示，您可以使用全域網址對應設定進階流量管理，但這次要使用 pathMatchers[].routeRules[]，而不是 pathMatchers[].pathRules[]。
以下各節說明進階主機、路徑和轉送規則元件。
主機規則
要求送達負載平衡器時，系統會根據網址對應中定義的 hostRules 評估要求中的 host 欄位。每個主機規則都包含一或多個主機的清單，以及單一路徑比對器 (pathMatcher)。如未定義 hostRules，要求會轉送至 defaultService。
詳情請參閱全球網址對應 API 說明文件中的 hostRules[] 和 defaultService。
路徑比對器
要求符合主機規則後，負載平衡器會評估與主機對應的路徑比對器。
路徑比對器由下列元件組成：
- 一或多個路徑規則 (
pathRules) 或轉送規則 (routeRules)。 如果沒有其他相符的後端服務，系統就會執行預設規則。規則有下列互斥選項：
- 預設服務會指定預設後端服務，以便在沒有其他相符的後端服務時，將流量轉送至該服務。
- 如果沒有其他相符的後端服務，系統就會根據預設重新導向網址重新導向。
為預設服務設定負載平衡器時，您還可以設定在將要求傳送至預設服務前，先重寫網址。
詳情請參閱全球網址對應 API 說明文件中的 pathMatchers[]、pathMatchers[].pathRules[] 和 pathMatchers[].routeRules[]。
路徑規則
路徑規則 (pathRules) 會指定一或多個網址路徑，例如 / 或 /video。
路徑規則通常適用於先前所述的簡易主機與路徑型路由。
詳情請參閱全球網址對應 API 說明文件中的 pathRules[]。
轉送規則
轉送規則 (routeRules) 會比對傳入要求中的資訊，並根據比對結果做出轉送決策。
轉送規則可以包含各種不同的比對規則 (matchRules) 和各種不同的轉送動作 (routeAction)。
比對規則會根據 HTTP(S) 要求路徑、標頭和查詢參數評估傳入要求。比對規則支援各種比對類型 (例如前置字串比對) 和修飾符 (例如不區分大小寫)。舉例來說，您可以根據自訂 HTTP 標頭是否存在，將 HTTP(S) 要求傳送至一組後端。
如需 matchRules 支援的選項詳細清單，請參閱全域網址對應 API 說明文件中的 matchRules[]。
如果您有多個路徑規則，負載平衡器會依序執行這些規則，讓您指定自訂邏輯來比對、路由及執行其他動作。
在特定路由規則中，找到第一個相符項目時，負載平衡器就會停止評估相符規則，並忽略所有剩餘相符規則。
Google Cloud 會執行下列動作：
- 尋找符合要求的第一個比對規則。
- 停止查看任何其他相符規則。
- 套用對應路徑動作中的動作。
轉送規則包含多個元件，如下表所示。
路徑規則元件 (API field name) |
說明 |
|---|---|
優先順序 (priority) |
指派給特定路徑比對器中轉送規則的數字，範圍為 0 到 2,147,483,647 (即 (2^31)-1)，用來決定轉送規則的評估順序。 最高優先順序為 0。最低優先順序為 2147483647。舉例來說，系統會先評估優先順序為 4 的規則，再評估優先順序為 25 的規則。系統會套用第一個符合要求的規則。優先順序編號可以有間隔，不一定要連續。 您無法建立多個優先順序相同的規則。 |
說明 (description) |
選填說明，最多 1,024 個半形字元。 |
服務 (service) |
如果符合這項規則，流量會導向的後端服務資源完整或部分網址。 |
比對規則 (matchRules) |
系統會根據要求評估一或多項規則。這些 matchRules 可以比對所有要求屬性或屬性子集 (例如路徑、HTTP 標頭和查詢 (GET) 參數)。在 matchRule 中，所有比對條件都必須符合，routeRule 的 routeActions 才會生效。如果 routeRule 具有多個 matchRules，則當要求與 routeRule 的任一 matchRules 相符時，routeRule 的 routeActions 即會生效。 |
轉送動作 (routeAction) |
可讓您指定符合比對規則條件時要採取的網址重寫動作。 |
重新導向動作 (urlRedirect) |
您可以設定動作，在符合相符規則條件時，以 HTTP 重新導向做為回應。這個欄位無法與路徑動作一併使用。 |
詳情請參閱全球網址對應 API 說明文件中的下列欄位：
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirect
比對規則
比對規則 (matchRules) 會比對要求的一或多項屬性，並採取轉送規則中指定的動作。以下列出一些可使用比對規則比對的要求屬性：
主機：主機名稱是網址的網域名稱部分；例如，網址
http://example.net/video/hd的主機名稱部分為example.net。要求中的主機名則以Host標頭表示，如下列 curl 指令範例所示，其中10.1.2.9是經過負載平衡的 IP 位址：curl -v http://10.1.2.9/video/hd --header 'Host: example.com'主機名稱後面即為路徑；例如
/images。此規則可以指定要比對整個路徑，還是僅比對路徑的前置部分。可進行 Cookie 比對以及根據查詢參數 (GET 變數) 進行比對的 HTTP 標頭等其他 HTTP 要求參數。請注意，系統不支援標頭值的規則運算式比對。
如需支援的對照規則完整清單，請參閱pathMatchers[].routeRules[].matchRules[]全球網址對照表 API 說明文件。
設定流量管理
您可以使用 Google Cloud 控制台、gcloud 或 Cloud Load Balancing API 設定流量管理。在所選設定環境中，您可以使用 YAML 設定檔設定流量管理。
如需編寫這些 YAML 檔案的說明，請參閱下列資源：
-
提供完整欄位清單，包括關係、限制和基數的語意。
流量管理設定頁面範例：