外部應用程式負載平衡器簡介

本文將介紹設定外部應用程式負載平衡器時需瞭解的概念。

外部應用程式負載平衡器是以 Proxy 為基礎的第 7 層負載平衡器，可讓您透過單一外部 IP 位址執行服務及調度服務資源。外部應用程式負載平衡器會將 HTTP 和 HTTPS 流量分配給各種Google Cloud 平台 (例如 Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Storage) 上代管的後端，以及透過網際網路或混合式連線連線的外部後端。詳情請參閱「應用程式負載平衡器總覽：使用案例」。

運作模式

您可以透過下列模式設定外部應用程式負載平衡器：

• 全域外部應用程式負載平衡器。這是全球負載平衡器，在 Google Front Ends (GFE) 上以代管服務的形式實作。它使用開放原始碼的 Envoy Proxy，支援進階流量管理功能，例如流量鏡射、根據權重拆分流量，以及根據要求或回應轉換標頭。
• 傳統版應用程式負載平衡器。這是傳統外部應用程式負載平衡器，在進階級方案中屬於全域，但在標準級方案中可設定為區域性。這項負載平衡器是在 Google Front End (GFE) 上實作。GFE 遍布世界各地，透過 Google 的全球網路和控制層互相搭配運作。
• 區域性外部應用程式負載平衡器。這是區域負載平衡器，以開放原始碼 Envoy Proxy 的代管服務形式實作。包括進階流量管理功能，例如流量鏡射、根據權重拆分流量，以及根據要求或回應轉換標頭。

找出模式

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

架構

部署外部應用程式負載平衡器時，需要下列資源：

• 僅限區域性外部應用程式負載平衡器，系統會使用僅限 Proxy 的子網路，將連線從負載平衡器傳送至後端。

• 外部轉送規則會指定外部 IP 位址、通訊埠和目標 HTTP(S) Proxy。用戶端會使用 IP 位址和通訊埠連線至負載平衡器。

• 目標 HTTP(S) Proxy 會接收來自用戶端的要求。HTTP(S) Proxy 會使用網址對應評估要求，以決定流量轉送方式。Proxy 也可以使用 SSL 憑證驗證通訊。

  • 如果是 HTTPS 負載平衡，目標 HTTPS Proxy 會使用 SSL 憑證向用戶端證明自己的身分。目標 HTTPS Proxy 最多支援已記錄的 SSL 憑證數量。

• HTTP(S) Proxy 會使用網址對應，根據 HTTP 屬性 (例如要求路徑、Cookie 或標頭) 判斷轉送路徑。根據轉送決策，Proxy 會將用戶端要求轉送至特定後端服務或後端值區。網址對應表可以指定其他動作，例如將重新導向傳送給用戶端。

• 後端服務會將要求分配給健康狀態良好的後端。 全域外部應用程式負載平衡器也支援後端值區。一或多個後端必須連線至後端服務或後端值區。

• 健康狀態檢查會定期監控後端的完備性。這樣可降低要求傳送至無法處理要求的後端的風險。

• 後端接受健康狀態檢查探測器的防火牆規則。區域型外部應用程式負載平衡器需要額外的防火牆規則，才能允許流量從僅限 Proxy 的子網路傳送至後端。

全球

下圖顯示全域外部應用程式負載平衡器部署作業的元件。這項架構適用於進階級的全域外部應用程式負載平衡器和傳統版應用程式負載平衡器。

區域

這張圖表顯示區域性外部應用程式負載平衡器部署作業的元件。

Proxy 專用子網路

Proxy 專用子網路僅適用於區域性外部應用程式負載平衡器。

Google 會使用僅限 Proxy 的子網路提供的一組 IP 位址，代表您執行 Envoy Proxy。您必須在使用區域型外部應用程式負載平衡器的虛擬私有雲網路的每個區域中，建立一個僅限 Proxy 的子網路。這個僅限 Proxy 子網路的 --purpose 旗標已設為 REGIONAL_MANAGED_PROXY。位於相同區域和虛擬私有雲網路的所有區域 Envoy 型負載平衡器，都會共用來自相同 Proxy 專用子網路的 Envoy Proxy 集區。其他：

• 僅限 Proxy 的子網路只會用於 Envoy Proxy，不會用於後端。
• 區域和虛擬私有雲網路中，所有區域外部應用程式負載平衡器的後端 VM 或端點，都會從僅限 Proxy 的子網路接收連線。
• 區域外部應用程式負載平衡器的 IP 位址並非位於僅限 Proxy 的子網路。負載平衡器的 IP 位址是由外部管理的轉送規則所定義，詳情請參閱下文。

如果您先前使用 --purpose=INTERNAL_HTTPS_LOAD_BALANCER 建立僅限 Proxy 的子網路，請先將子網路的用途遷移至 REGIONAL_MANAGED_PROXY，才能在虛擬私有雲網路的相同區域中建立其他 Envoy 型負載平衡器。

轉送規則和 IP 位址

轉送規則會依 IP 位址、通訊埠和通訊協定，將流量轉送至由目標 Proxy、網址對應和一或多個後端服務所組成的負載平衡設定。

IP 位址規格。每個轉送規則都會提供一個 IP 位址，供您用於應用程式的 DNS 記錄。您不需要進行 DNS 型負載平衡。您可以指定要使用的 IP 位址，或由 Cloud Load Balancing 為您指派 IP 位址。

通訊埠規格。應用程式負載平衡器的每個轉送規則都可參照單一通訊埠 (1 至 65535)。如要支援多個通訊埠，必須設定多個轉送規則。只要每個轉送規則的 IP 位址、通訊埠和通訊協定組合不重複，您就可以設定多個轉送規則，使用相同的外部 IP 位址 (VIP) 並參照相同的目標 HTTP(S) Proxy。這樣一來，您就能使用共用網址對應的單一負載平衡器，做為多個應用程式的 Proxy。

外部應用程式負載平衡器使用的轉送規則類型、IP 位址和負載平衡配置，取決於負載平衡器的模式和負載平衡器所在的網路服務層級。

如要查看外部應用程式負載平衡器在各模式下轉送規則支援的完整通訊協定清單，請參閱負載平衡器功能。

轉送規則和虛擬私有雲網路

