集中式负载均衡 vs. 分布式负载均衡

负载均衡（Load Balancing）是任何可伸缩系统的"交通警察"。

集中式负载均衡（Centralized LB）与分布式负载均衡（Distributed LB）代表了两种截然不同的"指挥哲学"：

• 前者"单点决策、统一调度"，简单、成熟、易观测；

• 后者"多点自治、协同决策"，弹性、低延迟、高可用。

二者在微服务、云原生、边缘计算、Service Mesh 等场景中并存，互为补充。

一、知识点框架速览

维度	集中式负载均衡	分布式负载均衡
决策位置	独立 LB 节点（硬件或软件）	每个客户端或服务实例
控制面	单点或主备	去中心化、最终一致
数据面	流量必经 LB	流量直连目标实例
典型实现	LVS、Nginx、HAProxy、ELB、F5	Envoy、Finagle、Linkerd、客户端 SDK、一致性哈希
适用规模	中小规模、南北向流量	大规模、东西向流量
故障域	LB 单点	局部节点失效影响小
运维复杂度	低	高（需治理、观测、版本管理）

二、集中式负载均衡详解

2.1 架构与组件

Internet VIP RS1 RS2 RS3 Health Check Health Check Health Check User Centralized LB
LVS/Nginx/ELB Service A-1 Service A-2 Service A-3

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 决策流程

Consumer Registry Provider-1 Provider-2 Subscribe service list [P1,P2,P3] + metadata Local LB algorithm Direct TCP/HTTP call Response Consumer Registry Provider-1 Provider-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"，复杂却弹性无限。

• 未来趋势是"控制面集中、数据面分布"：用统一控制面下发策略，用分布式数据面执行决策，兼顾治理与性能。