Nginx的weight参数是后端服务能力的相对比值表达，非百分比或绝对值，默认为1，0表示临时下线；需配合健康检查与合理范围（1–100）设置，并避免与ip_hash等策略混用，动态权重需依托可观测性实现。
权重是服务能力的数字化表达
weight 不是百分比，也不是绝对值，而是相对能力比。一台 CPU 核心数翻倍、内存带宽提升 1.5 倍的服务器，综合服务能力大约是旧机器的 2–3 倍，对应 weight 可设为 6:2 或 9:3，而非生硬写成 100:33。
- 默认所有节点 weight=1；未显式配置即按均等轮询处理
- weight=0 表示临时下线，不参与请求分发，但仍接受健康检查探测
- Nginx 自动归一化：weight=4 和 weight=2 等价于 2:1，实际流量占比约为 66.7% : 33.3%
- 数值建议控制在 1–100 范围内，避免过小（如 2 和 1）导致微小误差被放大
按业务角色设定差异化权重
不同后端承担的角色不同，权重应体现其定位，而非仅看硬件。
- 主力服务节点：高配、稳定、承载核心逻辑，weight 设为最高（如 8–10），并搭配 max_fails=3 fail_timeout=45s，容忍短暂抖动
- 缓存加速节点：响应快但容量有限，适合高频轻量请求，weight 可设中等（如 4–6），slow_start=15s 避免冷启动压垮
- 灾备/降级节点：仅主集群全部不可用时启用，用 backup 标记，weight 不生效，也不参与常规调度
- 灰度/新版本节点：初期只承接少量真实流量，weight 设低（如 1–2），配合 slow_start=60s 平稳放量
必须配套健康检查，否则权重失去意义
权重只在“正常运行”前提下起作用。没有健康检查，一台响应延迟飙升到 5 秒的节点，仍会按原权重持续收请求。
- 每个 server 行建议加上 max_fails=2 fail_timeout=30s，连续失败两次即隔离 30 秒
- 避免与 ip_hash 或 hash $request_uri 混用——这些策略会覆盖 weight，导致负载完全失衡
- proxy_pass 必须引用 upstream 名称（如 http://my_backend），不能直写 IP，否则权重失效
进阶：让权重随真实表现动态浮动
静态 weight 适合稳态环境；若后端性能波动大（如突发流量、GC 暂停），需引入动态机制：
- 用 OpenResty + Lua，每 3–5 秒探测 P95 延迟，按公式 weight = floor(10 × (基准延迟 / 实际延迟)¹·⁵) 实时重算
- 或接入 Consul/etcd，由外部监控系统（如 Prometheus + Alertmanager）驱动权重变更，Nginx 通过 nginx-upsync-module 自动拉取
- 所有动态方案都依赖可观测性：access_log 中固定记录 $upstream_addr $upstream_response_time，确保权重调整有据可依