本節說明外部應用程式負載平衡器使用的轉送規則如何與虛擬私有雲網路建立關聯。

目標 Proxy

目標 Proxy 會終止來自用戶端的 HTTP(S) 連線。一或多個轉送規則會將流量導向至目標 Proxy，而目標 Proxy 會查詢網址對應，以決定如何將流量轉送至後端。

請勿依賴 Proxy 來維持要求或回應標頭名稱的大小寫。舉例來說，Server: Apache/1.0 回應標頭在用戶端位置可能會顯示為 server: Apache/1.0。

下表說明外部應用程式負載平衡器所需的目標 Proxy 類型。

除了目標 Proxy 新增的標頭，負載平衡器還會以以下方式調整其他 HTTP 標頭：

• 全域外部應用程式負載平衡器可能會將要求和回應標頭轉換為小寫。

  但使用 HTTP/1.1 的全域網際網路 NEG 後端是例外。如要瞭解如何使用全域網際網路 NEG 處理 HTTP/1.1 標頭，請參閱網際網路 NEG 總覽。

• 如果是傳統版應用程式負載平衡器，要求和回應標頭會轉換為小寫，但使用 HTTP/1.1 時除外。使用 HTTP/1.1 時，標頭會改為採用適當的大小寫格式。標頭鍵的第一個字母，以及連字號 (-) 後的每個字母都會大寫，以確保與 HTTP/1.1 用戶端相容。舉例來說，user-agent 會變更為 User-Agent，content-encoding 則會變更為 Content-Encoding。

• 部分標題已合併。如果出現多個相同標頭鍵 (例如 Via)，負載平衡器會將這些值合併為單一標頭鍵的半形逗號分隔清單。只有值可表示為以半形逗號分隔清單的標頭會合併。其他標頭 (例如 Set-Cookie) 則不會合併。

主機標頭

負載平衡器發出 HTTP 要求時，會保留原始要求的 Host 標頭。

X-Forwarded-For 標頭

負載平衡器會在 X-Forwarded-For 標頭中附加兩個 IP 位址，並以半形逗號分隔，順序如下：

1. 連線至負載平衡器的用戶端 IP 位址
2. 負載平衡器轉送規則的 IP 位址

如果傳入的要求未包含 X-Forwarded-For 標頭，產生的標頭如下：

X-Forwarded-For: <client-ip>,<load-balancer-ip>

如果傳入的要求已包含 X-Forwarded-For 標頭，負載平衡器會將值附加至現有標頭：

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

使用自訂要求標頭移除現有標頭值

您可以使用後端服務的自訂要求標頭，移除現有的標頭值。以下範例使用 --custom-request-header 標記，透過 client_ip_address 和 server_ip_address 變數重新建立 X-Forwarded-For 標頭。這項設定會取代傳入的 X-Forwarded-For 標頭，只保留用戶端和負載平衡器的 IP 位址。

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

後端反向 Proxy 軟體如何修改 X-Forwarded-For 標頭

如果負載平衡器的後端執行 HTTP 反向 Proxy 軟體，軟體可能會在 X-Forwarded-For 標頭結尾附加下列一或兩個 IP 位址：

1. 連線至後端的 GFE IP 位址。 GFE IP 位址位於 130.211.0.0/22 和 35.191.0.0/16 範圍。

2. 後端系統本身的 IP 位址。

因此，上游系統可能會看到結構如下的 X-Forwarded-For 標頭：

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Cloud Trace 支援

應用程式負載平衡器不支援追蹤。如果沒有 X-Cloud-Trace-Context 標頭，全域和傳統版應用程式負載平衡器會新增該標頭。區域性外部應用程式負載平衡器不會新增這個標頭。如果已存在 X-Cloud-Trace-Context 標頭，則會通過負載平衡器，且不會經過修改。不過，負載平衡器不會匯出任何追蹤記錄或範圍。

網址對應

網址對應會定義比對模式，這些模式可透過網址將要求轉送到合適的後端服務。網址對應可讓您透過檢查網址元件來劃分流量，以便將要求傳送到不同的後端組合。系統會定義預設服務來處理任何不符合指定主機規則或路徑比對規則的要求。

在某些情況下，例如在多區域負載平衡的範例中，您可能無法定義任何網址規則，而只能使用預設服務。

網址對應表支援多項進階流量管理功能，例如根據標頭導引流量、根據權重拆分流量，以及鏡射要求。如要瞭解詳情，請參考下列資源：

• 全域外部應用程式負載平衡器的流量管理總覽

• 區域性外部應用程式負載平衡器的流量管理總覽

下表說明外部應用程式負載平衡器在各模式中所需的網址對應類型。

SSL 憑證

使用目標 HTTPS Proxy 的外部應用程式負載平衡器需要私密金鑰和 SSL 憑證，才能完成負載平衡器設定。

• Google Cloud 提供兩種設定方法，可將私密金鑰和 SSL 憑證指派給目標 HTTPS Proxy：Compute Engine SSL 憑證和 Certificate Manager。如要瞭解各項設定，請參閱 SSL 憑證總覽中的「憑證設定方法」。

• Google Cloud 提供兩種憑證類型：自行管理和 Google 代管。如要瞭解各類型憑證，請參閱 SSL 憑證總覽中的「憑證類型」。

外部應用程式負載平衡器的類型 (全域、區域或傳統版) 會決定支援的設定方法和憑證類型。詳情請參閱安全資料傳輸層 (SSL) 憑證總覽中的「憑證和負載平衡器」一節。 Google Cloud

安全資料傳輸層 (SSL) 政策

SSL 政策會指定 Google Cloud 負載平衡器與用戶端交涉 SSL 時使用的 SSL 功能組合。

根據預設，HTTPS 負載平衡會使用一組提供良好安全性和廣泛相容性的 SSL 功能。有些應用程式需要進一步控制 HTTPS 或 SSL 連線使用的 SSL 版本和加密方式。您可以定義 SSL 政策，指定負載平衡器與用戶端交涉 SSL 時使用的 SSL 功能組合。此外，您也可以將該 SSL 政策套用至目標 HTTPS Proxy。

下表列出各模式中負載平衡器的 SSL 政策支援。

後端服務

