权重配置需基于实测能力（如压测吞吐量）或资源估算（CPU/内存），配合健康检查（max_fails=3、fail_timeout=30s）与验证闭环（日志统计、响应头采样），并辅以least_conn、ip_hash等策略提升负载均衡精度。

权重配置是实现灰度发布和流量平滑切分最直接、最轻量的方式，但它不是“设个数字就完事”的简单操作——关键在于让权重真正反映后端承载力，并配合健康感知与验证闭环。

权重要基于实测能力，不能拍脑袋定

weight 不是版本号或优先级标签，而是对处理能力的量化表达。主观设 weight=100 或 weight=99 会导致调度失真：

• 压测法更可靠：用 wrk 或 ab 对每台实例单独压测，记录稳定吞吐量（如 A 实例 1800 req/s，B 实例 900 req/s），按比例取整得 weight=2 和 weight=1
• 资源粗估法可辅助：8 核服务器设 weight=8，4 核设 weight=4；32GB 内存可设 weight=16（按内存 GB/2 取整）
• 灰度初期建议用小跨度比值，比如新实例 weight=1、老实例 weight=9，天然实现约 10% 流量切入

必须绑定健康检查，否则权重会失效

一台机器响应变慢甚至卡在半路，Nginx 或 Dubbo 默认仍会按 weight 比例继续派请求过去。所以每条 upstream server 或 Dubbo provider 都要配故障探测：

• max_fails=3：连续 3 次超时或返回 5xx，标记为 down
• fail_timeout=30s：30 秒内不再转发，之后自动试探恢复
• 可加 down 手动下线维护中节点，或用 backup 标记灾备机（仅主池全不可用时启用）

单靠权重不够时，补策略提升真实负载匹配度

当后端响应时间差异大、存在长连接或耗时任务时，纯 weight 调度容易造成“分配了流量，但没释放连接”，实际负载不均衡：

• least_conn：优先发给当前活跃连接最少的后端，适合 WebSocket、HTTP/2 等长连接场景
• ip_hash：固定用户到同一台机器，适用于未做 session 共享的老系统
• Dubbo 场景下可叠加 标签路由（Tag Router），按环境（env=gray）、版本（v=2.1）等维度精准隔离灰度流量

配置生效后必须验证是否真按比例走量

reload 完只是第一步，不验证等于没调：

• 用 curl -I 多次请求，观察响应头中 Server 或 X-Backend 字段，统计各 IP 出现频次（采样 ≥1000 次）
• 查 Nginx access.log，用 awk + sort 统计 upstream_addr 字段分布：“awk '{print \$11}' access.log | sort | uniq -c | sort -nr”
• 允许 ±5% 偏差，但若新实例只收到 2% 流量（预期 10%），就要排查是否被健康检查踢出、日志路径写错、或 upstream 名称拼写错误