加权轮询是微服务网关适配异构节点最常用且可控的负载策略，需按硬件资源设初始权重、结合健康检查动态衰减、用监控数据反向校准，并避开ip_hash冲突等常见陷阱。
加权轮询是微服务网关中适配异构节点最常用、也最可控的负载策略。优化权重不是简单调大数字，而是让权重真实反映后端实例的实际服务能力，并随运行状态动态适配。
按硬件资源合理设初始权重
权重应与关键硬件指标对齐，避免拍脑袋设置。常见做法是：
- CPU核心数直接映射：8核机器设 weight=8，4核设 weight=4
- 内存容量可作辅助参考：若两台CPU相同但内存差一倍（如16GB vs 32GB），后者权重可上浮20%~30%
- 新上线服务实例建议保守起步：weight=1，观察30分钟CPU、响应延迟、错误率后再逐步上调
结合健康检查做权重衰减
静态权重无法应对突发抖动。建议在 server 行中叠加容错参数，实现软降权：
- max_fails=2 fail_timeout=15s：连续2次健康检查失败，15秒内不再派发新请求
- 配合 slow_start=30s（Nginx 1.11.5+）：恢复后渐进式提升流量，避免冷启动冲击
- 不推荐直接删节点，用权重归零（weight=0）临时隔离，便于快速回切
用监控数据反向校准权重
真实负载比理论配置更重要。定期看三项指标并调整：
- 平均响应时间：某实例RT持续高于均值30%，权重下调20%
- 5xx错误率：错误率＞0.5%且持续5分钟，权重减半；＞2%则置为0
- CPU/内存使用率：长期＞85%的实例，权重降低；＜40%且RT稳定，可适度加权
避免常见权重陷阱
几个容易被忽略但影响显著的细节：
- 权重只在本轮调度周期内生效，Nginx 不会“记住”历史分配比例，所以总权重和无需归一化（3+2+1 和 30+20+10 效果一致）
- 不要混用 ip_hash 和 weight：ip_hash 本身不支持权重，开启后 weight 参数被忽略
- 若用 Prometheus + Grafana 监控，可写规则自动告警“权重偏差＞40%且RT偏差＞50%”，触发人工复核
