現代應用程式需要高可用性、效能與地理分散。使用者期望無論身在何處都能獲得即時回應，而服務必須在個別伺服器甚至整個資料中心故障時仍能保持運作。本地流量管理器（LTM）與全域伺服器負載平衡（GSLB）應運而生，成為分散式系統中流量管理的基礎。
LTM 在單一資料中心內運作，將流量分散到多台伺服器以優化資源利用率並提供容錯能力。GSLB 將此概念延伸至全球，根據位置、健康狀態與容量將使用者導向最佳資料中心。兩者結合創造出具韌性的架構，能在維持效能與可用性的同時承受多層級的故障。
本文探討 LTM 與 GSLB 的運作方式、架構模式以及相關的營運權衡。透過實際案例，我們將揭示何時適合使用各項技術，以及它們如何在現代基礎設施中相輔相成。
理解本地流量管理
本地流量管理器在資料中心層級運作，位於客戶端與應用程式伺服器之間，智慧地分配傳入請求。
LTM 架構
LTM 作為具備複雜流量分配能力的反向代理伺服器：
🔄 LTM 核心元件
虛擬伺服器
- 代表多台後端伺服器的單一 IP 位址
- 客戶端連接至虛擬 IP（VIP）而非個別伺服器
- 終止客戶端連線並向後端發起新連線
- 可執行 SSL/TLS 終止
- 套用流量政策與路由規則
伺服器池
- 提供相同服務的後端伺服器群組
- 成員可動態新增或移除
- 每個成員都有健康監控
- 支援加權分配以處理容量差異
- 實現無停機時間的滾動部署
健康監控
- 主動檢查：LTM 定期探測伺服器
- 被動檢查：監控實際流量以偵測故障
- 多種檢查類型：TCP、HTTP、HTTPS、自訂腳本
- 自動將故障伺服器從輪替中移除
- 恢復後逐步重新引入
LTM 維護連線狀態、追蹤伺服器健康狀況，並根據設定的演算法與當前條件做出即時路由決策。
負載平衡演算法
不同的演算法適合不同的應用程式特性：
⚖️ 分配策略
輪詢（Round Robin）
- 依序將請求分配到各伺服器
- 簡單且可預測
- 適用於伺服器容量相等的情況
- 不考慮當前伺服器負載
- 最適合請求成本均勻的無狀態應用程式
最少連線（Least Connections）
- 路由至活躍連線數最少的伺服器
- 考慮長時間連線
- 更適合請求持續時間變化的應用程式
- 需要連線追蹤開銷
- 對資料庫連線與串流有效
加權分配（Weighted Distribution）
- 根據伺服器容量按比例分配流量
- 適用於伺服器規格不同的情況
- 可在部署期間逐步轉移流量
- 需要容量規劃與調整
- 實現藍綠部署模式
IP 雜湊 / 會話持久性（IP Hash / Session Persistence）
- 將相同客戶端路由至相同伺服器
- 為有狀態應用程式維護會話親和性
- 可能造成分配不均
- 使伺服器維護複雜化
- 替代方案：共享會話儲存
演算法的選擇取決於應用程式架構，特別是會話是有狀態還是可以自由分配。
SSL/TLS 終止
LTM 通常處理 SSL/TLS 終止，將加密運算從應用程式伺服器卸載：
🔒 SSL 終止優勢
效能優化
- 集中式憑證管理
- 加密運算的硬體加速
- 降低應用程式伺服器的 CPU 負載
- 實現後端連線重用
- 簡化憑證輪替
流量檢查
- LTM 可檢查解密後的流量
- 套用基於內容的路由規則
- 實作 Web 應用程式防火牆（WAF）規則
- 記錄與監控應用層流量
- 偵測並阻擋惡意請求
營運簡化
- 憑證更新的單一點
- 跨服務的一致 TLS 設定
- 更容易的合規稽核
- 集中式加密套件管理
然而，SSL 終止意味著 LTM 與後端之間的流量在資料中心內通常是未加密的。對於敏感應用程式，可能需要 SSL 重新加密或端到端加密。
全域伺服器負載平衡
GSLB 將負載平衡延伸至多個地理位置，將使用者導向最佳資料中心。
GSLB 運作方式
與在第 4/7 層運作的 LTM 不同，GSLB 通常在 DNS 層級運作：
🌍 GSLB 架構
基於 DNS 的路由
- GSLB 作為您網域的權威 DNS 伺服器
- 客戶端查詢 www.example.com 的 DNS
- GSLB 回傳最佳資料中心的 IP 位址
- 客戶端直接連接至選定的資料中心
- GSLB 不持續參與流量傳輸
健康監控
- GSLB 監控每個資料中心的健康狀況
- 檢查可以是簡單的（ping）或複雜的（應用層級）
- 故障的資料中心從 DNS 回應中移除
- 自動容錯移轉至健康位置
- 恢復期間逐步轉移流量
地理智慧
- 從來源 IP 判斷客戶端位置
- 根據網路拓撲路由至最近的資料中心
- 考慮延遲，而非僅地理距離
- 可針對特定區域覆寫（資料主權）
- 平衡效能與容量
基於 DNS 的方法提供全球分散，而不需要 GSLB 處理實際流量，實現大規模擴展。
GSLB 路由政策
不同的政策針對不同的目標進行優化：
🎯 路由策略
地理鄰近性（Geographic Proximity）
- 將使用者路由至最近的資料中心
- 為大多數使用者最小化延遲
- 易於理解與設定
- 不考慮資料中心負載
- 可能將流量送至過載的鄰近資料中心
輪詢（Round Robin）
- 在資料中心間均勻分配使用者
- 全球平衡負載
- 忽略使用者位置與延遲
- 適用於測試或成本優化
- 遠距資料中心的使用者體驗不佳
加權分配（Weighted Distribution）
- 根據資料中心容量分配流量
- 考慮不同的基礎設施規模
- 可為維護逐步轉移流量
- 實現受控推出
- 需要容量規劃
基於效能（Performance-Based）
- 根據測量的延遲或回應時間路由
- 動態適應網路狀況
- 提供最佳使用者體驗
- 實作與監控更複雜
- 需要持續的測量基礎設施
容錯移轉（Failover）
- 主要資料中心處理所有流量
- 次要資料中心僅在主要故障時接收流量
- 最簡單的災難復原方法
- 正常運作時浪費次要容量
- 備份基礎設施的明確成本優化
許多實作結合多種政策：地理鄰近性搭配基於健康的容錯移轉與基於容量的加權。
DNS TTL 挑戰
GSLB 基於 DNS 的方法引入了一個關鍵限制：DNS 快取。
⚠️ DNS 快取影響
存活時間（TTL）權衡
- 低 TTL（60-300 秒）：更快的容錯移轉，更高的 DNS 查詢負載
- 高 TTL（3600+ 秒）：更低的 DNS 負載，更慢的容錯移轉
- 客戶端與 ISP 可能忽略 TTL 並快取更長時間
- 無法保證立即的流量轉移
- 即使使用低 TTL，容錯移轉也可能需要數分鐘
實際行為
- 某些 ISP 無論 TTL 如何都會快取 DNS 數小時
- 行動網路通常有積極的快取
- 企業網路可能覆寫 TTL
- 瀏覽器獨立快取 DNS
- 作業系統有自己的 DNS 快取
對容錯移轉的影響
- 無法使用基於 DNS 的 GSLB 實現即時容錯移轉
- 某些使用者將繼續連接故障的資料中心
- 應用層重試邏輯至關重要
- 對於關鍵服務考慮 Anycast 或基於 BGP 的替代方案
- 規劃逐步流量轉移，而非即時切換
此限制使 GSLB 不適合需要即時容錯移轉的場景。應用程式必須優雅地處理連線失敗並重試。
LTM 與 GSLB 結合
最穩健的架構採用分層方法結合兩種技術：
✅ 分層流量管理
GSLB 層（全域）
- 將使用者路由至最佳資料中心
- 處理資料中心層級的故障
- 提供地理分散
- 在 DNS 層級運作
- 管理跨區域流量
LTM 層（本地）
- 在資料中心內分配流量
- 處理伺服器層級的故障
- 提供 SSL 終止
- 在第 4/7 層運作
- 管理資料中心內流量
結合優勢
- 全域韌性與本地優化
- 資料中心故障不影響其他區域
- 伺服器故障對使用者不可見
- 無停機時間的維護
- 跨區域的逐步部署
此架構在多個層級提供韌性：伺服器、資料中心與區域。
流量流程範例
透過分層流量管理的典型請求流程：
1. 使用者查詢 www.example.com 的 DNS
2. GSLB 回傳最近資料中心的 IP（例如：美西）
3. 使用者連接至美西資料中心 VIP
4. LTM 在 VIP 接收連線
5. LTM 使用演算法選擇健康的後端伺服器
6. LTM 終止 SSL，轉發至後端
7. 後端處理請求，回傳回應
8. LTM 將回應轉發給使用者如果後端伺服器故障，LTM 立即路由至另一台伺服器。如果整個美西資料中心故障，GSLB 最終會將新使用者路由至美東（在 DNS TTL 過期後）。
生產環境事件：GSLB 如何拯救危機
數年前，我見證了 GSLB 在災難性資料中心故障期間的價值。我們位於新加坡的主要資料中心經歷了完全的網路中斷——不僅是我們的伺服器，整個設施都失去了連線。這次事件測試了我們的災難復原規劃，並揭示了 GSLB 的優勢與限制。
故障連鎖反應
中斷始於當地時間凌晨 2:47。我們的監控系統立即偵測到故障，但最初並不清楚範圍：
🚨 事件時間軸
T+0 分鐘：初始偵測
- 新加坡資料中心的監控警報
- 所有健康檢查同時失敗
- GSLB 自動將新加坡從 DNS 輪替中移除
- 新的 DNS 查詢回傳東京與香港的 IP
T+5 分鐘：使用者影響開始
- 快取 DNS 的使用者仍連接至新加坡
- 連線逾時與失敗
- 應用程式重試邏輯啟動
- 部分使用者成功容錯移轉至其他區域
- 其他使用者經歷完全的服務中斷
T+15 分鐘：逐步恢復
- 更多使用者的 DNS 快取過期
- 流量轉移至東京與香港
- 這些資料中心經歷負載增加
- 因過載導致部分效能下降
- 大多數使用者現在成功連接
T+30 分鐘：穩定
- 大部分流量遷移至健康的資料中心
- 積極的 DNS 快取導致剩餘故障
- 隨著負載平衡，效能恢復正常
- 新加坡資料中心仍完全離線
GSLB 完全按照設計運作：它偵測到故障並將新加坡從輪替中移除。然而，DNS TTL（300 秒）意味著使用者在故障後仍持續嘗試連線數分鐘。
成功之處
分層架構證明了其價值：
✅ 成功的容錯移轉要素
GSLB 自動偵測
- 健康檢查在 30 秒內偵測到故障
- 新加坡立即從 DNS 回應中移除
- 不需要手動介入
- 新使用者自動路由至健康的資料中心
應用程式重試邏輯
- 應用程式設定為重試失敗的連線
- 重試觸發新的 DNS 查詢
- 使用者最終到達健康的資料中心
- 優雅降級而非完全故障
多區域容量
- 東京與香港有足夠的容量
- 處理新加坡的流量而不崩潰
- 效能下降但仍可接受
- 驗證了容量規劃假設
健康資料中心內的 LTM
- 東京與香港的 LTM 分配增加的負載
- 沒有個別伺服器被壓垮
- 健康監控防止連鎖故障
- 對連接後的使用者透明
沒有 GSLB，整個服務將會離線。沒有剩餘資料中心的 LTM，增加的負載可能會壓垮個別伺服器。
失敗之處
事件也揭示了限制：
⚠️ 容錯移轉挑戰
DNS 快取延遲
- 5-15 分鐘後大多數使用者才遷移
- 某些 ISP 快取超過一小時
- 行動網路特別有問題
- 無法強制立即快取失效
- 使用者在轉換期間經歷故障
會話遺失
- 新加坡的活躍會話遺失
- 使用者必須重新驗證
- 進行中的交易失敗
- 沒有跨區域會話複製
- 資料一致性挑戰
監控缺口
- 未立即識別設施範圍的中斷
- 最初認為是我們的基礎設施問題
- 花了 20 分鐘確認設施問題
- 需要更好的外部監控
- 與設施提供商的溝通延遲
DNS TTL 限制特別令人沮喪。儘管 GSLB 在數秒內正確回應，但由於我們無法控制的快取，使用者仍持續失敗數分鐘。
經驗教訓
這次事件強化了幾個架構原則：
🎯 災難復原見解
接受 DNS 限制
- 基於 DNS 的 GSLB 無法提供即時容錯移轉
- 規劃 5-15 分鐘的轉換期
- 應用程式重試邏輯至關重要
- 對於真正關鍵的服務考慮 Anycast
- 設定實際的 RTO 期望
容量規劃
- 每個資料中心必須處理 N+1 容量
- 不要假設所有資料中心始終可用
- 定期在負載下測試容錯移轉
- 持續監控容量利用率
- 規劃區域流量高峰
會話管理
- 無狀態應用程式容錯移轉乾淨
- 有狀態應用程式需要會話複製
- 考慮分散式會話儲存
- 為會話遺失場景設計
- 實作優雅的會話恢復
監控與溝通
- 從基礎設施外部監控
- 與設施提供商建立溝通管道
- 自動化事件偵測與通知
- 記錄升級程序
- 在演練期間測試溝通
新加坡中斷持續了四小時。GSLB 確保在初始轉換期後，使用者經歷最小的中斷。沒有它，整個服務將在整個期間離線。
LTM 與 GSLB：並列比較
| 面向 | LTM（本地流量管理器） | GSLB（全域伺服器負載平衡） |
|---|---|---|
| 範圍 | 單一資料中心 | 多個資料中心/區域 |
| OSI 層 | 第 4/7 層（傳輸/應用） | 第 3 層（DNS） |
| 路由決策 | 每個連線/請求 | 每個 DNS 查詢 |
| 容錯移轉速度 | 即時（秒） | 受 DNS 快取延遲（分鐘） |
| 流量處理 | 代理實際流量 | 僅回傳 IP 位址 |
| 健康檢查 | 連線層級監控 | 資料中心層級監控 |
| 負載平衡 | 伺服器對伺服器分配 | 資料中心對資料中心分配 |
| SSL/TLS | 可終止 SSL | 不涉及 SSL |
| 會話持久性 | 支援黏性會話 | 無會話感知 |
| 典型使用案例 | 在 Web 伺服器間分配負載 | 將使用者路由至最近區域 |
| 故障域 | 個別伺服器故障 | 資料中心/區域故障 |
| 設定複雜度 | 中等 | 較低（基於 DNS） |
| 營運開銷 | 較高（連線狀態） | 較低（無狀態 DNS） |
| 可擴展性 | 受硬體容量限制 | 高度可擴展（DNS） |
何時使用 LTM 與 GSLB
在 LTM、GSLB 或兩者之間選擇取決於您的架構與需求：
🤔 決策框架
使用 LTM 當：
- 在單一資料中心內運作
- 需要伺服器層級的負載平衡
- 需要 SSL 終止
- 想要連線層級的健康監控
- 有多台伺服器提供相同服務
- 需要第 7 層路由能力
使用 GSLB 當：
- 跨多個地理位置運作
- 需要資料中心層級的容錯移轉
- 想將使用者路由至最近位置
- 有資料地域性的合規要求
- 需要跨區域的災難復原
- 想優化全球效能
同時使用兩者當：
- 在全球運作且有多個資料中心
- 每個資料中心有多台伺服器
- 需要多層級的韌性
- 想要全球與本地的最佳效能
- 有高可用性需求
- 可以證明營運複雜性的合理性
大多數大規模應用程式最終會在成長與全球分散時採用兩者。
替代方案與現代方法
傳統的 LTM 與 GSLB 面臨來自新技術的競爭：
🔄 現代替代方案
Anycast 路由
- 從多個位置宣告相同 IP
- 網路路由將使用者導向最近位置
- 即時容錯移轉（無 DNS 快取延遲）
- 實作更複雜
- 需要 BGP 與網路專業知識
- 常見於 CDN 與 DNS 服務
服務網格（Service Mesh）
- 應用層級的負載平衡
- 與容器編排整合
- 動態服務發現
- 細粒度的流量控制
- 更適合微服務架構
- 範例：Istio、Linkerd、Consul
雲端負載平衡器
- 雲端提供商的託管服務
- 與雲端基礎設施整合
- 自動擴展與健康監控
- 較低的營運負擔
- 範例：AWS ELB/ALB、Azure Load Balancer、GCP Load Balancing
具備來源容錯移轉的 CDN
- CDN 處理全球分散
- 自動來源容錯移轉
- 快取減少來源負載
- 簡化的架構
- 範例：CloudFlare、Fastly、Akamai
這些替代方案通常提供與現代雲原生架構更好的整合，儘管傳統的 LTM/GSLB 在許多場景中仍然相關。
營運考量
運行 LTM 與 GSLB 引入營運複雜性：
⚠️ 營運挑戰
設定管理
- LTM 與 GSLB 設定必須保持同步
- 變更需要仔細測試
- 設定錯誤可能導致中斷
- 版本控制與自動化至關重要
- 需要定期稽核
健康檢查設計
- 過於積極：誤報、抖動
- 過於寬鬆：故障偵測緩慢
- 必須測試實際應用程式功能
- 在準確性與開銷之間取得平衡
- 針對不同故障模式的不同檢查
容量規劃
- LTM 本身可能成為瓶頸
- GSLB DNS 基礎設施必須擴展
- 規劃 N+1 冗餘
- 持續監控利用率
- 在峰值負載條件下測試
監控與警報
- 將 LTM/GSLB 健康與應用程式分開監控
- 追蹤分配模式的異常
- 對健康檢查失敗發出警報
- 監控 DNS 查詢模式
- 建立基準指標
營運負擔很大，但對於需要高可用性與全球分散的應用程式來說是合理的。
結論
本地流量管理器與全域伺服器負載平衡構成現代高可用性架構的基礎。LTM 在資料中心內提供伺服器層級的分配，透明地處理故障並優化資源利用率。GSLB 將此延伸至全球，根據位置、健康狀況與容量將使用者路由至最佳資料中心。兩者結合創造出能在多個層級承受故障的韌性系統。
架構模式已經確立：GSLB 在 DNS 層級運作以進行全球路由，而 LTM 在第 4/7 層運作以進行本地分配。這種分層方法在資料中心與伺服器層級都提供韌性，實現無停機時間的維護與優雅的故障處理。這種組合使應用程式能夠在維持效能與可用性的同時進行全球擴展。
然而，兩種技術都引入了營運複雜性與限制。基於 DNS 的 GSLB 由於快取無法提供即時容錯移轉，需要應用程式實作重試邏輯並接受故障期間的轉換期。LTM 需要仔細設定健康檢查、負載平衡演算法與容量規劃。營運負擔包括設定管理、監控與定期測試容錯移轉場景。
實際事件展示了這些技術的價值與限制。新加坡資料中心中斷顯示 GSLB 成功將流量路由至健康位置，但也揭示了阻止即時容錯移轉的 DNS 快取延遲。事件驗證了多區域容量規劃、應用程式重試邏輯的重要性，以及接受基於 DNS 的容錯移轉需要數分鐘而非數秒的事實。
現代替代方案如 Anycast 路由、服務網格與雲端負載平衡器提供不同的權衡。Anycast 提供更快的容錯移轉而無 DNS 快取延遲。服務網格與微服務架構整合得更好。雲端負載平衡器透過託管服務減少營運負擔。然而，傳統的 LTM 與 GSLB 在許多場景中仍然相關，特別是在混合雲與本地環境中。
實作 LTM、GSLB 或兩者的決策應基於您的架構、規模與可用性需求。單一資料中心部署僅從 LTM 受益。多區域部署需要 GSLB 進行地理分散。大規模全球應用程式通常需要兩者以在多個層級提供韌性。當可用性需求要求時，營運複雜性是合理的，但對於不太關鍵的應用程式，更簡單的替代方案可能就足夠了。
在實作這些技術之前，請考慮：您的可用性需求是否證明營運複雜性的合理性？您的團隊能否管理設定與監控負擔？您是否在實際條件下測試過容錯移轉場景？是否有更簡單的替代方案能滿足您的需求？答案將指導您是否採用傳統的 LTM/GSLB、現代替代方案，或結合多種技術的混合方法。