本頁面由 Cloud Translation API 翻譯而成。

網址對應總覽

Google Cloud 應用程式負載平衡器和 Cloud Service Mesh 使用稱為「網址對應」 Google Cloud的設定資源，將 HTTP(S) 要求轉送至後端服務或後端 bucket。

舉例來說，使用外部應用程式負載平衡器時，您可以根據單一網址對應中設定的規則，將要求轉送至不同目的地：

將 https://example.com/video 的要求轉送至某個後端服務。
將 https://example.com/audio 的要求轉送至其他後端服務。

將 https://example.com/images 的要求轉送至 Cloud Storage 後端 bucket。

將任何其他主機和路徑組合的要求轉送至預設後端服務。

網址對應可用於下列 Google Cloud 產品：

外部應用程式負載平衡器 (全域、區域和傳統模式)
內部應用程式負載平衡器 (跨區域和區域模式)
Cloud Service Mesh：如果 Cloud Service Mesh 是透過負載平衡 API 部署，

網址對應資源有兩種：全域和區域。

全域 urlMaps 用於全域外部應用程式負載平衡器、傳統版應用程式負載平衡器、跨區域內部應用程式負載平衡器和 Cloud Service Mesh。
regionUrlMaps 用於區域外部應用程式負載平衡器、區域內部應用程式負載平衡器和 Cloud Service Mesh。

使用的資源類型取決於產品的負載平衡架構。

產品	負載平衡架構	網址對應資源類型	支援的目的地
全域外部應用程式負載平衡器	`EXTERNAL_MANAGED`	全球	後端服務、後端 bucket
傳統版應用程式負載平衡器	`EXTERNAL`	全球	後端服務、後端 bucket
區域性外部應用程式負載平衡器	`EXTERNAL_MANAGED`	區域	後端服務
跨區域內部應用程式負載平衡器	`INTERNAL_MANAGED`	全球	後端服務
區域性內部應用程式負載平衡器	`INTERNAL_MANAGED`	區域	後端服務
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	全球	後端服務
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	區域	後端服務

並非所有產品都支援所有網址對應功能。搭配全域外部應用程式負載平衡器、區域外部應用程式負載平衡器、內部應用程式負載平衡器和 Cloud Service Mesh 使用的網址對應，也支援多項進階流量管理功能。如要進一步瞭解這些差異，請參閱負載平衡器功能比較：轉送和流量管理。此外，地區網址對應也可以是指定為App Hub 應用程式中服務的資源。

網址對應的運作方式

當要求到達負載平衡器時，負載平衡器會根據網址對應中定義的規則，將要求轉送至特定的後端服務或後端值區。

後端服務代表後端集合，也就是應用程式或微服務的執行個體。後端值區是 Cloud Storage 值區，通常用於代管靜態內容，例如圖片。

如果是區域性外部應用程式負載平衡器、內部應用程式負載平衡器和 Cloud Service Mesh，可能的目的地如下：

預設後端服務
非預設後端服務

此外，全域外部應用程式負載平衡器還支援下列功能：

預設後端 bucket
非預設後端 bucket

例如，假設您的設定如下：

一個 IP 位址：
- 針對您機構的所有要求都會傳送至相同的 IP 位址和相同的負載平衡器。
- 系統會根據要求網址將流量導向至不同的後端服務。
兩個網域：
- example.net 託管訓練影片。
- example.org 託管貴機構網站。
四組伺服器：
- 一組用於託管您的機構網站 (後端服務：org-site)。
- 一組用於託管整個訓練影片網站 (後端服務： video-site)。
- 一組用於託管高畫質 (HD) 訓練影片 (後端服務： video-hd)。
- 一組用於託管標準畫質 (SD) 訓練影片 (後端服務： video-sd)。

您希望發生以下情況：