後端服務會將設定資訊提供給負載平衡器，以便將要求導向至後端，例如 Compute Engine 執行個體群組或網路端點群組 (NEG)。如要進一步瞭解後端服務，請參閱後端服務總覽。

如需範例，瞭解如何設定具有後端服務和 Compute Engine 後端的負載平衡器，請參閱「使用 Compute Engine 後端設定外部應用程式負載平衡器」。

後端服務範圍

下表說明外部應用程式負載平衡器使用的後端服務資源和範圍：

後端的通訊協定

應用程式負載平衡器的後端服務必須使用下列其中一種通訊協定，將要求傳送至後端：

• HTTP，使用 HTTP/1.1 且不使用 TLS
• HTTPS，使用 HTTP/1.1 和 TLS
• HTTP/2，使用 HTTP/2 和 TLS (系統不支援未加密的 HTTP/2)。
• H2C：透過 TCP 使用 HTTP/2。不需要傳輸層安全標準 (TLS)。傳統版應用程式負載平衡器不支援 H2C。

負載平衡器只會使用您指定的後端服務通訊協定，與後端通訊。如果負載平衡器無法使用指定的後端服務通訊協定與後端通訊，將不會改回使用其他通訊協定。

後端服務通訊協定不必與用戶端用來與負載平衡器通訊的通訊協定相符。舉例來說，用戶端可以使用 HTTP/2 將要求傳送至負載平衡器，但負載平衡器可以使用 HTTP/1.1 (HTTP 或 HTTPS) 與後端通訊。

後端值區

後端值區會將傳入流量導向至 Cloud Storage 值區。如需示範如何將值區新增到外部應用程式負載平衡器的範例，請參閱設定具有後端值區的負載平衡器。如要瞭解 Cloud Storage 的一般資訊，請參閱「什麼是 Cloud Storage？」一文。

後端

下表列出外部應用程式負載平衡器在各模式下支援的後端和相關功能。

後端和虛擬私有雲網路

後端所在位置的限制取決於負載平衡器類型。

全域外部應用程式負載平衡器後端適用下列規定：

• 後端執行個體 (適用於執行個體群組後端) 和後端端點 (適用於 NEG 後端) 可位於同一機構內的任何 VPC 網路。不同的虛擬私有雲網路不需要使用虛擬私有雲網路對等互連連線，因為 GFE 會直接與各自虛擬私有雲網路中的後端通訊。

• Cloud Storage 值區不會與虛擬私有雲網路建立關聯。這些專案可位於同一機構內的任何專案中。

  全域外部應用程式負載平衡器也支援共用 VPC 環境，您可以在專案之間共用 VPC 網路和相關聯的資源。不過，如果是全域外部應用程式負載平衡器，您不需要設定共用虛擬私有雲，就能從貴機構的其他專案參照後端服務或後端儲存空間。

傳統版應用程式負載平衡器後端適用下列規定：

• 執行個體群組後端的所有後端執行個體，以及 NEG 後端的所有後端端點，都必須位於同一個專案。不過，執行個體群組後端或 NEG 可以在該專案中使用不同的虛擬私有雲網路。不同的虛擬私有雲網路不需要透過虛擬私有雲網路對等互連連線，因為 GFE 會直接與各自虛擬私有雲網路中的後端通訊。

• Cloud Storage 值區不會與虛擬私有雲網路建立關聯。不過，這些節點必須與負載平衡器位於相同專案。

區域性外部應用程式負載平衡器後端適用下列規定：

• 對於執行個體群組、區域 NEG 和混合式連線 NEG，所有後端都必須與後端服務位於相同的專案和區域。不過，負載平衡器可以參照使用不同 VPC 網路的後端，但必須與後端服務位於同一專案。 您可以使用虛擬私有雲網路對等互連、Cloud VPN 通道、Cloud Interconnect VLAN 連結或 Network Connectivity Center 架構，設定負載平衡器虛擬私有雲網路與後端虛擬私有雲網路之間的連線。

  後端網路定義

  • 對於區域 NEG 和混合式 NEG，您在建立 NEG 時會明確指定虛擬私有雲網路。
  • 如果是代管執行個體群組，虛擬私有雲網路是在執行個體範本中定義。
  • 對於非代管執行個體群組，系統會將執行個體群組的虛擬私有雲網路設為與新增至執行個體群組的第一個 VM 的 nic0 介面虛擬私有雲網路相符。

  後端網路需求

  後端的網路必須符合下列任一網路需求：

  • 後端的虛擬私有雲網路必須與轉送規則的虛擬私有雲網路完全相符。

  • 後端的虛擬私有雲網路必須使用虛擬私有雲網路對等互連，連線至轉送規則的虛擬私有雲網路。您必須設定子網路路徑交換，允許轉送規則虛擬私有雲網路中的僅限 Proxy 子網路，與後端執行個體或端點使用的子網路進行通訊。

• 後端的 VPC 網路和轉送規則的 VPC 網路都必須是VPC 輪輻，且附加至相同的 Network Connectivity Center 中樞。匯入和匯出篩選器必須允許轉送規則的 VPC 網路中僅限 Proxy 的子網路，與後端執行個體或端點使用的子網路進行通訊。

• 如果是其他後端類型，所有後端都必須位於同一個虛擬私有雲網路和區域。

  區域外部應用程式負載平衡器也支援共用 VPC 環境，您可以在專案之間共用 VPC 網路和相關聯的資源。如要讓區域外部應用程式負載平衡器的後端服務和後端位於與轉送規則不同的專案中，您需要在共用虛擬私有雲環境中設定負載平衡器，並進行跨專案服務參照。

後端和網路介面

如果您使用執行個體群組後端，封包一律會傳送至 nic0。如要將封包傳送至非 nic0 介面 (vNIC 或動態網路介面)，請改用 NEG 後端。

如果您使用區域 NEG 後端，封包會傳送至 NEG 中端點所代表的任何網路介面。NEG 端點必須與 NEG 明確定義的 VPC 網路位於同一個 VPC 網路。

健康狀態檢查

每個後端服務都會指定健康狀態檢查，定期監控後端是否已準備好接收來自負載平衡器的連線。這樣可降低要求傳送至無法處理要求的後端的風險。健康狀態檢查不會檢查應用程式本身是否正常運作。

