权重分配不等于流量平摊，需结合健康检查、连接策略与可观测性；weight仅表比例，应基于压测吞吐或硬件资源设定，避免极端比值，并搭配max_fails、proxy_next_upstream等机制提升容错。
权重分配本身不等于流量平摊，它只是按请求数做比例分发。想让多后端业务真正“平摊”，得把 weight 当作起点，再叠加健康检查、连接策略和可观测性，否则容易出现一台 CPU 95%、另一台空闲却还在收请求的情况。
权重设置要基于可测指标，不是凭感觉
weight 值只看比值，没有单位。设成 100 和 1 比设成 4 和 1 效果一样，关键在比例是否反映真实承载力：
- 压测单节点：用 wrk 或 ab 测出各后端在相同并发下的吞吐（req/s）和平均延迟，按吞吐比设 weight（如 A:1200 req/s，B:300 req/s → weight=4:1）
- 按硬件资源粗估：16 核、8 核、4 核服务器可设 weight=4:2:1，但需后续验证实际负载是否匹配
- 避免极端值：weight=1 和 weight=99 这类悬殊配置会放大调度偏差，建议最大比值控制在 1:5 以内
必须搭配健康检查，否则权重再准也失效
没健康检查的 weight 就像给故障车配高速轮胎——方向错了，跑得越快越危险：
- 加 max_fails 和 fail_timeout：例如 max_fails=3 fail_timeout=30s，连续失败 3 次就暂停转发，30 秒后重试
- 配合 proxy_next_upstream：当后端返回 500/502/504 或超时，自动转发到下一个 upstream server，提升容错
- 新节点上线时先设低 weight（如 1），等日志确认稳定后再逐步调高，防止冷启动冲击
单一轮询不够，得按场景选补充策略
纯 weight+round_robin 只适合短连接、无状态服务。其他情况需要组合策略：
- 长连接或 WebSocket 场景：启用 least_conn，优先发给当前连接数最少的节点，防堆积
- 需登录态保持：用 ip_hash 或 hash $cookie_session_id consistent，保证用户固定落在同一后端
- 跨机房部署：按带宽和 RT 反向设权（如北京总权 40，广州总权 12），再配合 upstream_hash 锁定机房内路由
真要动态适配，得靠外部机制补足
开源 Nginx 的 weight 是静态的，reload 才生效。想根据 CPU、响应时间实时调权，必须引入外部协同：
- 用 nginx-upsync-module + Consul/etcd：配置中心改权重，Nginx 每 300ms 自动拉取，毫秒级生效
- 用 OpenResty + Lua：定时探测后端 P95 延迟，按公式 weight = base × (ref_rt / actual_rt)² 动态计算并选节点
- 用 nginx-upstream-dynamic-servers + HTTP API：脚本读 Prometheus 指标，每分钟 POST 新权重，轻量易落地
