PCA 雲端架構師之旅 09 — 網路與 Load Balancing

儲存選完，接著要決定使用者的請求怎麼進來、送往哪些後端。GCP 的負載平衡器選項不少；如果從產品名稱背起，很快就會混在一起。先問流量走 HTTP 還是 TCP／UDP、入口在內部還是外部，再看要不要跨區域。

這篇會把選型問題逐步拆開，也會提醒你確認後端類型、健康檢查與成本；同樣叫負載平衡器，能接的工作負載不一定相同。

這是 13 步驟 PCA 雲端架構師之旅 的第九站。

先看流量，再看部署範圍

案例可能會這樣描述流量需求：

• 「全球用戶、要做 TLS 終止、還要 WAF」
• 「內部微服務之間的 gRPC 呼叫」
• 「遊戲伺服器、走 UDP、低延遲、要保留客戶端 IP」
• 「一個既有的 TCP 應用，只跑在 asia-east1 一個 region」

先分清楚協定、入口對外或對內、後端分布範圍，再確認後端是否必須在封包層看到原始 client IP。這些條件一起看，比從單一詞彙猜 LB 類型可靠。

常見的誤判有三種。只因用戶分布全球就選全域 Application LB，卻沒檢查應用實際的入口範圍；把 UDP 交給只處理 HTTP(S) 的 Application LB；或把「後端能讀到 client IP」和「封包來源 IP 不變」當成同一件事。最後一項尤其要問清楚：Proxy 可以透過標頭或 PROXY protocol 傳遞來源資訊，但若要求封包層保留來源位址，就要看 Passthrough。

flowchart TB
  R[流量需求] --> H{HTTP、HTTPS 或 gRPC？}
  H -- 是 --> A[Application LB]
  H -- 否 --> I{走 UDP，或後端須在<br/>封包層看到來源 IP？}
  I -- 是 --> P[Passthrough Network LB]
  I -- 否 --> N[Proxy Network LB]
  A --> E{公網還是 VPC 內部？}
  P --> E
  N --> E
  E -- 公網 --> X[External]
  E -- 內部 --> Y[Internal]
  X --> G{後端跨多個 region<br/>還是單一 region？}
  Y --> G
  G --> V[選出最小且足夠的範圍]

用三個維度縮小範圍

LB 類型和部署模式會更新，先記三個比較穩定的維度：協定、對外或對內，以及後端的區域範圍。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

下面列出常見配置。它是對照表，不是完整產品清單；例如全域外部 Passthrough Network LB 目前另有 Preview 模式。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

表格看完，再把兩個容易混淆的差別釐清：

第一條，Proxy 跟 Passthrough 的差別。Proxy 型的 LB 會終止用戶端連線，再建立到後端的連線；後端可透過支援的標頭或協定取得用戶端資訊，但網路層看到的來源不同。Passthrough 不終止連線，後端可看到原始來源 IP。題目若強調「後端在網路層保留來源 IP」，就要留意這個差別。

第二條，Application 跟 Proxy Network 的差別。這兩個都是 proxy（都會終止連線），差在看得多深。Application LB 是 L7，看得懂 HTTP 的 header、path、cookie，所以能做 /api 跟靜態資源分流這種事；Proxy Network LB 只看到 L4，它知道這是一條 TCP，但不知道裡面裝的是什麼。需要按路徑分流就得用 Application，純粹 TCP 轉發才輪到 Proxy Network；若還要終止 TLS，得選 global external（或 classic）模式，regional 與 internal 模式只處理 TCP。

📝 考場提點

選負載平衡器時，先確認協定、是否要保留原始來源 IP、入口在公網或 VPC，以及服務範圍。這些條件能先縮小選項；若題目還要求 WAF 或應用層防護，再看 Cloud Armor 與所選 Application LB 的搭配方式，別只憑「全球」或「安全」一個字決定。

sequenceDiagram
  participant C as Client
  participant L as Load Balancer
  participant B as Backend
  rect rgb(239, 246, 255)
    Note over C,B: Proxy 模式
    C->>L: 建立連線 1
    L->>B: 另建連線 2
    Note right of B: 後端看到 LB 來源 IP
  end
  rect rgb(236, 253, 245)
    Note over C,B: Passthrough 模式
    C->>L: 原始 TCP／UDP 封包
    L->>B: 只轉送，不終止連線
    Note right of B: 後端保留 client IP
  end

走一遍範例 — 登雲書店

光講維度還是抽象，拿登雲書店走一遍會比較清楚。從公網入口到 VPC 內部，流量的協定和服務對象會變，適合的 LB 也可能跟著變。

第一層：會員購物網站（前端）

• 需求：HTTPS、全球 CDN、WAF 防爬蟲
• 選擇：Global External Application LB + Cloud CDN + Cloud Armor
• 理由：HTTP 協定 + 需要 path routing（/api vs 靜態資源）+ 整合 CDN

第二層：後端微服務之間（訂單 → 庫存 → 物流）

