集中式负载均衡 vs. 分布式负载均衡
集中式负载均衡 vs. 分布式负载均衡
负载均衡（Load Balancing）是任何可伸缩系统的“交通警察”。
集中式负载均衡（Centralized LB）与分布式负载均衡（Distributed LB）代表了两种截然不同的“指挥哲学”：
• 前者“单点决策、统一调度”，简单、成熟、易观测；
• 后者“多点自治、协同决策”，弹性、低延迟、高可用。
二者在微服务、云原生、边缘计算、Service Mesh 等场景中并存，互为补充。
一、知识点框架速览
| 维度 | 集中式负载均衡 | 分布式负载均衡 |
|---|---|---|
| 决策位置 | 独立 LB 节点（硬件或软件） | 每个客户端或服务实例 |
| 控制面 | 单点或主备 | 去中心化、最终一致 |
| 数据面 | 流量必经 LB | 流量直连目标实例 |
| 典型实现 | LVS、Nginx、HAProxy、ELB、F5 | Envoy、Finagle、Linkerd、客户端 SDK、一致性哈希 |
| 适用规模 | 中小规模、南北向流量 | 大规模、东西向流量 |
| 故障域 | LB 单点 | 局部节点失效影响小 |
| 运维复杂度 | 低 | 高（需治理、观测、版本管理） |
二、集中式负载均衡详解
2.1 架构与组件
- VIP（Virtual IP）：对外唯一入口，DNS 指向 VIP。
- 调度算法：RR、WRR、LC、WLC、IP-Hash、一致性哈希、最少连接等。
- 健康检查：TCP/HTTP/GRPC 探活，失败即摘除。
- 会话保持：Source IP Hash、Cookie Insert、Sticky Table。
- 高可用：Keepalived + VRRP、BGP Anycast、双活 LB 集群。
2.2 优势
- 简单：部署、监控、排障都围绕一个或一组 LB。
- 功能丰富：SSL 终端、WAF、限流、缓存、压缩、灰度发布。
- 透明：对后端服务零侵入，语言栈无关。
2.3 局限
- 单点瓶颈：带宽、PPS、SSL 握手数、连接表大小。
- 延迟叠加：流量多一跳，RTT 增加 0.2~1 ms。
- 爆炸半径：LB 故障导致全集群不可用。
- 水平扩展上限：ECMP 最多 8~16 条等价路径，再多会哈希不均。
三、分布式负载均衡详解
3.1 架构范式
- 客户端侧负载均衡
每个调用方（Consumer）内置负载均衡逻辑，通过注册中心（Consul/Eureka/Nacos）实时感知 Provider 列表。 - 边车代理（Sidecar）
每个 Pod/VM 部署 Envoy，拦截进出流量，由控制面（Istiod）下发路由规则。 - 无代理直连
gRPC 内置负载均衡策略（pick_first、round_robin、weighted_target），直接连目标 IP。
3.2 决策流程
- 负载感知：基于实时延迟、错误率、QPS、权重、实例标签。
- 故障转移：熔断、重试、离群摘除（Outlier Detection）。
- 版本路由：金丝雀、A/B、按 Header 染色。
3.3 优势
- 零单点：任何节点故障只影响局部。
- 低延迟：流量直发，无额外 hop。
- 弹性扩展：节点数线性增加，吞吐线性提升。
- 细粒度治理：按方法级、按用户级、按地域级路由。
3.4 挑战
- 治理复杂：需要统一 SDK、版本管理、灰度升级。
- 观测困难：调用链分散，需分布式追踪（OpenTelemetry）。
- 网络放大：注册中心推送风暴、心跳风暴。
- 多语言：每种语言都要实现或引入 Sidecar。
四、对比与选型
| 比较维度 | 集中式 | 分布式 |
|---|---|---|
| 部署成本 | 低（买几台 LB 即可） | 高（Sidecar、注册中心、控制面） |
| 运维心智 | 传统网络运维即可 | 需 DevOps + SRE + 网络 |
| 性能上限 | 受限于 LB 规格 | 随节点数线性增长 |
| 功能扩展 | 依赖 LB 厂商 | 可自定义 Filter、Lua/Wasm |
| 故障域 | 全局 | 局部 |
| 适用场景 | 入口网关、南北向、SSL 卸载 | 微服务东西向、Service Mesh、边缘节点 |
五、混合模式实践
现代云原生平台往往“分层负载均衡”：
• L4 集中式：Anycast + ECMP 做全局流量入口，解决 BGP 收敛、DDoS 清洗。
• L7 分布式：Envoy Sidecar 做服务间调用，实现金丝雀、熔断、限流。
• 边缘自治：边缘节点内置轻量级 LB（如 Traefik、Nginx Unit），在断网场景下继续服务本地用户。
六、总结
| 结论 | 说明 |
|---|---|
| 没有银弹 | 集中式与分布式不是“谁取代谁”，而是“谁更适合哪一层”。 |
| 分层治理 | 入口用集中式，内部用分布式，边缘用自治式。 |
| 可观测优先 | 无论哪种模式，统一 Metrics、Tracing、Logging 是落地前提。 |
架构师洞见
• 集中式负载均衡像“机场塔台”，简单可控，但容量有限；分布式负载均衡像“每架飞机自带 TCAS”，复杂却弹性无限。
• 未来趋势是“控制面集中、数据面分布”：用统一控制面下发策略，用分布式数据面执行决策，兼顾治理与性能。