nginx 通过 upstream 块中 server 的 weight 参数实现按服务能力加权分发，权重为正整数、默认1、呈相对比例关系，需经压测校准（qps÷响应时间）、上线后依cpu负载微调，并支持路径级差异化分流与定期验证。
直接用 weight 参数就能让 Nginx 按能力分发请求，不是玄学，而是可算、可控、可调的资源调度方式。关键不在于设多少，而在于怎么设得准、调得稳。
权重配置的核心写法
所有权重逻辑都写在 upstream 块里，语法简洁明确：
- 每台后端服务器用 server IP:端口 weight=N 定义，N 是正整数，默认为 1
- 权重值之间是相对比例关系，比如 weight=6 和 weight=2 等价于 weight=3 和 weight=1
- 未显式写 weight 的服务器，统一按 weight=1 计算总权重
- 支持同时搭配其他参数，如 max_fails=2 fail_timeout=30s（健康检查）、backup（备用机）
权重值怎么定才合理
不能拍脑袋填数字，得结合真实服务能力来校准：
- 先做压测：分别对每台后端服务器跑相同接口（如 /health 或 /api/test），记录 QPS 和平均响应时间
- 用 QPS ÷ 平均响应时间 粗略估算处理效率比，作为初始权重参考（例如 A 服务器效率是 B 的 2.5 倍，可设 weight=5 和 weight=2）
- 上线后观察实际负载（CPU、内存、连接数），微调权重使各节点 CPU 利用率尽量接近 60%–75%
- 避免极端值：单台权重超过总和 60% 容易形成瓶颈，低于 10% 则调度意义弱化
结合路径做差异化权重转发
同一套 upstream 可通过 location + proxy_pass 实现路径级分流，让不同业务走不同权重组合：
- 为静态资源单独建 upstream，配高权重（如 weight=5），因为它们轻量、缓存友好
- 为支付类关键 API 单独建 upstream，用更高权重 + 更严健康检查（如 fail_timeout=10s）
- 示例：访问 /api/pay/* 走 high-priority 组，/static/ 走 static-cache 组，/ 走默认组
- 注意：不要在同一个 location 内混用多个 proxy_pass，否则权重逻辑会失效
权重生效后的验证与维护
配置 reload 后必须验证是否真正按预期工作：
- 用 curl -I http://your-nginx-domain/ 多次请求，看响应头中 X-Upstream-Addr（需在 proxy_set_header 中添加）是否符合权重比例
- 开启 Nginx stub_status 模块，访问 /nginx-status 查看 active connections 和 upstream 状态
- 定期（建议每周）检查 access.log 中各后端 IP 的 request count，计算实际分发比是否偏离设定值 ±5% 以内
- 扩容新机器时，先设低权重（如 weight=1），观察 1 小时无异常后再逐步加到目标值