對於健康狀態檢查探測器，您必須建立允許輸入的防火牆規則，讓健康狀態檢查探測器可連線至後端執行個體。健康狀態檢查探測通常來自 Google 的集中式健康狀態檢查機制。

使用混合式 NEG 後端的區域外部應用程式負載平衡器是這項規則的例外狀況，因為這類負載平衡器的健康狀態檢查是從 Proxy 專用子網路發出，詳情請參閱混合型 NEG 總覽。

健康狀態檢查通訊協定

雖然這並非必要，也不一定都可行，但最佳做法是使用通訊協定與後端服務通訊協定相符的健康狀態檢查。舉例來說，HTTP/2 健康狀態檢查最能準確測試與後端的 HTTP/2 連線。相較之下，使用混合式 NEG 後端的區域性外部應用程式負載平衡器不支援 gRPC 健康狀態檢查。如需支援的健康狀態檢查通訊協定清單，請參閱「負載平衡功能」。

下表說明外部應用程式負載平衡器在各模式下支援的健康狀態檢查範圍。

如要進一步瞭解健康狀態檢查，請參閱下列文章：

• 健康狀態檢查總覽
• 建立健康狀態檢查

防火牆規則

負載平衡器需要下列防火牆規則：

• 如果是全域外部應用程式負載平衡器，請設定允許輸入的規則，允許流量從 Google Front End (GFE) 傳送至後端。 如果是區域外部應用程式負載平衡器，請設定允許輸入的規則，允許流量從僅限 Proxy 的子網路傳送至後端。
• 輸入允許規則，允許來自健康狀態檢查探測範圍的流量。如要進一步瞭解健康狀態檢查探測，以及為何必須允許來自這些探測的流量，請參閱「探測 IP 範圍和防火牆規則」。

防火牆規則是在 VM 執行個體層級實作，而非在 GFE Proxy 上實作。您 Google Cloud 無法使用 防火牆規則，防止流量抵達負載平衡器。如果是全域外部應用程式負載平衡器和傳統版應用程式負載平衡器，則可使用 Google Cloud Armor 達成此目的。

這些防火牆規則的通訊埠必須設定如下：

• 允許流量前往各後端服務健康狀態檢查的目的地通訊埠。

• 如果是執行個體群組後端：請根據後端服務的已命名通訊埠與每個執行個體群組中與該已命名通訊埠相關聯的通訊埠編號之間的對應關係，判斷要設定的通訊埠。指派給相同後端服務的執行個體群組，其連接埠號碼可能有所不同。

• 如果是 GCE_VM_IP_PORT NEG 後端：允許流量傳送至端點的通訊埠編號。

下表摘要說明防火牆規則所需的來源 IP 位址範圍：

GKE 支援

GKE 會透過下列方式使用外部應用程式負載平衡器：

• 使用 GKE Gateway 控制器建立的外部閘道，可以使用外部應用程式負載平衡器的任何模式。您可以選擇 GatewayClass，控管負載平衡器的模式。GKE Gateway 控制器一律使用 GCE_VM_IP_PORT 地區 NEG 後端。

• 使用 GKE Ingress 控制器建立的外部 Ingress 一律為傳統應用程式負載平衡器。GKE Ingress 控制器偏好使用GCE_VM_IP_PORT區域性 NEG 後端，但同時也支援執行個體群組後端。

• 您可以將 GKE 服務建立及管理的GCE_VM_IP_PORT區域 NEG，做為任何應用程式負載平衡器或 Proxy 網路負載平衡器的後端。詳情請參閱透過獨立的區域 NEG 使用容器原生負載平衡。

共用 VPC 架構

外部應用程式負載平衡器支援使用共用虛擬私有雲的網路。共用虛擬私有雲可讓機構將多項專案的資源連線至共同的虛擬私有雲網路，以便透過該網路中的內部 IP 位址，安全高效地相互通訊。如果您還不熟悉共用虛擬私有雲，請參閱 共用虛擬私有雲總覽。

在共用 VPC 網路中，設定外部應用程式負載平衡器的方法有很多種。無論部署類型為何，負載平衡器的所有元件都必須位於同一個機構中。

雖然您可以在共用 VPC 主專案中建立所有負載平衡元件和後端，但這類部署作業不會區隔網路管理和服務開發職責。

服務專案中的所有負載平衡器元件和後端

下圖顯示標準的共用虛擬私有雲部署作業，其中所有負載平衡器元件和後端都位於服務專案中。所有應用程式負載平衡器都支援這類部署作業。

負載平衡器元件和後端必須使用相同的虛擬私有雲網路。

共用虛擬私有雲環境中的無伺服器後端

如果負載平衡器使用無伺服器 NEG 後端，後端 Cloud Run 或 Cloud Run functions 服務必須與無伺服器 NEG 位於同一個專案。

此外，對於支援跨專案服務參照的區域外部應用程式負載平衡器，後端服務、無伺服器 NEG 和 Cloud Run 服務一律須位於同一個服務專案中。

跨專案參照服務

跨專案服務參照是一種部署模式，負載平衡器的前端和網址對應位於一個專案中，負載平衡器的後端服務和後端則位於另一個專案中。

機構可以透過跨專案服務參照功能，設定一個中央負載平衡器，並將流量轉送至分散在多個不同專案中的數百項服務。您可以在一個網址對應中集中管理所有流量轉送規則和政策。您也可以將負載平衡器與一組主機名稱和 SSL 憑證建立關聯。因此，您可以視需要調整部署應用程式所需的負載平衡器數量，並降低可管理性、營運成本和配額需求。

為每個職能團隊建立不同的專案，也有助於在機構內區分角色。服務擁有者可以專注於在服務專案中建構服務，而網路團隊則可在另一個專案中佈建及維護負載平衡器，兩者可透過跨專案服務參照功能連結。

服務擁有者可透過負載平衡器，自主控管服務曝光度，並決定哪些使用者可以存取服務。這項作業是透過名為「Compute Load Balancer Services User」的特殊 IAM 角色 (roles/compute.loadBalancerServiceUser) 達成。

跨專案服務參照支援功能會因負載平衡器類型而異：

• 全域外部應用程式負載平衡器：負載平衡器的前端和網址對應可以參照同一機構內任何專案的後端服務或後端 bucket。沒有虛擬私有雲網路限制。雖然您可以使用共用虛擬私有雲環境設定跨專案部署，如本範例所示，但這並非必要條件。

