集中式负载均衡 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”,复杂却弹性无限。
• 未来趋势是“控制面集中、数据面分布”:用统一控制面下发策略,用分布式数据面执行决策,兼顾治理与性能。