本頁面將概略說明傳統版應用程式負載平衡器的流量管理功能。本頁面僅適用於傳統版應用程式負載平衡器。如果您使用負載平衡器的其他模式,並支援擴充的流量管理功能集,請參閱下列任一頁面:
傳統版應用程式負載平衡器支援流量管理功能,可讓您使用下列功能:
- 流量導向。根據 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 | |
已找到 | 302 | |
PERMANENT_REDIRECT | 308 | 在這種情況下,系統會保留要求方法。 |
TEMPORARY_REDIRECT | 307 | 在這種情況下,系統會保留要求方法。 |
SEE_OTHER | 303 |
標頭和參數型轉送
標頭式和參數式轉送可讓負載平衡器根據 HTTP 標頭和網址查詢參數做出轉送決策。
有了這項功能,您就能簡化雲端架構,不必部署額外的代理伺服器層級 (例如 NGINX) 來進行路由。
您可以使用外部應用程式負載平衡器執行下列操作:
- A/B 測試
- 將客戶指派給在後端執行的不同服務
- 根據要求來源的不同類別裝置,提供不同的頁面和體驗
在根據主機字串選取 pathMatcher
後,pathMatcher
中的 routeRules
會選取網址路徑。詳情請參閱「網址對應總覽」。
範例:使用查詢參數式轉送設定 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 = ABTest pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA |
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB |
如需設定範例,請參閱「以標頭和參數為依據的路由」。
將要求轉送至後端
系統會透過兩階段方式,判斷流量的後端:
負載平衡器會選取具有後端的後端服務。後端可以是下列任一項:
- 非代管執行個體群組中的 Compute Engine 虛擬機器 (VM) 執行個體
- 代管執行個體群組 (MIG) 中的 Compute Engine VM
- 透過區域網路端點群組 (NEG) 中的 Google Kubernetes Engine (GKE) 節點建立容器
- 網際網路 NEG 中 Google Cloud 以外的外部後端
- 後端值區中的 Cloud Storage
- 無伺服器 NEG 中的 App Engine、Cloud Run 函式或 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 屬性或屬性子集,例如路徑、HTTP 標頭和查詢 (GET) 參數。在 matchRule 中,必須符合所有比對條件,routeRule 的 routeActions 才會生效。如果 routeRule 有多個 matchRules ,則當要求與 routeRule 的任一 matchRules 相符時,routeRule 的 routeActions 就會生效。 |
路由動作 (routeAction ) |
可讓您指定在符合比對規則條件時,要採取的網址重寫動作。 |
重新導向動作 (urlRedirect ) |
您可以設定動作,在符合比對規則條件時以 HTTP 重新導向回應。這個欄位無法與路徑動作搭配使用。 |
詳情請參閱 全球網址對應 API 說明文件中的下列欄位:
routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].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 要求參數。請注意,系統不支援標頭值的規則運算式比對。
如需支援的對照規則完整清單,請參閱 全球網址對照 API 說明文件中的 pathMatchers[].routeRules[].matchRules[]
。
設定流量管理
您可以使用 Google Cloud 主控台、gcloud
或 Cloud Load Balancing API 設定流量管理。在所選設定環境中,您可以使用 YAML 設定檔設定流量管理。
如需編寫這些 YAML 檔案的說明,請參閱下列資源:
-
提供完整的欄位清單,包括關於關係、限制和基數的語意。
流量管理設定頁面上的範例: