负载均衡策略选择决策树

核心要点

选择负载均衡策略时，真正的问题不是”用不用负载均衡”，而是如何根据后端特征和流量模式选择决策算法。Traefik 的四种服务器级策略覆盖了从最简单到最复杂的全部场景，且可以与服务级策略（加权、镜像、故障转移）组合使用。

WRR 是 Traefik 的默认策略，它的真正价值不是”公平”，而是可预测性。当你发送 300 个请求到三台同构服务器，每台处理约 100 个——这种确定性让容量规划和故障排查变得简单。

加权版本用于异构硬件：一台大机器配 weight=4，小机器配 weight=1，流量按 4:1 分配。但权重是静态配置，不会根据实时负载调整。所以当后端性能差异是动态变化的时候，WRR 就会失效。

P2C 的算法极其简单：随机选两台服务器，比较活跃连接数，路由到较少的那台。但它解决了一个 WRR 无法处理的问题：连接生命周期高度可变。

典型场景是实时协作平台（如 Figma、Google Docs）：

WRR 会让某台服务器堆积大量长连接，而其他服务器 idle。P2C 通过比较活跃连接数，让新连接自然流向负载较轻的实例。

局限：P2C 只看连接数，不看处理时间。一台处理 10 个轻量请求的服务器，和一台处理 10 个重请求的服务器，在 P2C 眼里是一样的。

HRW（Rendezvous hashing）用客户端 IP 计算哈希，确定性地把同一客户端映射到同一后端。当后端有本地缓存时，这能显著提高缓存命中率。

关键特性：当服务器增减时，只有约 1/N 的客户端需要重新映射（N 为服务器总数），而简单取模哈希会导致 100% 重新映射。这个特性对缓存预热成本高的系统至关重要。

风险：如果某个客户端产生 disproportionate 流量，其对应的后端会成为热点。HRW 优先考虑一致性而非负载均衡的完美性。

Least-Time 是唯一同时考虑响应时间和活跃连接数的策略。它计算每台服务器的 score（基于近期 TTFB 和活跃连接），路由到 score 最低的服务器。

这个策略对混合实例类型的场景几乎是必需的：

WRR 会让用户随机体验到 5ms、15ms 或 50ms；Least-Time 会自动把更多流量发给快的服务器，当慢服务器恢复时流量自然回流。结合权重还可以表达容量差异：weight=3 表示这台服务器在 score 变劣前可以承受 3 倍流量。

Traefik 允许在服务级和服务器级同时使用不同策略：

最复杂的组合示例：服务级用 WRR 做金丝雀（90% v1 + 10% v2），每个版本内部再用 Least-Time 在服务器间做性能自适应路由。