• 區域性外部應用程式負載平衡器：您必須在共用 VPC 環境中建立負載平衡器。負載平衡器的前端和網址對應表必須位於主專案或服務專案中，負載平衡器的後端服務和後端則可分散在同一個共用虛擬私有雲環境的主專案或服務專案中。

如要瞭解如何為區域外部應用程式負載平衡器設定共用 VPC (包括使用跨專案服務參照和不使用跨專案服務參照)，請參閱「使用共用 VPC 設定區域外部應用程式負載平衡器」。

跨專案服務參照的使用注意事項

• 跨專案服務參照可與執行個體群組、無伺服器 NEG 和大多數其他支援的後端類型搭配使用。但請注意，本功能有以下限制：

  • 如果後端服務具有 App Engine 的無伺服器 NEG 後端，您就無法使用全域外部應用程式負載平衡器，參照跨專案後端服務。

  • 使用區域性外部應用程式負載平衡器時，如果後端服務具有區域性網際網路 NEG 後端，您就無法參照跨專案後端服務。
• 傳統版應用程式負載平衡器不支援跨專案服務參照。
• Google Cloud 不會區分多個專案中名稱相同的資源 (例如後端服務)。因此，使用跨專案服務參照時，建議您在機構的專案中使用不重複的後端服務名稱。
• 如果看到「Cross-project references for this resource are not allowed」(不允許這項資源的跨專案參照) 等錯誤訊息，請確認您有權使用該資源。資源所屬專案的管理員必須授予您Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser)。這項角色可在專案層級或資源層級授予。如需範例，請參閱授予 Compute Load Balancer 管理員使用後端服務或後端值區的權限。

範例 1：負載平衡器的前端和後端位於不同的服務專案

以下是共用虛擬私有雲部署作業的範例，其中負載平衡器的前端和網址對應是在服務專案 A 中建立，而網址對應則參照服務專案 B 中的後端服務。

在本例中，服務專案 A 中的網路管理員或負載平衡器管理員需要存取服務專案 B 中的後端服務。服務專案 B 管理員將 Compute Load Balancer Services User 角色 (roles/compute.loadBalancerServiceUser) 授予服務專案 A 中的負載平衡器管理員，讓他們參照服務專案 B 中的後端服務。

示例 2：主專案中的負載平衡器前端，以及服務專案中的後端

以下是共用虛擬私有雲部署範例，其中負載平衡器的前端和網址對應是在主專案中建立，後端服務 (和後端) 則是在服務專案中建立。

在這個案例中，主專案中的網路管理員或負載平衡器管理員需要存取服務專案中的後端服務。服務專案管理員將 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser) 授予主專案 A 中的負載平衡器管理員，讓他們參照服務專案中的後端服務。

範例 3：負載平衡器前端和後端位於不同專案

以下是部署範例，其中全域外部應用程式負載平衡器的前端和網址對應，是在與負載平衡器後端服務和後端不同的專案中建立。這類部署作業不會使用共用 VPC，且僅適用於全域外部應用程式負載平衡器。

如要進一步瞭解這項設定，請參閱使用後端服務和後端值區設定跨專案服務參照。

高可用性和容錯移轉

您可以在負載平衡器層級設定外部應用程式負載平衡器的高可用性和容錯移轉功能。如要處理這類情況，請在需要備份的任何區域中，建立備份區域性外部應用程式負載平衡器。

下表說明容錯移轉行為。

支援 HTTP/2

HTTP/2 是 HTTP/1 通訊協定的重大修訂版本。HTTP/2 支援有 2 種模式：

• 透過 TLS 的 HTTP/2
• 透過 TCP 傳輸的明文 HTTP/2

透過 TLS 的 HTTP/2

系統支援透過 TLS 的 HTTP/2，用於用戶端與外部應用程式負載平衡器之間的連線，以及負載平衡器與後端之間的連線。

負載平衡器會使用 ALPN TLS 擴充功能，在 TLS 握手過程中與用戶端進行 HTTP/2 交涉。即使負載平衡器已設定為使用 HTTPS，現代的用戶端預設為使用 HTTP/2。這是在用戶端上控制的，而不是在負載平衡器上控制的。

如果用戶端不支援 HTTP/2，且負載平衡器已設定為在負載平衡器和後端執行個體之間使用 HTTP/2，負載平衡器可能仍會交涉 HTTPS 連線或接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTPS 或 HTTP 要求，以透過 HTTP/2 經由 Proxy 將要求傳送至後端執行個體。

如要透過 TLS 使用 HTTP/2，您必須在後端啟用 TLS，並將後端服務通訊協定設為HTTP2。詳情請參閱「從負載平衡器到後端的加密」一文。

HTTP/2 並行串流數量上限

HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS 設定說明端點接受的串流數量上限 (由對等互連啟動)。HTTP/2 用戶端向Google Cloud 負載平衡器宣傳的值實際上沒有意義，因為負載平衡器不會向用戶端啟動串流。

如果負載平衡器使用 HTTP/2 與在 VM 上執行的伺服器通訊，負載平衡器會遵守伺服器通告的 SETTINGS_MAX_CONCURRENT_STREAMS 值，但不得超過 100 的最大值。在要求方向 (Google Cloud 負載平衡器 → gRPC 伺服器) 中，負載平衡器會使用 gRPC 伺服器的初始 SETTINGS 框架，判斷每個連線可同時使用的串流數量。如果伺服器宣傳的值高於 100，負載平衡器會將並行串流數量上限設為 100。如果宣傳的值為零，負載平衡器就無法將要求轉送至伺服器，這可能會導致錯誤。

HTTP/2 動態標頭表大小

HTTP/2 具備多工處理和 HPACK 標頭壓縮等功能，大幅改善 HTTP/1.1。HPACK 使用動態資料表來強化標頭壓縮功能，進而加快所有作業的速度。如要瞭解動態標頭表格大小變更對 HTTP/2 的影響、這項功能如何提升效能，以及各種 HTTP 用戶端程式庫中的特定錯誤如何導致 HPACK 標頭壓縮發生問題，請參閱社群文章。

HTTP/2 限制