• 需求：gRPC、只在 VPC 內、跨 zone HA
• 選擇：Internal Application LB（gRPC 走 HTTP/2）
• 理由：East-West 流量不該走出 VPC；需要 L7 routing 支援 service mesh

第三層：自架 PostgreSQL 讀取副本分流（Compute Engine / GKE 上的自管節點）

（登雲書店實際用的是 Cloud SQL，這一層換成自管節點，只是為了示範 L4 內部分流要選哪一種 LB）

• 需求：TCP 5432、保留 client IP 做審計
• 選擇：Internal Passthrough Network LB
• 理由：PostgreSQL 協定是 TCP；審計需要 client IP；不需要 L7 能力
• 注意：Cloud SQL 是全代管服務，不會在讀取副本之間自動分流（各讀取副本有各自的連線 IP；Enterprise Plus 版的 read pool 則提供單一讀取端點並內建負載平衡）；本例以 ILB 分流，前提是資料庫節點由你自管

第四層：即時聊天客服（WebSocket over WSS）

• 需求：長連線、HTTP Upgrade
• 選擇：Global External Application LB
• 理由：Application LB 支援 WebSocket；Global External Proxy Network LB 雖然也能承載走 SSL 的 WebSocket，官方仍建議 HTTP(S) 流量用 Application LB

這四層裡，後端微服務之間的呼叫要另外看。若直接共用對外的 Global External Application LB，內部 API 也可能經過公開入口，增加存取控制與路徑管理的負擔。只供內部使用的服務，先評估 Internal LB，並確認網路與權限設定符合需求。

📝 考場提點

case study 若同時出現對外網站、內部 API 和資料庫連線，先把每條流量的來源、目的地與協定分開畫。內部流量不必因為網站用了 External LB，就跟著走公開入口；也別只因為題目提到預算，就一律改用 Regional LB。比較候選方案時，要一起核對後端類型、資料路徑、存取控制、可用性要求和費用。

flowchart TB
  U[全球會員] --> G[Global External Application LB<br/>CDN＋Cloud Armor]
  G --> W[網站與 WebSocket]
  G --> N[Serverless NEG]
  N --> C[Cloud Run APIs]
  C --> I[Internal Application LB<br/>gRPC 微服務]
  I --> S[訂單、庫存、物流]
  S --> P[Internal Passthrough LB<br/>自管 PostgreSQL 節點]
  P --> D[資料庫讀取副本]

那些把人坑進去的細節

縮小候選後，還有幾個細節值得再核對。

UDP 與 Proxy Network LB 不相容。 DNS、遊戲或 VoIP 若走 UDP，可評估 Passthrough Network LB；接著再確認要對外或對內，以及使用區域或全域模式。

分清楚「取得來源資訊」和「封包來源 IP 不變」。 Application LB 可透過 X-Forwarded-For 傳遞 client IP；部分 Proxy Network LB 也能用 PROXY protocol 傳遞連線資訊。但後端在網路層看到的來源不是原始 client。若應用要求封包來源 IP 不變，就比較 Passthrough 的支援模式。

Passthrough 不再只有區域型。 常見的 regional external Passthrough 只使用單一區域後端；Google 另提供 global external Passthrough（目前為 Preview），可把流量導向多區域後端。若專案不能使用 Preview，仍可評估多個區域入口搭配 DNS 路由，並確認健康檢查與故障切換行為。（參考：Google Cloud 負載平衡器總覽）

flowchart LR
  U[全球 UDP Client] --> D[Cloud DNS<br/>地理位置路由]
  D --> T[asia-east1<br/>Regional Passthrough LB]
  D --> J[asia-northeast1<br/>Regional Passthrough LB]
  D --> K[asia-northeast3<br/>Regional Passthrough LB]
  T --> T1[台灣遊戲後端]
  J --> J1[日本遊戲後端]
  K --> K1[韓國遊戲後端]
  T1 -. 健康狀態回饋 .-> D
  J1 -. 健康狀態回饋 .-> D
  K1 -. 健康狀態回饋 .-> D

Cloud Run 後端要透過 Serverless NEG 接上 Application Load Balancer。 設定全域外部 Application Load Balancer 時，後端服務使用 Serverless Network Endpoint Group（NEG）指向 Cloud Run；若還要使用 Cloud Armor，也應先把這條連線路徑接好。

如果後端一直顯示 unhealthy，除了應用本身，也要查健康檢查路徑與防火牆。負載平衡器的探測流量必須能到達後端；建立規則時，來源範圍應以所用產品的官方文件為準。

延伸閱讀

• Cloud Load Balancing 總覽
• 選擇 Load Balancer 類型
• Cloud Armor 安全防護
• Cloud CDN 快取策略

下一步：流量怎麼進來搞定了，但 LB 後面那張網要怎麼鋪——VPC、子網、防火牆規則與位址規劃——下一篇我們來談網路拓樸。

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 08 — GCP 儲存服務選擇
• 下一篇：PCA 雲端架構師之旅 10 — 網路拓樸

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 9 填入你的 case study，邊寫邊內化。