最有效、最轻量的按需分流方式是直接使用weight参数，它不依赖额外模块，将硬件差异转化为可读可调的正整数比例；权重必须写在upstream块内server行后，仅对round_robin和ip_hash生效，需搭配max_fails/fail_timeout等健康检查机制才能可靠运行。
直接用 weight 参数是最有效、最轻量的按需分流方式。它不依赖额外模块，也不改变架构，把硬件或部署差异转化为可读、可调、可验证的整数比例。
权重必须写在 upstream 的 server 行里
weight 只能出现在 upstream 块中，紧跟在 server 地址之后：
- ✅ 正确：
server 192.168.1.10:8080 weight=5; - ❌ 错误：写在 location 或 proxy_pass 附近，Nginx 会报
unknown directive "weight" - ❌ 错误：绕过 upstream 直接 proxy_pass 到 IP，weight 完全失效
数值要反映真实能力，别靠猜
weight 不是百分比，而是相对比例。设得准，才能避免“新机闲着、老机打满”：
- 旧机性能约为新机 40%，就设
weight=4，不是weight=0.4（只接受正整数） - 避免用太小的数（如 1 和 2），推荐统一放大 10 倍——
10:4:2比5:2:1更易对齐实际流量 - 可参考实测 QPS、CPU 核心数或响应时间中位数折算权重
权重得配健康机制才可靠
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康检查，慢节点照样收请求：
- 加
max_fails=2 fail_timeout=30s：连续两次超时或拒绝连接，就暂停转发 - 故障期间，剩余健康节点会按各自 weight 重新归一化分担流量（例如原
5:3:2，C 下线后 A/B 变成5:3） - 新节点上线可用
slow_start=30s，让流量从 0 开始缓慢爬升，防冷启动冲击
按路径或特征做更细粒度分流
当同一台机器跑多个应用，或不同接口资源消耗差异大时，单靠 server 级 weight 不够：
- 用
location拆 upstream：用户中心走user_backend，订单服务走order_backend，互不抢资源 - 缓存类接口（如商品详情）可单独指向高权重、高缓存命中率的节点组
- 灰度发布时，用
backend_canary配置低权重（如weight=2）引流验证
