PCA 雲端架構師之旅 09 — 網路與 Load Balancing
儲存選完，下一個問題就很現實：流量到底怎麼進來。GCP 的 Load Balancing 是它在雲端市場少數真的拿得出手的東西——全域 Anycast、一個公網 IP 蓋全世界、跨 region 自動路由，這套別家還真不容易抄。但能力一多，選型就跟著難，七種 Load Balancer 攤在你面前，題目又只給你三行字，你得很快認出它要的是哪一種。
PCA 超愛考這個。給你一段需求，問你選哪種 LB。這一題答歪，後面的高可用設計、成本估算全部跟著歪。所以這篇我們不只把七種講清楚，更重要的是練那個「看到關鍵字就反射出答案」的肌肉。
這是 13 步驟 PCA 雲端架構師之旅 的第九站。
圖解：七種 Load Balancer 不用整張死背。先問流量是 HTTP(S) 還是 TCP／UDP，再問使用者在外部還是內部，最後看服務範圍要全域還是區域；三個答案會把選項快速縮小，健康檢查再決定哪些後端真的能接流量。
題目其實已經把答案寫在句子裡
你大概會在 case study 看到這種句子，每一句背後都鎖死了一種 LB：
- 「全球用戶、要做 TLS 終止、還要 WAF」
- 「內部微服務之間的 gRPC 呼叫」
- 「遊戲伺服器、走 UDP、低延遲、要保留客戶端 IP」
- 「一個既有的 TCP 應用，只跑在 asia-east1 一個 region」
讀的時候眼睛要盯三個關鍵字：協定（是不是 HTTP）、範圍（全球還是一個 region）、有沒有要保留原始 client IP。這三個答完，答案幾乎就出來了。
過來人提醒你三個最常翻車的點。第一個，看到題目就反射選 Global External Application Load Balancer——「全域 + 應用層」聽起來最豪華嘛。但很多場景根本只需要一個區域 LB，甚至內部 LB 就夠了，你選了最貴的那個，邏輯上不算錯，但在「成本要砍 35%」的案子裡就是扣分。第二個，UDP 的需求拿 Application LB 去接，這個直接判死——Application LB 只認 HTTP(S)，UDP 跟 raw TCP 它碰都不碰。第三個最陰，題目埋一句「要保留 client IP」，這句話一出現，能選的就剩 Passthrough Network LB 一種，其他全部出局。
七種 LB，先把座標軸搞懂
直接背七種組合很痛苦，而且容易記混。聰明的做法是先理解三個彼此獨立的維度，組合起來就是那七種。
Google 的建立精靈其實偷偷把選型順序幫你排好了：第一步先逼你選應用程式(HTTP/HTTPS)還是網路(TCP/UDP/SSL)，接著左側的步驟 2「公開或內部」、步驟 3「全域或單一區域」一路往下問。這三步就是上面那張「三軸」的真身。考場上沒有精靈給你點，但你腦袋要照同一個順序跑一遍——協定 → 對外對內 → 範圍——三題答完，七個選項就縮到剩一個。
| 維度 | 選項 | 你要問自己 |
|---|---|---|
| 協定層 (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 跟 Passthrough 的差別。Proxy 型的 LB 會把連線「切成兩段」——client 連到 LB 是一條 TCP，LB 再連後端是另一條 TCP，所以後端看到的來源 IP 是 LB 的。Passthrough（直通）就完全不同，它只改封包的路由，不終止連線，client 跟後端等於直接對話，後端拿得到原始 client IP。這就是為什麼「保留 client IP」這個需求一出現，答案只能是 Passthrough。
第二條，Application 跟 Proxy Network 的差別。這兩個都是 proxy（都會終止連線），差在看得多深。Application LB 是 L7，看得懂 HTTP 的 header、path、cookie，所以能做 /api 跟靜態資源分流這種事；Proxy Network LB 只看到 L4，它知道這是一條 TCP，但不知道裡面裝的是什麼。需要按路徑分流就得用 Application，純粹 TCP 轉發又想要 TLS 終止才輪到 Proxy Network。
📝 考場提點
考場上不要硬記七個名字，記「三軸 + 兩條分水嶺」就好。拿到題目按順序問四件事：是不是 HTTP（是→Application，否→Network）→ 要不要保留 client IP（要→Passthrough，否→Proxy）→ 流量從公網還是 VPC（公網→External，內部→Internal）→ 全球還是區域（全球只有 Application 跟 Proxy Network 撐得住）。四題問完答案就鎖定了。額外記一條反射：題目只要出現 WAF、OWASP Top 10、防爬蟲、DDoS，答案幾乎一定是 Global External Application LB 搭 Cloud Armor，這組是綁在一起的。
走一遍範例 — 登雲書店
光講維度太抽象，我們把登雲書店真的接一遍。它要上雲了，流量從前端到後端、從公網到 VPC 內部，每一層需要的 LB 都不一樣，正好把七種裡的關鍵幾種都用上。
第一層：會員購物網站（前端）
- 需求：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。我看過不少團隊圖方便，一套外部 LB 內外通吃。問題是這樣內部呼叫會繞出 VPC、走一圈公網路由再回來，不只白白多付一筆流量費、多吃一段延遲，更糟的是內部 API 等於暴露在公網能觸及的路徑上，零信任原則第一條就破了。內部往內部的流量，老老實實走 Internal LB，這不只是省錢，是安全基線。
📝 考場提點
case study 的 LB 題常常一次丟給你好幾層流量，評分看的是你有沒有「分層選對」——尤其是外部 vs 內部這一刀。內部往內部硬走 External LB，在改考卷的人眼裡同時踩到成本（多付 egress）跟安全（破壞零信任）兩個雷，是雙重扣分。另一個高頻陷阱：題目一強調「成本要砍」「預算有限」，就別反射把每一層都堆 Global External Application LB——能用 Regional、能用 Internal 的地方就降下來，這種「夠用就好」的取捨，正是 PCA 想看到的架構成熟度。
那些把人坑進去的細節
七種選完，魔鬼藏在幾個容易記反的地方，這幾個 PCA 幾乎每次改版都還留著考。
UDP 千萬別碰 Proxy Network LB。 Proxy Network LB 只吃 TCP 跟 SSL，UDP 它不收。所以 DNS、遊戲、VoIP 這類走 UDP 的，唯一的路就是 Passthrough Network LB。題目把「UDP」跟「Proxy」放在同一個選項裡，那個選項就是來騙你的。
以為 X-Forwarded-For 就是保留 client IP。 Application LB 確實會把原始 IP 塞進 X-Forwarded-For 這個 HTTP header，但這是「寫在 header 裡」，不是「封包層真的保留」。如果你的後端是純 TCP 應用、根本不解析 HTTP header，那它永遠讀不到這個 IP。需求只要寫「後端要拿到原始 client IP 做審計」而後端又不是 HTTP 服務，標準答案就是 Passthrough Network LB，別在 header 上鑽牛角尖。
Passthrough Network LB 沒有 Global 版本。 這點很多人栽過。它永遠是 regional，沒有全域版。所以當題目同時丟出「全球用戶 + UDP + 要保留 client IP」這種看似無解的組合時，它不是要你找一個神奇的全域 Passthrough，而是要你自己拼——在多個 region 各擺一個 regional Passthrough LB，前面再用 Cloud DNS 的地理路由把用戶導去最近的那個。能想到「用 DNS 補上 Global 這一層」，這題你就贏了。
選到直通式這一步，你會發現一件事：外部那邊只給你一個 Region A，從頭翻到尾都找不到「全域」那顆按鈕。這不是介面漏做，是直通式 LB 天生就永遠是區域性的。所以題目丟「全球用戶 + UDP + 保留 client IP」時，別傻傻去找一個神奇的全域 Passthrough——它不存在，正解是每個 region 各擺一台，再用 Cloud DNS 補上全域這層。精靈幫你把這個考題陷阱直接畫出來了。
Cloud Run / serverless 後端要靠 NEG 掛上去。 這點考試很愛拐彎問。Global External Application LB 沒辦法直接指向一個 Cloud Run 服務，中間得隔一層 Serverless Network Endpoint Group（NEG）當橋。題目如果寫「用全域 LB + Cloud Armor 罩住一個 Cloud Run 後端」，正確接法是 LB →（路由規則）→ Serverless NEG → Cloud Run，少了 NEG 這層就接不起來——選項裡那個「LB 直接指 Cloud Run」看起來最直覺，但它是錯的。
很多人以為 LB 後面只能掛 VM，這個下拉選單就是最好的反例。「無伺服器 NEG」這一項，正是把 Cloud Run、App Engine、Cloud Functions 接到 LB 後面的那座橋。考試最愛擺的陷阱選項是「LB 直接指 Cloud Run」——看起來最順手，但少了這層 Serverless NEG 就是接不起來。記住後端類型這格一定要先選對，橋沒搭好，Cloud Armor 罩得再漂亮流量也進不去。
順帶一個實務上的痛，考試不一定考但工作一定遇到：health check 的防火牆。LB 的健康檢查是從 Google 一組固定的探測 IP 段打進來的，很多人 LB 都配好了卻發現後端一直被標成 unhealthy，最後才發現是 VPC 防火牆沒放行那幾段探測 IP。架構圖上看不到這個坑，但它能讓你整個下午都在懷疑人生。
把 130.211.0.0/22 和 35.191.0.0/16 這兩段直接背起來——它們是 Google 健康檢查探測器的固定來源 IP。沒有這條規則放行，你的 LB 配得再完美，後端也會被健康檢查一路判成 unhealthy，流量一個都送不進去。這坑在架構圖上完全看不到，卻是新手最常花整個下午懷疑人生的地方；工作一定會踩，考試偶爾也拿它出來問。
延伸閱讀
下一步：流量怎麼進來搞定了，但 LB 後面那張網要怎麼鋪——VPC、子網、對等互連、混合連線——下一篇我們來談網路拓樸。
系列導航
- 系列首頁：PCA 雲端架構師之旅
- 上一篇：PCA 雲端架構師之旅 08 — GCP 儲存服務選擇
- 下一篇：PCA 雲端架構師之旅 10 — 網路拓樸
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 9 填入你的 case study，邊寫邊內化。
相關文章
您可能也會對這些文章感興趣
PCA 雲端架構師之旅 09 — 網路與 Load Balancing
GCP 七種 Load Balancer 的取捨：Application、Proxy Network、Passthrough Network；外部 vs 內部、全域 vs 區域。PCA 必考選型決策。
PCA 雲端架構師之旅 01 — 讀懂案例情境
PCA 考試第一步就是讀懂 case study。本文帶你拆解業務目標、技術限制、利害關係人，避免沒看完題目就開始選 GCP 服務。
PCA 雲端架構師之旅 02 — 定義 User Personas
PCA 架構設計不是畫服務圖，而是從使用者開始。本文教你定義 User Persona，讓後續的 SLO、API、儲存選型都有依據。