將針對 example.org (或 example.net 以外的任何網域) 的要求傳送至 org-site 後端服務。
將針對 example.net (與其他特定路徑不相符) 的要求傳送至 video-site 後端服務。
將對 example.net/video/hd/* 的要求傳送至 video-hd 後端服務。
將對 example.net/video/sd/* 的要求傳送至 video-sd 後端服務。

/video/* 的 --path-rule 會比對 /video/test1 和 /video/test2 等 URI。不過，這項路徑規則與路徑「/video」不符。

如果負載平衡器收到網址含有 /../ 的要求，負載平衡器會移除 .. 前的路徑區隔，並以轉換後的網址做出回應。舉例來說，當要求傳送至 http://example.net/video/../abc 時，負載平衡器會以 302 重新導向回應 http://example.net/abc。接著，大多數用戶端會發出要求給負載平衡器傳回的網址 (在本例中為 http://example.net/abc)，藉此做出回應。Cloud Logging 不會記錄這項 302 重新導向。

您可以使用網址對應設定這類主機和路徑轉送。

負載平衡器命名

如果是應用程式負載平衡器，負載平衡器的名稱一律與網址對應的名稱相同。各 Google Cloud 介面的行為如下：

Google Cloud console. 如果您使用Google Cloud 控制台建立應用程式負載平衡器，系統會自動為網址對應指派您輸入的負載平衡器名稱。
Google Cloud CLI 或 API：如果您使用 gcloud CLI 或 API 建立應用程式負載平衡器，請在建立網址對應時輸入您選擇的名稱。這個網址對應名稱隨後會反映在Google Cloud 控制台中，做為負載平衡器的名稱。

如要瞭解 Proxy 網路負載平衡器和直通式網路負載平衡器的命名方式，請參閱「後端服務總覽：負載平衡器命名」。

網址對應元件

網址對應是一組設定資源 Google Cloud ，可將針對網址的要求導向至後端服務或後端值區。網址對應會使用網址的主機名稱和路徑部分做為導向依據：

主機名稱是網址的網域名稱部分；例如，網址 http://example.net/video/hd 的主機名稱部分是 example.net。
路徑是網址中主機名稱和選用連接埠號碼後面的部分；例如，網址 http://example.net/video/hd 的路徑部分是 /video/hd。

具備基本網址對應的負載平衡器設定。 — 使用基本網址對應的負載平衡器設定 (按一下即可放大)。

這張圖表顯示負載平衡設定物件彼此之間的關係。

您可以透過下列網址對應設定參數，控制要用哪些後端服務或後端值區來接收傳入的要求：

預設後端服務或預設後端值區。建立網址對應時，您必須指定預設後端服務或預設後端值區，但不能同時指定兩者。除非另有適用的主機規則，否則此預設值表示 Google Cloud 會將帶有任何主機名稱的網址要求導向至預設後端服務或後端值區。

注意： 內部應用程式負載平衡器和 Cloud Service Mesh 不支援後端值區。
主機規則 (hostRules)。主機規則會將傳送到一或多個相關主機名稱的要求，導向至單一路徑比對器 (pathMatchers)。網址的主機名稱部分與主機規則設定的主機名稱完全相符，或使用規則運算式比對。在網址對應主機和路徑規則中，如果省略主機，規則會比對任何要求的主機。如要將針對 http://example.net/video/hd 的要求導向至路徑比對器，您必須有一個主機規則至少包含主機名稱 example.net。這個主機規則也可以處理其他主機名稱的要求，但會將它們導向至相同的路徑比對器。

如果需要將要求導向至不同的路徑比對器，您必須使用不同的主機規則。網址對應中的兩個主機規則不能包含相同的主機名稱。

您可以在主機規則中指定萬用字元 *，比對所有主機名稱。以網址 http://example.org、http://example.net/video/hd 和 http://example.com/audio 為例，其主機名稱 example.org、example.net 和 example.com 都可以透過在主機規則中指定 * 來達成比對。您也可以指定萬用字元 * 來比對部分主機名稱。舉例來說，主機規則 *.example.net 可與主機名稱 news.example.net 和 finance.example.net 都達成比對。

通訊埠編號。不同的應用程式負載平衡器處理連接埠號碼的方式不同。如果是內部應用程式負載平衡器，您可以使用 Host 規則參數指定通訊埠號碼。舉例來說，如要將通訊埠 8080 的要求導向 example.net，請將主機規則設為 example.net:8080。如果是傳統型應用程式負載平衡器，系統只會比對網址中的主機名稱，舉例來說，通訊埠 8080 和通訊埠 80 的 example.net 要求會比對主機規則 example.net。

注意： 負載平衡器不會驗證網址中的主機名稱值。用戶端可以為主機名稱設定任意值，例如設定 Host 標頭。您不應使用主機名稱欄位，為應用程式實作存取權控管。
路徑比對器 (pathMatchers)。路徑比對器是主機規則所參照的設定參數。它定義了網址的路徑部分與應處理要求的後端服務或後端 bucket 之間的關係。路徑比對器包含下列兩項元素：
- 路徑比對器預設後端服務或路徑比對器預設後端值區。對於每個路徑比對器，您必須至少指定一個預設後端服務或預設後端值區，但不能同時指定兩者。這個預設值表示，Google Cloud 會將主機名稱與路徑比對器相關主機規則相符的網址要求，以及網址路徑與路徑比對器中的任何路徑規則都不相符的網址要求，導向至預設後端服務或後端值區。
- 路徑規則。您可以為每個路徑比對器指定一或多個路徑規則，這些規則是將網址路徑對應到單個後端服務或後端值區的鍵/值組合。
  
  彈性模式比對運算子可使用萬用字元語法，比對網址路徑的多個部分，包括不完整的網址和後置字元 (副檔名)。當您需要根據複雜的網址路徑轉送流量及執行重寫作業時，這些運算子就派得上用場。您也可以將一或多個路徑元件與具名變數建立關聯，然後在重寫網址時參照這些變數。使用具名變數，您可以在要求傳送至來源之前，重新排序及移除網址元件。詳情請參閱「路徑規則中的萬用字元、規則運算式和動態網址」。
  
  如果您需要更進階的轉送功能，例如要將特定網址的流量導向多個服務，可以使用轉送規則，而非路徑規則。
- 轉送規則。如需進階流量轉送功能 (例如根據網址路徑、HTTP 標頭和查詢參數轉送流量)，可以使用轉送規則來取代路徑規則。
  
  您可以透過彈性模式比對運算子和具名變數，設定路徑規則。當您需要根據複雜的網址路徑轉送流量及執行重寫作業時，這些運算子就派得上用場。詳情請參閱路徑範本中的萬用字元和模式比對運算子 (適用於路徑規則)。
  
  您也可以設定比對路徑、查詢參數或傳入要求中標頭的規則運算式。詳情請參閱「路徑規則中的規則運算式」。

主機名稱和主機規則關係

主機名稱只能參照單一主機規則。
單一主機規則可以處理多個主機名稱。

主機規則和路徑比對器關係

多個主機規則可以參照單一路徑比對器。
主機規則只能參照單一路徑比對器。

網址和後端關係

每個專屬網址只會導向到一個後端服務或後端值區。因此：

Google Cloud 會使用網址的主機名稱部分，選取單一主機規則及其參照的路徑比對器。
在路徑比對器中使用路徑規則時，您不能為同一路徑建立多個路徑規則。例如，針對 /videos/hd 的要求無法導向至超過一個的後端服務或後端值區。後端服務可以在不同區域和地區中具有後端執行個體群組或後端網路端點群組 (NEG)，您也可以建立使用多區域儲存空間級別的後端值區。

如要將特定網址的流量導向多項服務，可以使用轉送規則，而非路徑規則。如果您為路徑比對器設定標頭或參數比對的路徑規則，系統會根據網址的標頭或查詢參數內容，將專屬網址導向多個後端服務或值區。

同樣地，對於區域外部應用程式負載平衡器和 Cloud Service Mesh，路徑動作上的加權後端服務可根據加權後端服務上設定的權重，將相同網址導向多個後端服務或 bucket。

網址對應和通訊協定

只要目標 HTTP Proxy 和目標 HTTPS Proxy 都參照網址對應，您就可以使用相同的網址對應、主機規則和路徑比對器，處理用戶端提交的 HTTP 和 HTTPS 要求。

最簡單的網址對應

最簡單的網址對應僅有預設的後端服務或預設的後端值區，不含任何主機規則，也沒有路徑比對器。所有要求網址都會由預設的後端服務或後端值區處理 (視您的定義而定)。

如果您定義了預設後端服務， Google Cloud 會根據後端服務的設定，將要求導向至其後端執行個體群組或後端 NEG。

除預設服務外沒有任何其他規則的網址對應。 — 除預設服務外沒有任何其他規則的網址對應 (點選即可放大)。

作業順序

對於要求網址中的特定主機名稱和路徑， Google Cloud 會使用下列程序將要求導向至正確的後端服務或後端值區 (如網址對應的設定)：

如果網址對應不包含網址主機名稱的主機規則，Google Cloud 會根據您的定義，將要求導向至網址對應的預設後端服務或預設後端值區。
如果網址對應含有具網址主機名稱的主機規則，系統會查詢該主機規則參照的路徑比對器：
- 如果路徑比對器含有與網址路徑完全相符的路徑規則， Google Cloud 會將要求導向至該路徑規則的後端服務或後端值區。
- 如果路徑比對器不含與網址路徑完全相符的路徑規則，但含有結尾為 /* 的路徑規則 (其前置字串與網址路徑中「最長的一段」相符)，則 Google Cloud會將要求至導向該路徑規則的後端服務或後端值區。舉例來說，網址對應含有兩個路徑比對器規則 /video/hd/movie1 和 /video/hd/*，如果網址包含與 /video/hd/movie1 完全相符的路徑，則會與該路徑規則達成比對。
- 如果前面的條件都不成立， Google Cloud 會將要求導向至路徑比對器的預設後端服務或預設後端值區 (視您的定義而定)。

網址對應設定限制

以下各節說明網址對應元件的特定設定限制。

主機和路徑規則中的規則運算式比對器

主機規則可讓您比對網址的主機名稱部分與主機規則設定的主機名稱。您可以選擇在 hostRules[].hosts[] 欄位中使用特定主機名稱或萬用字元 *，與傳入要求中的主機名稱比對。

轉送規則可讓您定義比對規則，比對傳入要求中的路徑、查詢字串或標頭是否符合規則運算式。轉送規則支援對下列網址對應欄位使用規則運算式：

pathMatchers[].routeRules[].matchRules[].regexMatch：用於比對連入要求路徑的規則運算式。
pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch：規則運算式，內含與傳入要求標頭相符的述詞。
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch：規則運算式，內含與傳入要求查詢參數相符的述詞。

只要符合任一 matchRule，系統就會將要求視為符合 routeRule。不過，特定 matchRule 中的述詞具有 AND 語意。也就是說，matchRule 中的所有述詞都必須符合，要求才會符合規則。

其他使用注意事項：

規則運算式僅適用於下列產品：
- 區域性內部應用程式負載平衡器
- 跨區域內部應用程式負載平衡器
- 區域性外部應用程式負載平衡器
全域和傳統版應用程式負載平衡器不支援規則運算式。
您必須使用 RE2 語法建構規則運算式。如需網址對應中允許的限制和運算子完整清單，請參閱網址對應的 RE2 規格。
以規則運算式比對會耗用大量記憶體，且要求處理延遲時間較長。如果您選擇使用規則運算式比對，規劃部署時就必須考量效能降低的問題。舉例來說，如果網址對應包含單一規則運算式，預期每個要求的負載平衡器延遲時間會增加 100 微秒。如果網址對應包含 5 個要比對的規則運算式，則每個要求的延遲時間預計會增加 200 微秒。

範例 1：使用規則運算式比對路徑

如果路徑符合 regexMatch 指定的規則運算式，且已移除原始網址提供的所有查詢參數和錨點，系統就會將該路徑視為相符。舉例來說，在下列範例網址對應中，轉送規則的規則運算式 /videos/hd.* 會套用至路徑為 /videos/hd-abcd?key=245 的網址。

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

以下是範例網址對應表各個欄位的說明：

defaultService：指定要使用的預設後端服務，前提是網址對應中的其他規則都不符合連入要求。
name：將名稱 rule-match-url-map 指派給這個網址對應設定。
hostRules：定義規則清單，用於比對傳入要求的主機標頭。第一條規則會比對任何主機 (*)，並將流量導向名為 pathMatcher 的 video-matcher。第二個規則會比對主機 example.net，並將流量導向名為 video-matcher 的路徑比對器。
pathMatchers：定義具名路徑比對器清單。
name：定義名為 video-matcher 的路徑比對器。
defaultService：為這個路徑比對器設定預設服務。如果要求符合指向 video-matcher 的主機規則，但不符合其中的任何 routeRules，就會使用這項服務。
routeRules：包含比對網址路徑的規則清單。
priority：將這項規則的優先順序設為 100000。系統會依優先順序編號由低至高評估規則。
matchRules：包含要比對這項路徑規則的條件。
regexMatch：這項條件會檢查網址路徑是否符合規則運算式 /videos/hd.* (例如「/videos/hd」和「/videos/hd-caching」)。
routeAction：指定符合 matchRules 中所有條件時要採取的動作。
weightedBackendServices：根據權重，將流量分配至後端服務清單。
backendService：指定要將流量轉送至哪個後端服務。
weight：為這個後端服務指派 100 的權重。由於這是清單中唯一的服務，因此會收到與這項 routeRule 相符的 100% 流量。

下方的網址對應表顯示類似範例，但未使用 routeAction。

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

範例 2：使用規則運算式比對標頭

如果標頭值符合 regexMatch 指定的規則運算式，系統就會將標頭視為相符。舉例來說，在下列範例網址對應中，標頭名稱規則運算式 .*Android.*-hd 會套用至含有標頭 User-Agent:123Androidabc-hd 的要求。

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

以下是範例網址對應表各個欄位的說明：

defaultService：指定要使用的預設後端服務，前提是網址對應中的其他規則都不符合連入要求。
name：將名稱 header-match-url-map 指派給這個網址對應設定。
hostRules：定義規則清單，用於比對傳入要求的主機標頭。這項規則會比對任何主機 (「*」)，並將流量導向名為「header-matcher」的 pathMatcher。
pathMatchers：定義具名路徑比對器清單。
name：定義名為 header-matcher 的路徑比對器。
defaultService：為這個路徑比對器設定預設服務。如果要求符合主機規則，但不符合這個路徑比對器中的任何 routeRules，就會使用這項服務。
routeRules：包含規則清單，可根據標頭和路徑比對傳入的要求。
priority：將這項規則的優先順序設為 1。系統會依優先順序編號評估規則，從最低到最高。
matchRules：包含條件清單，所有條件都必須為 true，規則才會相符。
headerMatches：根據要求標頭指定條件。
headerName：尋找 User-Agent 標頭。
regexMatch：檢查 User-Agent 標頭值是否符合規則運算式 .*Android.*-hd。這會比對指出 Android 裝置的 User-Agent，且字串包含「-hd」。
prefixMatch：設為 /video/，這個條件會檢查網址路徑是否以「/video/」開頭。
service：如果符合所有 matchRules 條件，流量就會導向這個後端服務。
註解掉的 routeAction 區段顯示指定後端服務的替代方式，如果您需要設定其他路徑動作 (例如網址重寫、標頭轉換或加權後端服務)，就必須使用這種方式。

範例 3：使用規則運算式比對查詢參數

如果路徑的值 (含查詢參數) 符合 regexMatch 指定的規則運算式，系統就會將查詢參數視為相符。舉例來說，在下列範例網址對應中，查詢參數的規則運算式 /im.*/.*.html 會套用至含有查詢參數的網址，例如 /images/random_page.html?param1=param_value_123abc-hd。

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

