现代应用程序需要高可用性、性能与地理分散。用户期望无论身在何处都能获得即时响应，而服务必须在个别服务器甚至整个数据中心故障时仍能保持运作。本地流量管理器（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、现代替代方案，或结合多种技术的混合方法。