least_conn策略是微服务架构中应对负载不均的关键手段，基于活跃连接数调度，适配异构节点、长连接协议及慢查询场景，并需配套健康检查、max_conns限流和keepalive配置。
least_conn 策略在微服务架构中不是“锦上添花”，而是应对真实负载不均的关键手段。它不依赖响应时间或 CPU 指标，只看每个后端实例当前还挂着多少活跃连接——这对微服务这种接口粒度细、耗时差异大、长连接普遍的环境特别对症。
适合微服务的典型场景
微服务之间调用常出现“小包高频 + 大包低频”混合流量，least_conn 能自然避开正在处理慢请求的实例：
- 异构服务节点混部：比如订单服务跑在 16C32G 物理机，而用户中心部署在 4C8G 容器里，轮询会很快压垮小规格实例；least_conn 让连接数始终向空闲资源倾斜
- 长连接协议大量使用：gRPC（HTTP/2）、WebSocket、SSE 接口维持连接数十秒至数分钟，连接堆积比请求数更真实反映压力，least_conn 直接基于这个维度调度
- 慢查询或同步任务干扰：某次报表导出接口耗时 8 秒，轮询可能连续把新请求打到同一台正忙的机器上；least_conn 在它连接数升高的瞬间就转向其他空闲实例
- API 网关层统一接入：Nginx 作为微服务统一入口，面对 /auth、/order、/payment 等不同路径的后端集群，每个集群内部用 least_conn，避免单个服务因局部热点拖垮整条链路
配置要点必须同步落地
单独加一行 least_conn 不足以发挥效果，微服务环境下需配套三项关键设置：
-
主动健康检查不可省略：微服务实例可能“假活”（进程没崩但卡死），仅靠超时重试无法及时剔除。建议配置
health_check interval=3s fails=2 passes=2，并用match校验 HTTP 状态码和关键响应头 -
max_conns 替代 weight 实现软性容量控制：Nginx 的 least_conn 不识别 weight，但可通过
server x.x.x.x max_conns=1500给高性能实例设更高上限，既保留动态调度优势，又体现承载力差异 -
upstream keepalive 必须开启：微服务间调用频繁复用连接，
keepalive 32（或按 worker 进程数匹配）能减少 TCP 握手开销；注意 keepalive 连接也计入活跃连接数，影响 least_conn 判断
要注意的现实约束
least_conn 在 Nginx 中是 per-worker 独立统计，不是全局精确值。在万级并发、worker 数较多时，可能出现短暂偏差——但这对微服务场景影响有限：
- 微服务调用链本身有重试和熔断机制，单次调度轻微不一致不会引发雪崩
- 只要各 worker 的连接分布整体趋近均衡，且健康检查及时更新状态，实际效果远优于轮询
- 若业务对一致性要求极高（如金融类强一致路由），可考虑 OpenResty + shared dict 自建全局连接计数，但多数微服务场景无需过度复杂化