以下是範例網址對應表各個欄位的說明：

hostRules：新增規則來比對所有主機 (*)，並將流量導向名為 query-matcher 的 pathMatcher。
pathMatchers：定義名為「query-matcher」的路徑比對器。
routeRules：將提供的 routeRules 區塊放在 query-matcher 中。
priority：將這項規則的優先順序設為 1。系統會依優先順序編號評估規則，編號越小越先評估。
matchRules：包含 routeRules 的條件。
queryParameterMatches：檢查名為「param1」的查詢參數是否符合規則運算式 param_value_.*-hd。
regexMatch：/im.*/.*.html 規則運算式適用於網址路徑 (例如 /images/random_page.html)，位於查詢字串之前。
service：指定當 matchRules 內的所有條件都成立時，要使用的後端服務。

路徑規則和前置字串比對中的萬用字元、規則運算式和動態網址

路徑規則 (pathMatchers[].pathRules[]) 只能在正斜線字元 (/) 之後加上萬用字元 (*)。舉例來說，/videos/* 和 /videos/hd/* 是路徑規則的有效格式，但 /videos* 和 /videos/hd* 則否。
路徑規則不使用規則運算式或子字串比對。 PathTemplateMatch 可以使用簡化的路徑比對運算子。舉例來說，/videos/hd 或 /videos/hd/* 的路徑規則不適用於含有路徑 /video/hd-abcd 的網址。然而，/video/* 的路徑規則卻能適用。
前置碼比對 (pathMatchers[].routeRules[].matchRules[].prefixMatch) 不會將 * 視為萬用字元，而是常值字元。
路徑比對器 (通常指網址對應) 不提供類似於 Apache <LocationMatch> 指令的功能。如果您的應用程式會產生具有共同前置字串的動態網址路徑 (例如 /videos/hd-abcd 和 /videos/hd-pqrs，而您必須將對這些路徑的要求傳送至不同的後端服務，可能無法透過網址對應來達成目標。如果是只有少數幾個動態網址的情況，您「或許」可以建立具有限路徑規則組合的路徑比對器。如果是較複雜的情況，您必須在後端進行以路徑為依據的規則運算式比對。

路徑範本中的萬用字元和模式比對運算子 (適用於路徑規則)

彈性模式比對運算子可使用萬用字元語法，比對網址路徑的多個部分，包括不完整的網址和後置字元 (副檔名)。如果需要根據複雜的網址路徑轉送流量及執行重寫作業，這些運算子就派得上用場。您也可以將一或多個路徑元件與具名變數建立關聯，然後在重寫網址時參照這些變數。使用具名變數，您可以在要求傳送至來源前，重新排序及移除網址元件。

只有下列產品支援使用萬用字元進行模式比對：

全域外部應用程式負載平衡器

區域性外部應用程式負載平衡器
區域性內部應用程式負載平衡器

跨區域內部應用程式負載平衡器
Cloud Service Mesh

下列範例會為電子商務應用程式的流量設定路徑，該應用程式具有購物車資訊和使用者資訊的個別服務。您可以透過彈性模式比對運算子和具名變數設定 routeRules，在重寫網址後，將使用者的專屬 ID 傳送至使用者帳戶詳細資料頁面，並將使用者的購物車資訊傳送至購物車處理服務。

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

以下說明用戶端要求 /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB 時會發生什麼情況，其中包含使用者資訊和購物車資訊：

要求路徑與 cart-matcher 內的 pathTemplateMatch 相符。{username=*} 變數會比對 abc@xyz.com，而 {cartid=**} 變數會比對 FL0001090004/entries/SJFI38u3401nms。
查詢參數會從路徑中分割出來，路徑會根據 pathTemplateRewrite 重新編寫，查詢參數則會附加至重新編寫的路徑。我們只能使用在 pathTemplateRewrite 中定義 pathTemplateMatch 時所用的變數。
重新編寫的要求會傳送至 cart-backend，並使用重新編寫的網址路徑：/abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB。

如果用戶改為要求 /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234，其中只包含使用者和帳戶資訊，則會發生以下情況：

要求路徑與 user-matcher 內的 pathTemplateMatch 相符。第一個 * 符合 abc%40xyz.com，第二個 * 符合 abc-1234。
要求已傳送給 user-backend。

下表列出路徑範本模式的語法。

運算子	相符
*``**	單一路徑區隔，不含周圍的路徑分隔符 `/` 字元。
``**	比對零或多個字元，包括多個路徑區段之間的任何路徑分隔符 `/` 字元。如果包含其他運算子，`**` 運算子必須是最後一個運算子。
*`{name}` 或 `{name=}`**	與一個路徑區段相符的具名變數。比對單一路徑區隔，不包括周圍的路徑分隔符 `/` 字元。
*`{name=news/}`**	明確符合兩個路徑區隔的具名變數： `news` 和 `*` 萬用字元區隔。
*`{name=/news/}`*	與三個路徑區隔相符的具名變數。
`{name=}`**	符合零個或多個字元的具名變數。如果有的話，必須是最後一個運算子。

使用這些運算子進行彈性模式比對時，請注意下列事項：

單一模式中可合併多個運算子。
查詢參數會從路徑中分割出來，路徑會根據 pathTemplateRewrite 重新編寫，查詢參數則會附加至重新編寫的路徑。
要求不會經過百分比編碼正規化處理。舉例來說，如果網址含有百分比編碼的正斜線字元 (%2F)，系統不會解碼為未編碼的格式。
每個變數名稱 (例如 {segment} 或 {region}) 在同一個模式中只能出現一次。如果有多個同名變數，系統會視為無效並拒絕。
變數名稱會區分大小寫，且必須是有效的 ID。如要檢查變數名稱是否有效，請確認名稱符合規則運算式 ^[a-zA-Z][a-zA-Z0-9_]*$。
- {API}、{api} 和 {api_v1} 都是有效的 ID。他們找出三個不同的變數。
- 「{1}」、「{_api}」和「{10alpha}」不是有效的 ID。
每個範本模式最多只能有五個運算子。

如要在要求傳送至來源前執行選用的網址重新編寫作業，可以使用您定義的相同變數來擷取路徑。舉例來說，定義 urlRewrite 時，您可以在 pathTemplateRewrite 欄位中參照、重新排序或省略變數。

使用變數和運算符彈性比對網址重新編寫模式時，請注意下列事項：

重寫網址時，如果重寫後的網址不需要變數，可以省略。
在進行任何重新編寫作業前，您可以檢查回應標頭，找出用戶端在來源傳送的網址。原始用戶端網址會填入 x-client-request-url 標頭和 x-envoy-original-path 標頭。

外部應用程式負載平衡器的網址對應工作流程範例

以下範例說明網址對應的作業順序。這個範例只會為現有的傳統應用程式負載平衡器設定網址對應。為了方便理解，這個範例只使用後端服務；但您可以改用後端 bucket。如要瞭解如何建立負載平衡器的其他元件，請參閱「建立傳統型應用程式負載平衡器」。

如要進一步瞭解如何使用路徑比對器和主機規則建立及設定網址對應，請參閱gcloud compute url-maps create說明文件。

為負載平衡器建立網址對應，並指定預設的後端服務。本範例建立名為 video-org-url-map 的網址對應，而該網址對應參照了名為 org-site 的現有後端服務。
```
gcloud compute url-maps create video-org-url-map \
    --default-service=org-site
```
建立名為 video-matcher 的路徑比對器，其特性如下：
- 預設的後端服務是 video-site，這是現有的後端服務。
- 新增路徑規則，將針對網址路徑 /video/hd或網址路徑前置字串 /video/hd/* 的要求，導向至名為 video-hd 的現有後端服務。
- 新增路徑規則，將針對網址路徑 /video/sd或網址路徑前置字串 /video/sd/* 的要求，導向至名為 video-sd 的現有後端服務。
```
gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
```

為參照 video-matcher 路徑比對器的 example.net 主機名稱建立主機規則。

gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

video-org-url-map 網址對應表應如下所示：

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

video-org-url-map 網址對應透過以下方式將要求的網址導向至後端。

具有路徑規則、路徑比對器和主機規則的網址對應。 — 具有路徑規則、路徑比對器和主機規則的網址對應 (點選即可放大)。

下表說明上圖所示的要求處理程序。

主機名稱	網址路徑	選取的後端服務	選取理由
主機名稱： `example.org` 和其他所有主機名稱，但不含 `example.net`	所有路徑	`org-site`	主機名稱不在網址對應的任何主機規則中，因此會將要求導向至網址對應的預設後端服務。
主機名稱： `example.net`	`/video` `/video/examples`	`video-site`	將要求導向至預設的後端服務，因為 `/video/` 或 `/video/*` 沒有路徑規則。`example.net` 的主機規則參照了一個路徑比對器，但該路徑比對器沒有任何適用於這些路徑的路徑規則。
主機名稱： `example.net`	`/video/hd` `/video/hd/movie1` `/video/hd/movies/movie2` 其他開頭為 `/video/hd/*` 的網址	`video-hd`	`example.net` 的主機規則參照了一個路徑比對器，該路徑比對器的路徑規則會將針對與 `/video/hd` 完全相符或開頭為 `/video/hd/*` 之網址路徑的要求導向至 `video-hd` 後端服務。
主機名稱： `example.net`	`/video/sd` `/video/sd/show1` `/video/sd/shows/show2` 其他開頭為 `/video/sd/*` 的網址	`video-sd`	`example.net` 的主機規則參照了一個路徑比對器，該路徑比對器的路徑規則會將針對與 `/video/sd` 完全相符或開頭為 `/video/sd/*` 之網址路徑的要求導向至 `video-sd` 後端服務。

網址重新導向

網址重新導向會將網域訪客從一個網址重新導向至另一個網址。

預設網址重新導向不會根據連入要求中是否符合特定模式而有所不同。舉例來說，您可能想使用預設網址重新導向，將任何主機名稱重新導向至所選主機名稱。

建立網址重新導向的方法有很多種，詳見下表。

方法	設定
網址對應的預設網址重新導向	頂層 `defaultUrlRedirect`
路徑比對器的預設網址重新導向	`pathMatchers[].defaultUrlRedirect[]`
路徑比對器的路徑規則網址重新導向	`pathMatchers[].pathRules[].urlRedirect`
路徑比對器的轉送規則網址重新導向	`pathMatchers[].routeRules[].urlRedirect`

在 defaultUrlRedirect 或 urlRedirect 中，pathRedirect 一律會按照下列方式運作：

整個要求路徑會替換為您指定的路徑。

在 defaultUrlRedirect 或 urlRedirect 內，prefixRedirect 的運作方式取決於您的使用方式：

如果您使用 defaultUrlRedirect，prefixRedirect 實際上是前置字串前置，因為相符路徑一律為 /。
如果您在路徑比對器的轉送規則或路徑規則中使用 urlRedirect，prefixRedirect 會根據要求路徑的相符情形，取代路徑規則或轉送規則中定義的前置字串。

重新導向範例

下表提供重新導向設定的範例。右欄會顯示預設網址重新導向的 API 設定。

你想要	使用預設網址重新導向功能完成
HTTP 到 HTTPS 的重新導向重新導向 http://host.name/path 至 https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
HTTP 到 HTTPS + 主機重新導向重新導向 http://any-host-name/path 至 https://www.example.com/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com"
HTTP 到 HTTPS + 主機重新導向 + 完整路徑重新導向重新導向 http://any-host-name/path 至 https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
HTTP 到 HTTPS + 主機重新導向 + 前置字元重新導向重新導向 http://any-host-name/originalPath 至 https://www.example.com/newPrefix/originalPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix"

下列部分程式碼片段會為每個 API 資源加上註解：

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

後續步驟

如要新增、驗證、測試、列出或刪除網址對應，請參閱「使用網址對應」。
如要瞭解 Cloud Service Mesh 的路由規則對應，請參閱「Cloud Service Mesh 路由規則對應總覽」。

網址對應總覽 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

網址對應的運作方式

負載平衡器命名

網址對應元件

主機名稱和主機規則關係

主機規則和路徑比對器關係

網址和後端關係

網址對應和通訊協定

最簡單的網址對應

作業順序

網址對應設定限制

主機和路徑規則中的規則運算式比對器

範例 1：使用規則運算式比對路徑

範例 2：使用規則運算式比對標頭

範例 3：使用規則運算式比對查詢參數

路徑規則和前置字串比對中的萬用字元、規則運算式和動態網址

路徑範本中的萬用字元和模式比對運算子 (適用於路徑規則)

外部應用程式負載平衡器的網址對應工作流程範例

網址重新導向

重新導向範例

後續步驟

網址對應總覽