• 負載平衡器和執行個體之間的 HTTP/2 可能需要比 HTTP 或 HTTPS 多出許多連往執行個體的 TCP 連線。HTTP/2 不支援連線集區化 (這項最佳化功能可減少 HTTP 或 HTTPS 的連線數量)。因此，後端連線的頻率可能會提高，導致後端延遲時間較長。
• 負載平衡器與後端之間的 HTTP/2 不支援透過 HTTP/2 連線的單一串流執行 WebSocket 通訊協定 (RFC 8441)。
• 負載平衡器與後端之間的 HTTP/2 不支援伺服器推送。
• 您無法在Google Cloud API 或 Google Cloud 控制台中查看 gRPC 錯誤率和要求量。如果 gRPC 端點傳回錯誤，負載平衡器記錄檔和監控資料會回報 200 OK HTTP 狀態碼。

透過 TCP 的明文 HTTP/2 (H2C)

透過 TCP 的明文 HTTP/2 (也稱為 H2C) 可讓您使用 HTTP/2，不必使用 TLS。以下兩種連線都支援 H2C：

• 用戶端與負載平衡器之間的連線。無須進行特殊設定。

• 負載平衡器與後端之間的連線。

  如要為負載平衡器與後端之間的連線設定 H2C，請將後端服務通訊協定設為 H2C。

使用 GKE Gateway 控制器和 Cloud Service Mesh 建立的負載平衡器，也支援 H2C。

傳統版應用程式負載平衡器不支援 H2C。

支援 HTTP/3

HTTP/3 是新一代網際網路通訊協定，這項通訊協定是以 IETF QUIC 為基礎建構，並從原始的 Google QUIC 通訊協定開發而來。外部應用程式負載平衡器、Cloud CDN 和用戶端之間支援 HTTP/3。

具體情況如下：

• IETF QUIC 是一種傳輸層通訊協定，提供類似 TCP 的擁塞控制和可靠性，使用 TLS 1.3 確保安全性，並提升效能。
• HTTP/3 是以 IETF QUIC 為基礎建構的應用程式層，並依賴 QUIC 處理多工處理、壅塞控制、遺失偵測和重新傳輸。
• HTTP/3 可加快用戶端連線的啟動速度、避免多工串流發生隊頭阻塞問題，並且可在用戶端的 IP 位址變更時支援連線遷移。
• HTTP/3 支援用戶端與負載平衡器之間的連線，但不支援負載平衡器與後端之間的連線。
• HTTP/3 連線使用 BBR 壅塞控制演算法。

負載平衡器上的 HTTP/3 可縮短網頁載入時間、減少影片重新緩衝處理次數，並提高高延遲連線的處理量。

下表列出各模式中，外部應用程式負載平衡器對 HTTP/3 的支援情況。

HTTP/3 的交涉方式

啟用 HTTP/3 後，負載平衡器會向用戶端公告這項支援，允許支援 HTTP/3 的用戶端嘗試與 HTTPS 負載平衡器建立 HTTP/3 連線。

• 正確實作的用戶端若無法建立 HTTP/3 連線，一律會改回使用 HTTPS 或 HTTP/2。
• 支援 HTTP/3 的用戶端會使用先前快取的 HTTP/3 支援資訊，避免日後不必要的往返行程。
• 由於有這樣的備用機制，所以在負載平衡器中啟用或停用 HTTP/3 將不會破壞負載平衡器連線到用戶端的能力。

支援項目會顯示在 Alt-Svc HTTP 回應標頭中。啟用 HTTP/3 後，負載平衡器的回應會包含下列 alt-svc 標頭值：

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

如果已明確將 HTTP/3 設為 DISABLE，回應就不會包含 alt-svc 回應標頭。

在 HTTPS 負載平衡器中啟用 HTTP/3 後，某些情況可能導致用戶端改回使用 HTTPS 或 HTTP/2，而不是進行 HTTP/3 交涉。其中包括：

• 用戶端支援的 HTTP/3 版本與 HTTPS 負載平衡器支援的 HTTP/3 版本不相容。
• 負載平衡器偵測到 UDP 流量遭到封鎖或速率受限，且這樣的封鎖或限制會導致 HTTP/3 無法運作。
• 用戶端完全不支援 HTTP/3，因此不會嘗試協商 HTTP/3 連線。

當連線改回使用 HTTPS 或 HTTP/2 時，我們不會將此視為負載平衡器失敗。

啟用 HTTP/3 前，請確認您的工作負載可接受上述行為。

設定 HTTP/3

NONE (預設) 和 ENABLE 都會為負載平衡器啟用 HTTP/3 支援功能。

啟用 HTTP/3 後，負載平衡器會向用戶端公告，允許支援 HTTP/3 的用戶端與負載平衡器交涉 HTTP/3 版本。不支援 HTTP/3 的用戶端不會交涉 HTTP/3 連線。除非您發現用戶端實作項目有問題，否則不需要明確停用 HTTP/3。

外部應用程式負載平衡器提供三種方式來設定 HTTP/3，如下表所示。

如要明確啟用 (或停用) HTTP/3，請按照下列步驟操作。

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

WebSocket 支援

Google Cloud 使用 HTTP 或 HTTPS 做為後端通訊協定時，HTTP(S) 型負載平衡器支援 WebSocket 通訊協定。負載平衡器不需要任何設定，即可透過 Proxy 進行 WebSocket 連線。

WebSocket 通訊協定會在用戶端和負載平衡器之間提供全雙工通訊管道。詳情請參閱 RFC 6455。

WebSocket 通訊協定的運作方式如下：

1. 負載平衡器會辨識來自 HTTP 或 HTTPS 用戶端的 WebSocket Upgrade 要求。要求包含 Connection: Upgrade 和 Upgrade: websocket 標頭，後面接著其他相關的 WebSocket 相關要求標頭。
2. 後端傳送 WebSocket Upgrade 回應。後端執行個體會傳送 101 switching protocol 回應，其中包含 Connection: Upgrade 和 Upgrade: websocket 標頭，以及其他與 WebSocket 相關的回應標頭。
3. 在目前連線期間，負載平衡器會 Proxy 雙向流量。

如果後端執行個體傳回狀態碼 426 或 502，負載平衡器就會關閉連線。

