PCA 架構之旅 09 — 網路與 Load Balancing
PCA
儲存選完，下一個要決定的就是流量怎麼進來。GCP 的 Load Balancing 在雲端市場算是少數的獨特賣點：全域 Anycast、單一公網 IP、跨 region 自動路由。但能力多，選型也跟著變複雜。
PCA 很愛考「給你一個需求，選哪種 LB」。這一步答不對，後面的 HA 跟成本估算都會偏掉。
為什麼這一步重要
PCA case study 通常會丟出這類句子：
- 「全球用戶、TLS 終止、需要 WAF」
- 「內部微服務之間的 gRPC 呼叫」
- 「遊戲伺服器、UDP、低延遲、要保留客戶端 IP」
- 「既有 TCP 應用、只在 asia-east1 一個 region」
每一句都對應不同的 LB 類型。考生常犯的錯誤：
- 無腦選 Global External Application Load Balancer：覺得「全域 + 應用層」聽起來最厲害，結果忘了有些場景只要區域或內部 LB 就夠了
- UDP 選 Application LB：Application LB 只處理 HTTP(S)，UDP / TCP raw 要用 Network LB
- 忽略「保留 client IP」需求：只有 Passthrough Network LB 能保留原始 client IP，考題會用這個條件逼你做選擇
核心概念
GCP Load Balancing 的三個正交維度：
| 維度 | 選項 | 判斷點 |
|---|---|---|
| Layer | Application (L7) / Proxy Network (L4) / Passthrough Network (L4) | 是 HTTP？還是 TCP/UDP？需要保留 client IP？ |
| Exposure | External（對外） / Internal（對內） | 流量來源在 VPC 內還是網際網路？ |
| Scope | Global（全域） / Regional（區域） | 用戶分布是全球還是單一區域？ |
七種常見組合與代表場景：
| LB 類型 | 協定 | 代表場景 |
|---|---|---|
| Global External Application LB | HTTP(S) | 全球用戶網站、整合 Cloud CDN / Cloud Armor |
| Regional External Application LB | HTTP(S) | 區域法規限制、需要綁定特定 region |
| Internal Application LB | HTTP(S) | 微服務 East-West、內部 API gateway |
| Global External Proxy Network LB | TCP / SSL | 全球 TCP 應用（非 HTTP），仍要 TLS 終止 |
| Regional External Proxy Network LB | TCP / SSL | 區域 TCP 應用 |
| External Passthrough Network LB | TCP / UDP | 保留 client IP、遊戲、VoIP、非標準協定 |
| Internal Passthrough Network LB | TCP / UDP | VPC 內部 L4 分流、HA 資料庫前端 |
關鍵分水嶺：
- Proxy vs Passthrough：Proxy 會終止連線（LB 跟後端各一條 TCP）；Passthrough 只改封包路由（client 跟後端直接對話）
- Application vs Proxy Network：兩者都是 proxy，但 Application 看 HTTP header / path，Proxy Network 只看 L4
思考框架
想清楚這四個問題：
- 是 HTTP(S) 嗎？ 是 → Application LB；否 → Network LB
- 需要保留 client 原始 IP 嗎？ 需要 → Passthrough；否則 Proxy
- 流量來自公網還是 VPC 內？ 公網 → External；VPC 內 → Internal
- 用戶是全球還是區域？ 全球 → Global（只有 Application 跟 Proxy Network 支援 Global）
補一個 PCA 很愛問的問題：
- 要做 WAF / OWASP Top 10 防護嗎？ 是 → 必須搭 Global External Application LB + Cloud Armor
走一遍範例 — 登雲書店
登雲書店要上線，流量怎麼接？我們拆成幾層來看：
第一層：會員購物網站（前端）
- 需求：HTTPS、全球 CDN、WAF 防爬蟲
- 選擇：Global External Application LB + Cloud CDN + Cloud Armor
- 理由：HTTP 協定 + 需要 path routing（/api vs 靜態資源）+ 整合 CDN
第二層：後端微服務之間（訂單 → 庫存 → 物流）
- 需求：gRPC、只在 VPC 內、跨 AZ HA
- 選擇：Internal Application LB（gRPC 走 HTTP/2）
- 理由：East-West 流量不該走出 VPC；需要 L7 routing 支援 service mesh
第三層：自架 PostgreSQL 讀取副本分流（Compute Engine / GKE 上的自管節點）
- 需求：TCP 5432、保留 client IP 做審計
- 選擇：Internal Passthrough Network LB
- 理由：PostgreSQL 協定是 TCP；審計需要 client IP；不需要 L7 能力
- 注意：Cloud SQL 是全代管服務，使用者無法在它前面掛自建 LB（讀取副本各自有獨立連線端點）；要用 ILB 分流的前提是資料庫節點由你自管
第四層：即時聊天客服（WebSocket over WSS）
- 需求：長連線、HTTP Upgrade
- 選擇：Global External Application LB
- 理由：Application LB 支援 WebSocket；不要誤選 Proxy Network LB
這裡有個常見的錯誤設計：把「後端微服務之間」也丟到 Global External Application LB。這不只多繞一圈、多付一筆網路費，還會讓內部呼叫暴露到公網路由，等於踩了零信任原則的雷。
常見陷阱
- UDP 場景選 Proxy Network LB：Proxy Network LB 只支援 TCP 跟 SSL，不支援 UDP。有 UDP 需求（DNS、遊戲、VoIP）就只能 Passthrough Network LB。
- 要保留 client IP 卻選 Application LB：Application LB 會把 client IP 放到
X-Forwarded-Forheader，不是真的保留。如果後端是 TCP 應用讀不到 header，必須改用 Passthrough Network LB。 - 全域能力幻覺：Passthrough Network LB 沒有 Global 版本，它永遠是 regional。看到「全球 + UDP + 保留 client IP」同時出現的題目，答案通常是用多個 regional Passthrough LB + Cloud DNS geo routing 拼出來。
延伸閱讀
系列導航
- 系列首頁：PCA 架構之旅
- 上一篇：PCA 架構之旅 08 — GCP 儲存服務選擇
- 下一篇：PCA 架構之旅 10 — 網路拓樸
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 9 填入你的 case study，邊寫邊內化。
pca-architect-journey — 9/13 完成
查看系列全覽 →