为什么需要负载均衡？
- 标签：负载均衡、后端、微服务、Spring Cloud
🏛 业务架构师
为什么需要负载均衡——我按业务价值三层讲：
1. 可用性（第一价值）：多实例分摊流量，单实例故障时摘除节点即可，消除单点。没有 LB，一台机器的硬件故障就是业务事故；有 LB，它只是一次例行摘除。
2. 可扩展性（容量弹性）：大促流量来了加实例、过了缩回去，LB 把流量自动分给新实例——扩缩容不用改任何调用方配置，这是弹性伸缩（K8s HPA）能成立的前提。成本视角：按峰值 10 倍配置单机 vs 平时只付 2 倍，LB 是"用弹性换成本"的机制基础。
3. 性能与隔离：请求分散，单点连接/资源瓶颈摊薄；配合灰度策略，还能做流量隔离（新旧版本分流量、租户分组路由）。
两种部署形态的分工（面试要能区分）：
- 服务端 LB（集中式）：F5/Nginx/云 SLB/K8s Service——入口层（南北向流量）用它，全局视角管控；
- 客户端 LB（进程内）：Spring Cloud LoadBalancer、Dubbo 内置——微服务间调用（东西向）用它，从注册中心拿实例列表在调用方本地选，少一跳网络、没有 LB 单点、能结合熔断做"摘除故障实例"的细粒度治理。
我的实践要点：真正的难点不在"分流量"，在**"分得对"——带状态服务的会话保持、灰度标签路由、慢实例自动降权。LB 策略要和健康检查、熔断、发布策略**联动，它是流量治理体系的执行器，不是孤立组件。
🏗 系统架构师
四个根本诉求：
- 分摊负载：单机容量有限，垂直扩展有天花板且成本非线性；水平扩展后流量必须分配到多副本；
- 高可用：实例故障自动摘除、流量绕开——LB 是把「冗余」变「可用」的转换器；
- 弹性：扩缩容后流量自动再均衡，调用方无感；
- 性能就近：同机房/同 AZ 路由降低 RT，跨 AZ 带宽成本也能省。
架构关键点：LB 的层级决定能力边界——L4 只见连接（性能高、无协议语义），L7 理解协议（路由改写限流精细但贵）；健康检查质量决定故障转移速度（主动探测与被动摘除结合）；会话亲和（一致性哈希）是有状态场景的刚需，也是扩展性的枷锁。
容量视角：LB 自身是共享组件——它的带宽、PPS、CPU 就是全站天花板，必须集群化加逐级分摊（DNS → 接入层 → 网关 → 客户端 LB）。任何一层没有主备或多副本，都是单点。
💻 全栈开发专家
三个硬需求：
- 水平扩展：单机有上限（CPU/内存/连接数），加机器必须把流量分出去——LB 是水平扩展的前提
- 高可用：实例会挂（发布、OOM、宿主机故障），LB + 健康检查自动绕开故障节点，用户无感
- 避免热点：把请求打散（均匀、按权重或一致性哈希定向），防止一台忙死其他闲死
工程上它还承载流量治理入口：灰度按版本分流、金丝雀小比例放量、慢启动权重爬升、同城优先路由——这些策略都长在 LB 上。
微服务里要分清两级：服务端 LB（Nginx/K8s Service/网关，入口处集中分发）和客户端 LB（Ribbon→LoadBalancer，调用方从注册中心拿列表自己选）——后者少一跳网络、感知实例变化快，是 Feign 调用的默认形态；Service Mesh 下两者又统一收到 sidecar。
一句话：没有 LB 就没有弹性（伸缩靠它）和韧性（摘除靠它）。它和注册发现是一对搭档——发现解决"有谁"，LB 解决"给谁"。