关键在于按实际处理能力动态分配weight而非新旧机器定权，需结合实测qps、cpu/内存/i/o等指标设初始值，并通过动态监控与自动降权、max_fails、slow_start等指令协同保障稳定。
让不同代际的服务器平稳共存，关键不是“让老机器别挂”，而是“让每台机器干它该干的活”。weight 参数就是这个调度杠杆——它不改变硬件，但能决定流量怎么分。
按能力定权重，而不是按新旧定权重
新服务器未必总该配高权重，旧服务器也未必只能低权重跑。重点看当前真实处理能力：
- 以 CPU 核心数为基准：16 核设为 8，8 核设为 4，4 核设为 2
- 内存影响明显时（如 Java 应用堆大）：64GB 对应 weight=8，32GB 对应 weight=4
- 若某台旧机换装 NVMe 硬盘、I/O 延迟下降 40%，可在原权重基础上加 0.5～1（如从 4 调到 4.5），但建议统一用整数，后续改 5 更稳妥
- 上线前务必实测：用 wrk 对每台后端压出稳定 QPS，按比例设 weight（如 A 机 1500 QPS、B 机 600 QPS → weight 比例约 5:2）
防止静态权重在运行中失效
一台标称 weight=8 的高配服务器，CPU 持续超 85% 后，实际吞吐可能只剩一半。这时权重还维持高位，等于主动往火坑里导流。
- 必须搭配动态反馈：采集 CPU 使用率、平均响应时间、5xx 错误率、连接排队长度
- 设定自动降权规则：例如某节点 CPU > 80% 持续 2 分钟，权重临时减半；恢复至 60% 并稳定 5 分钟后，再逐步回升
- Nginx 原生不支持运行时改 weight，需借助 nginx-upstream-check-module 或外部控制器（如 Consul Template + reload）实现闭环
- 磁盘 I/O 飙高但 CPU 正常？单独监控 iowait，超阈值即触发临时降权，避免拖慢整体响应
用配套指令兜住单点风险
weight 只管“谁该多干活”，不管“干不动了怎么办”。必须组合使用其他 upstream 指令：
- max_fails=2 fail_timeout=30s：连续两次超时或拒绝连接，就暂停转发，30 秒内不重试
- slow_start=30s：刚恢复或新加入的节点，30 秒内流量从 0 缓慢升到 full，防冷启动冲击
- backup：灾备机器只在全部主力节点不可用时启用，不参与日常权重分配
- down：计划维护时直接标记 down，无需注释配置，重启也不生效
验证是否真平稳，不能只看 Nginx 日志
配置写了不等于效果到了。要交叉验证三类数据：
- 看 Nginx 实际分发：启用 stub_status 或接入 nginx-exporter，查各 upstream server 的 requests 计数，比对是否接近 weight 比例（如 weight=5:3:2，实际请求比应在 4.8:2.9:2.3 范围内）
- 看后端真实水位：对比各节点的 CPU 使用率、P95 响应时间、活跃连接数，若高权重节点延迟显著高于低权重节点，说明它已过载，权重设高了
- 看业务指标：错误率、缓存命中率、下游依赖超时率是否同步恶化——有时负载没倾斜，但某台机器网络抖动或时钟不同步，也会引发连锁异常
