企业级加权轮询需兼顾流量合理性、稳定性、自愈性与可观察性，权重须基于实测qps设定且为正整数，必须绑定健康检查与slow_start，配置独立可审计，结合日志与监控闭环验证。
企业级加权轮询不是简单配个 weight 就完事，它需要兼顾流量分配合理性、服务稳定性、故障自愈能力和运维可观察性。核心是让权重真正反映后端服务能力，并在动态环境中持续可靠运行。
权重设定需匹配真实服务能力
权重不是拍脑袋定的数字，要基于可测量指标反推：
- 参考单机吞吐量（如 QPS 或并发连接数），若 A 机稳定支撑 600 QPS、B 机仅 200 QPS，初始权重比可设为 3:1
- 避免极端比例（如 1:50），否则低权值节点可能长期无流量，被监控系统误标为“失联”或触发自动下线
- 所有
weight必须为正整数，不支持小数、百分比或表达式（weight=0.8会直接报错） - 未声明 weight 的 server 默认为 1，混用时要统一显式写出，防止隐式差异引发理解偏差
必须绑定健康检查机制
加权轮询本身不判断后端是否存活，高权重节点宕机却仍在分发请求，后果更严重：
- 每个
server行必须带max_fails=3 fail_timeout=30s，表示连续失败 3 次后，30 秒内不再调度 - 对刚恢复的节点，建议叠加
slow_start=60s，让流量从 0 开始线性回升，避免重启即压垮 - 不要只依赖 passive 检查；关键业务应配合主动健康检查（如
health_check interval=5s fails=2 passes=2），但需注意该功能依赖ngx_http_upstream_health_check_module（通常需编译启用）
配置结构要满足可维护与可审计要求
企业环境强调变更留痕、多人协作和灰度发布能力：
- upstream 块统一放在
/etc/nginx/conf.d/upstreams/独立文件中，按业务域命名（如api-v2.upstream.conf） - 每行 server 后添加注释说明用途与依据，例如：
server 10.20.30.11:8080 weight=4; # 4C8G 实例，基准压测 QPS=800 - 禁止在 proxy_pass 中写路径（如
http://backend/api），路径应在 location 内统一控制，确保 upstream 定义纯粹做节点管理 - 上线前用
nginx -t校验，权重总和建议记录在部署文档中，便于容量复盘（如 “当前总权重=10，A占60%”）
结合日志与监控闭环验证效果
权重配得再合理，没数据反馈就是盲调：
- 开启 upstream 日志变量，在 access_log 中记录
$upstream_addr和$upstream_response_time，用于分析实际分发比例与响应分布 - 用 Prometheus + nginx-vts-exporter 或官方
ngx_http_stub_status_module指标，看各节点 request count 是否趋近理论权重比（允许 ±5% 波动） - 当某节点响应时间持续高于均值 2 倍，即使权重高也应人工介入：可能是 GC 频繁、DB 连接池打满等深层问题，不能只调低 weight 了事