Websocket 的工作階段相依性與任何其他要求相同。 詳情請參閱工作階段相依性。

gRPC 支援

gRPC 是遠端程序呼叫的開放原始碼架構，它採用 HTTP/2 標準。gRPC 的用途如下：

• 低延遲、高擴充性的分散式系統
• 開發與雲端伺服器通訊的行動用戶端
• 設計必須精確、有效且無關語言的新通訊協定
• 可實現擴充、驗證和記錄功能的分層式設計

如要將 gRPC 與 Google Cloud 應用程式搭配使用，端到端皆必須透過 HTTP/2 經由 Proxy 傳送要求。如要執行這項操作，請建立應用程式負載平衡器，並採用下列其中一種設定：

• 適用於端對端未加密流量 (不含 TLS)：建立 HTTP 負載平衡器 (已設定目標 HTTP Proxy)。此外，您也可以將後端服務通訊協定設為 H2C，將負載平衡器設為使用 HTTP/2，在負載平衡器與後端之間建立未加密的連線。

• 如要使用 TLS 進行端對端加密流量：請建立 HTTPS 負載平衡器 (已設定目標 HTTPS Proxy 和 SSL 憑證)。負載平衡器會使用 ALPN TLS 擴充功能，在 SSL 握手過程中與用戶端進行 HTTP/2 交涉。

  此外，您必須確保後端可以處理 TLS 流量，並將後端服務通訊協定設為 HTTP2，以便設定負載平衡器，在負載平衡器與後端之間使用 HTTP/2 進行加密連線。

  負載平衡器可能仍會與某些用戶端進行 HTTPS 交涉，或在設定為在負載平衡器和後端執行個體之間使用 HTTP/2 的負載平衡器上接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTP 或 HTTPS 要求，以透過 HTTP/2 經由 Proxy 將要求傳送至後端執行個體。

如要使用 HTTP/2 搭配 Google Kubernetes Engine Ingress 設定應用程式負載平衡器，或使用 gRPC 和 HTTP/2 搭配 Ingress 設定應用程式負載平衡器，請參閱用於與 Ingress 進行負載平衡的 HTTP/2。

如要使用 HTTP/2 搭配 Cloud Run 設定外部應用程式負載平衡器，請參閱「在負載平衡器後方使用 HTTP/2」。

如要瞭解如何排除 HTTP/2 問題，請參閱「排除後端的 HTTP/2 問題」一文。

如要瞭解 HTTP/2 的限制，請參閱 HTTP/2 限制。

TLS 支援

根據預設，HTTPS 目標 Proxy 在終止用戶端 SSL 要求時，只接受 TLS 1.0、1.1、1.2 和 1.3。

當傳統版應用程式負載平衡器使用 HTTPS 做為後端服務通訊協定時，就可以與後端進行 TLS 1.0、1.1、1.2 或 1.3 交涉。

支援雙向傳輸層安全標準 (TLS)

相互傳輸層安全標準 (mTLS) 是業界標準通訊協定，用於用戶端和伺服器之間的相互驗證。mTLS 會驗證用戶端和伺服器是否持有受信任的憑證授權單位 (CA) 核發的有效憑證，確保雙方相互驗證。標準 TLS 只會驗證伺服器，但 mTLS 要求用戶端和伺服器都必須出示憑證，確認雙方身分後才能建立通訊。

所有應用程式負載平衡器都支援 mTLS。使用 mTLS 時，負載平衡器會在與用戶端進行 TLS 握手期間，要求用戶端傳送憑證來驗證自身。您可以設定憑證管理工具信任儲存區，負載平衡器隨後會使用該儲存區驗證用戶端憑證的信任鏈。

如要進一步瞭解 mTLS，請參閱相互傳輸層安全標準 (mTLS) 驗證。

支援 TLS 1.3 早期資料

下列外部應用程式負載平衡器的目標 HTTPS Proxy 支援 TLS 1.3 早期資料，適用於透過 TCP 的 HTTPS (HTTP/1.1、HTTP/2) 和透過 QUIC 的 HTTP/3：

• 全域外部應用程式負載平衡器
• 傳統版應用程式負載平衡器

傳輸層安全標準 (TLS) 1.3 定義於 RFC 8446，並導入早期資料的概念，又稱為零往返時間 (0-RTT) 資料，可將恢復連線的應用程式效能提升 30% 至 50%。

使用 TLS 1.2 時，必須往返兩次，資料才能安全傳輸。TLS 1.3 可將新連線的往返次數減少至一次 (1-RTT)，讓用戶端在收到伺服器的第一個回應後，立即傳送應用程式資料。此外，TLS 1.3 為續傳工作階段導入早期資料的概念，讓用戶端能透過初始 ClientHello 傳送應用程式資料，進而將有效往返時間縮短至零 (0-RTT)。TLS 1.3 早期資料可讓後端伺服器在與用戶端完成交握程序前，開始處理用戶端資料，進而減少延遲時間；不過，請務必採取防範措施，降低重播攻擊風險。

由於早期資料是在交握完成前傳送，攻擊者可能會嘗試擷取及重送要求。為減輕這種情況，後端伺服器必須謹慎控管早期資料用量，僅限用於等冪要求。如果 HTTP 方法預期是冪等，但可能會觸發非冪等變更 (例如修改資料庫的 GET 要求)，則不得接受早期資料。在這種情況下，後端伺服器必須傳回 HTTP 425 Too Early 狀態碼，拒絕含有 HTTP Early-Data: 1 標頭的要求。

含有早期資料的要求會將 HTTP Early-Data 標頭設為 1 值，向後端伺服器指出要求已在 TLS 早期資料中傳送。這也表示用戶端瞭解 HTTP 425 Too Early 狀態碼。

TLS 早期資料 (0-RTT) 模式

您可以在負載平衡器的目標 HTTPS Proxy 資源上，使用下列其中一種模式設定 TLS 早期資料。

• STRICT。這會針對使用安全 HTTP 方法 (GET、HEAD、OPTIONS、TRACE) 的要求，以及不含查詢參數的 HTTP 要求，啟用 TLS 1.3 早期資料。如果要求傳送的早期資料包含非冪等 HTTP 方法 (例如 POST 或 PUT)，或含有查詢參數，系統會拒絕要求並傳回 HTTP 425 狀態碼。

