负载均衡原理：流量分发为什么不是“平均”这么简单

当一个服务有多个实例时，系统就要面临一个非常直接的问题：这一批请求应该发给谁。如果所有流量都打到同一个实例上，那扩容就失去了意义；如果实例之间分发策略不合理，即便节点数量不少，也可能出现有的机器很忙、有的机器很闲。

所以负载均衡虽然听起来像一个很熟悉的词，但它真正要解决的问题并不只是“把流量平均分掉”，而是让流量在当前系统状态下，以更合理的方式落到更合适的节点上。

负载均衡的核心从来不只是均匀，而是如何在可用性、性能、成本和稳定性之间找到更合适的分发策略。

为什么平均分配并不总是最优

很多人最先接触的负载均衡概念，通常是轮询。这个策略非常直观：每次请求按顺序分给下一个实例，看起来最公平。

但真实系统里，“公平”并不等于“最优”。

因为不同实例的处理能力可能不同，启动状态可能不同，机器负载可能不同，连接数也可能不同。如果完全不考虑这些运行时差异，单纯平均分配流量，就可能把本来就很脆弱的实例继续压垮。

所以负载均衡真正关心的，是系统当前的真实运行状态，而不是抽象上的整齐分配。

轮询适合节点能力比较接近、流量模型也比较稳定的场景。

随机分发实现简单，在实例数量足够多时也能达到比较自然的均摊效果。

加权分发则适合节点能力不完全一致的情况，例如某些机器配置更高，或者某些实例处于预热阶段，只希望先接一部分流量。

一致性哈希更适合需要会话黏性、缓存命中率或者按 key 路由的场景。它解决的不是平均问题，而是“同一类请求尽量打到同一类节点”。

你会发现，不同算法背后关注的目标并不一样，这也说明负载均衡本身就是一种权衡。

一个再好的分发算法，如果分到了坏节点上，也没有意义。

所以负载均衡通常不会单独存在，它必须和节点健康状态结合起来。只有先知道哪些节点可用，哪些节点应该暂时摘除，分发策略才有意义。

这也是为什么很多线上问题看起来像负载均衡异常，实际上根因却是健康检查滞后、摘除不及时或者恢复策略不合理。

它可以发生在很多层。

不同位置的负载均衡，掌握的信息不完全一样，适合解决的问题也不同。理解这一点很重要，因为很多治理能力其实会随着系统演进，从业务代码逐步下沉到基础设施层。

一个常见误区是把负载均衡理解成纯性能优化，好像它只是为了让吞吐更高。实际上它同时深度影响系统稳定性。

如果流量调度不合理，局部热点、实例雪崩、连接堆积、尾延迟放大这些问题都会更容易出现。所以负载均衡既是流量能力，也是稳定性能力。

假设你的某个服务现在有三个实例，其中一个实例刚启动完成，缓存还是冷的，另一个实例机器负载已经偏高。请你思考：如果继续完全轮询，会发生什么；如果改成加权分发，权重应该怎么设；如果某个实例健康检查失败，流量又该如何摘除。

这个练习的价值在于帮你意识到：负载均衡不是一个静态算法题，而是和运行时状态紧密耦合的工程问题。

负载均衡的目标不是机械地把流量平均切开，而是在节点能力、健康状态、调用特征和系统目标之间做更合理的分发。轮询、随机、加权、一致性哈希都只是手段，真正重要的是你是否理解：流量该如何进入系统、在系统里如何被调度，以及这种调度会对稳定性和性能产生什么影响。