nginx通过weight实现静态流量比例控制，结合least_conn应对长连接、健康检查保障节点可用性、map+多upstream支持特征驱动分组调配，形成稳定灵活的负载均衡方案。
用 weight 实现基础流量比例控制
weight 是最直接有效的静态调配手段，数值代表节点相对处理能力。比如新服务器性能是旧服务器的 3 倍，就设 weight=3 vs weight=1，Nginx 会按比例长期分发请求。
- 配置简单：在 upstream 块中为每个 server 显式声明 weight，无需额外指令，默认生效
- 比例可算：三台节点 weight=4/2/1，理论请求占比约 57% / 29% / 14%
- 适合场景：灰度发布、异构集群（新老机器混布）、硬件能力差异明确的环境
搭配 least_conn 应对长连接或耗时请求
纯 weight 在文件上传、报表导出等耗时操作下容易造成连接堆积——某节点虽然权重高，但连接迟迟未释放，新请求仍被持续打过去。least_conn 能动态选连接数最少的节点，和 weight 协同更合理。
- 在 upstream 中添加 least_conn 指令（注意不能与 ip_hash 共存）
- 效果是：长期倾向高权重点，瞬时避开连接满载点
- 特别适用于 WebSocket、大文件接口、同步调用类服务
靠健康检查保障权重只作用于可用节点
再合理的权重，若打到故障节点也毫无意义。Nginx 的被动健康检查能自动剔除异常实例，让 weight 始终生效在健康节点上。
- 为每个 server 配置 max_fails=3 fail_timeout=30s，连续失败 3 次即临时下线 30 秒
- 在 location 中启用 proxy_next_upstream error timeout http_500–504，单次请求失败立即重试下一个节点
- 这样即使高权重点短暂变慢，流量也会自然倾斜，整体吞吐不受影响
用 map + 多 upstream 实现请求特征驱动的分组调配
如果“按需”是指按用户类型、设备、地域或接口路径分流，单纯 weight 不够用。map 指令可以提取请求特征，动态绑定不同 upstream，每个组内再设独立权重。
- 例如用 map $http_user_agent $backend_group 区分移动端和 PC 端
- 为移动端 upstream 设置 weight=5（适配轻量接口），PC 端设 weight=3（承载复杂页面）
- 转发时写 proxy_pass http://$backend_group，Nginx 自动路由
