Nginx 借助权重实现后端集群的弹性流量扩容

权重是扩容平稳落地的关键开关，需通过低初始权重、渐进调权、健康检查联动及能力匹配的权重比值，实现灰度承接与流量精准分发。

权重本身不扩容，但它是让扩容“弹起来”的关键开关。新节点加进去不等于能立刻扛流量，得靠权重从低到高逐步放开，才能既压测真实能力，又不拖垮整体服务。

初始低权重接入，避开冷启动雷区

新机器刚上线时，JVM 还没热、缓存是空的、连接池没建满，直接给高权重容易引发超时和 502。稳妥做法是：
– 新节点设 weight=1（或更低），老节点保持原有权重（如 weight=10）
– 配置写进 upstream 后执行 nginx -t && nginx -s reload，新 server 立即参与轮询，但只分到极小比例流量
– 观察 5–10 分钟：看 access_log 中 $upstream_response_time、错误率、后端 CPU 是否平稳

渐进调权 + 自动 reload，实现灰度式承接

确认稳定后，不是一步到位拉满，而是分阶段提升权重，让系统在真实流量中持续验证：
– 手动或脚本控制，例如每 5 分钟执行一次：把 weight 从 1 → 3 → 6 → 10
– 每次修改后都必须 reload，Nginx 会平滑切换 worker，旧连接不受影响
– 若对接 Consul/etcd，可设定规则：健康检查连续通过 3 次后，自动更新 weight 并触发 reload

权重要配合健康检查才真正可控

没有探测机制的权重，等于把请求随机扔向可能已挂的服务：
– 每个 server 行加上 max_fails=2 fail_timeout=30s，Nginx 会基于 proxy_pass 的响应状态做被动健康判断
– 配合 proxy_next_upstream error timeout http_502 http_503，单次失败自动转到下一个节点
– 推荐用业务健康接口（如 /health 或 /actuator/health）而非 TCP 探活，确保数据库、下游依赖也在线

长期权重分配要反映真实处理能力

扩容不是加机器就完事，而是让整体吞吐线性增长。权重比值决定长周期内理论流量占比：
– 三台老机器 weight=5、5、5，新增一台高配机 weight=10 → 四台实际分摊比为 5:5:5:10 ≈ 20% : 20% : 20% : 40%
– 权重归一化生效，weight=2 和 weight=8 等价于 1 和 4，重点看相对大小
– 建议以压测 QPS 或 P95 响应时间为基准定权值，而不是拍脑袋按 CPU 核数配