• PERMISSIVE。這會針對使用安全 HTTP 方法 (GET、HEAD、OPTIONS、TRACE) 的要求啟用 TLS 1.3 早期資料。這個模式不會拒絕包含查詢參數的要求。應用程式擁有者必須確保每個要求路徑都能安全使用早期資料，特別是要求重播可能會導致非預期副作用的端點，例如 GET 要求觸發的記錄或資料庫更新。

• DISABLED。系統不會通告 TLS 1.3 早期資料，並拒絕所有 (無效) 嘗試傳送早期資料的要求。如果應用程式無法安全處理早期資料要求，請務必停用早期資料。TLS 1.3 早期資料預設為停用。

• UNRESTRICTED (不建議用於大多數工作負載)。這項設定會啟用 TLS 1.3 早期資料，供採用任何 HTTP 方法 (包括 POST 等非冪等方法) 的要求使用。這個模式不會強制執行任何其他限制。 這個模式對於 gRPC 用途來說很有價值。不過，除非您已評估安全狀況，並使用其他機制降低重播攻擊的風險，否則不建議採用這種方法。

設定 TLS 早期資料

如要明確啟用或停用 TLS 早期資料，請按照下列步驟操作：

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

設定 TLS 早期資料後，您就可以從支援 TLS 早期資料的 HTTP 用戶端發出要求。您會發現恢復的要求延遲時間較短。

如果用戶端不符合 RFC 規範，並傳送含有非等冪方法或查詢參數的要求，系統會拒絕該要求。您會在負載平衡器記錄檔中看到 HTTP 425 Early 狀態碼，以及下列 HTTP 回應：

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

限制

• HTTPS 負載平衡器終止 SSL 連線時，不會傳送 close_notify 關閉警示。也就是說，負載平衡器會關閉 TCP 連線，而不是執行 SSL 關機。

• HTTPS 負載平衡器僅支援憑證的通用名稱 (CN) 屬性或主體別名 (SAN) 屬性中的網域使用小寫字元。只有在目標 Proxy 中設為主要憑證時，系統才會傳回網域中含有大寫字元的憑證。

• 除了採用網際網路 NEG 後端的負載平衡器以外，HTTPS 負載平衡器不會使用伺服器名稱指示 (SNI) 擴充功能連線至後端。詳情請參閱「從負載平衡器到後端的加密」。

• Google Cloud 無法保證基礎 TCP 連線在後端服務逾時值的整個期間內保持開啟。用戶端系統必須實作重試邏輯，而不是依賴長時間開啟的 TCP 連線。

• 使用Google Cloud 控制台在進階級別中建立區域外部應用程式負載平衡器時，控制台只會顯示支援標準級別的區域。 Google Cloud 如要存取其他區域，請使用 gcloud CLI 或 API。

• 全域和傳統版應用程式負載平衡器使用的 GFE Proxy 不支援早期 200 OK 回應，也就是在要求 POST 酬載完全 Proxy 至後端之前傳送的回應。傳送早期 200 OK 回應會導致 GFE 關閉與後端的連線。

  後端必須在收到要求標頭後，以 100 Continue 回應，然後等待要求 POST 酬載完全經過 Proxy 處理，再以最終 200 OK 回應代碼回應。

• 在共用虛擬私有雲環境中，使用區域外部應用程式負載平衡器搭配 Cloud Run 時，服務專案中的獨立虛擬私有雲網路可將流量傳送至同一個共用虛擬私有雲環境中，部署在任何其他服務專案的 Cloud Run 服務。這是已知問題。

• Cloud CDN 可讓您要求快取失效，強制快取忽略一或多個物件。使用共用虛擬私有雲跨專案服務參照時，服務專案管理員預設不會有權限要求快取失效。這是因為快取失效設定是在前端專案中設定 (也就是具有負載平衡器轉送規則、目標 Proxy 和網址對應的專案)。因此，只有在前端專案中具有 IAM 角色，可設定負載平衡器相關資源的主體 (例如 Compute 網路管理員角色)，才能發出快取失效要求。服務管理員負責在另一個專案中控管後端服務的佈建作業，因此必須與前端專案的負載平衡器管理員合作，為跨專案服務發布快取失效要求。

後續步驟

• 如要瞭解外部應用程式負載平衡器如何處理連線、轉送流量及維持工作階段親和性，請參閱外部應用程式負載平衡器的要求分配。

• 如要瞭解如何部署全域外部應用程式負載平衡器，請參閱「設定後端為 Compute Engine 的外部應用程式負載平衡器」。

• 如要瞭解如何部署區域外部應用程式負載平衡器，請參閱使用 Compute Engine 後端設定區域外部應用程式負載平衡器。

• 如果您是傳統版應用程式負載平衡器的現有使用者，請務必在規劃使用全域外部應用程式負載平衡器的新部署作業時，查看遷移作業總覽。

• 如要瞭解如何使用 Terraform 自動設定外部應用程式負載平衡器，請參閱外部應用程式負載平衡器的 Terraform 模組範例。

• 如要瞭解如何設定全域外部應用程式負載平衡器提供的進階流量管理功能，請參閱全域外部應用程式負載平衡器的流量管理總覽。

• 如要瞭解如何設定區域性外部應用程式負載平衡器提供的進階流量管理功能，請參閱區域性外部應用程式負載平衡器的流量管理總覽。

• 如要瞭解如何提供網站內容，請參閱「提供網站內容」。

• 如要尋找 Google PoP 的位置，請參閱「GFE 位置」。

• 如要瞭解容量管理，請參閱利用負載平衡進行容量管理教學課程，以及利用全域負載平衡進行應用程式容量最佳化。

• 如要瞭解如何使用 Certificate Manager 佈建及管理 SSL 憑證，請參閱 Certificate Manager 總覽。

• 如要在負載平衡資料路徑中插入自訂邏輯，請設定服務擴充功能外掛程式或呼叫。

• 如果只有區域外部應用程式負載平衡器，您可以試用 Apigee Shadow API 探索功能，在現有Google Cloud 基礎架構中尋找 Shadow API (也稱為未記錄的 API)。啟用 Shadow API Discovery 前，請務必詳閱相關限制。