负载均衡、健康检查和会话保持怎么设计

Nginx 做反向代理时，这三个点经常一起出现，但它们分别解决不同问题：负载均衡负责分流，健康检查负责摘除故障节点，会话保持负责减少有状态请求漂移。

先说结论

• 先保证节点能被及时摘除，再谈流量分配策略
• 业务能无状态就尽量无状态，少依赖会话保持
• 负载策略要和后端处理能力、连接模型一起看，不能只图“均匀”
• 健康检查不能只看端口通不通，最好能覆盖接口级探活和超时治理

一、先分清这三件事分别在解决什么

负载均衡在解决什么

它解决的是请求如何分配到多个上游节点。常见策略有轮询、加权轮询、least_conn、ip_hash。没有绝对最优，只有更适合当前流量模型。

健康检查在解决什么

健康检查负责及时发现坏节点，避免请求继续打到已经超时、假活或半故障的实例上。没有健康检查的负载均衡，往往只能做到“平均分发错误”。

会话保持什么时候才需要

只有当后端还依赖本地 Session、粘性缓存或节点本地状态时，才需要考虑会话保持。更理想的做法通常是把状态外置到 Redis、数据库或统一会话服务。

二、实战里怎么设计

先决定后端是否无状态

如果能做到无状态，优先放弃 session stickiness，系统扩容、缩容和故障切换都会简单很多。

再选负载策略

• 请求耗时接近时，轮询或加权轮询就够用
• 长连接多、请求耗时差异大时，可以考虑 least_conn
• 必须按来源保持稳定路由时，才考虑 ip_hash

最后补健康检查与超时治理

健康检查不能只看端口通不通，最好结合接口级探活、失败阈值和超时配置。很多节点“能连上”不代表“还能正常服务”。

三、几种常见场景更适合怎么选

1. 普通 Web 服务

大多数情况下，轮询或加权轮询就够用，重点放在超时、失败摘除和无状态化。

2. 长连接或耗时差异很大的服务

更适合考虑 least_conn，避免少数节点被长请求长期占住。

3. 还没做无状态改造的旧系统

可以短期用 ip_hash 或上游会话保持兜底，但要明确这是过渡方案，不是长期目标。

四、常见误区

只配 upstream，不配失败摘除

节点挂了还持续分流，故障会迅速放大。

把会话保持当成默认方案

这会让后端越来越难做弹性扩容，也会让单节点热点更明显。

负载均衡策略一劳永逸

上线初期适合轮询，业务增长后未必还合适。要根据连接数、RT 和失败率持续调整。

五、上线后至少看哪些指标

• 上游节点 RT
• 5xx 比例
• upstream 失败次数
• 节点连接数分布
• 会话漂移或登录异常比例

总结

先保证故障节点能快速摘除，再根据流量模型选负载策略，最后尽量把会话状态从应用节点剥离出去，这套顺序更稳。