加权轮询灰度过渡需将新老服务器置于同一upstream块，v1与v2监听不同地址，设weight如20:1实现约4.8%流量切至v2；须配max_fails、fail_timeout、关键Header透传及健康检查，并通过nginx -t校验、-s reload热重载，监控5xx、响应时间，异常即置v2 weight=0回滚。
用 Nginx 的加权轮询实现新老服务器灰度过渡，核心是让流量按预设比例逐步从老版本（v1）切到新版本（v2），整个过程不中断服务、无需改业务代码、支持秒级回滚。
配置一个共用的 upstream 块
必须把新老后端定义在同一个 upstream 中，不能拆成两个独立 upstream。Nginx 才能按权重动态分发请求：
- v1 和 v2 必须监听不同地址：比如 v1 在 192.168.1.10:8080，v2 就得部署在 192.168.1.11:8080（或不同端口/域名）
- 权重填正整数，只看相对大小：起始推荐 v1 weight=20 / v2 weight=1（即约 4.8% 流量进新版本）
- 不要写百分比，也不用算总和；99:1 和 20:1 效果一致，但小基数更利于平滑调整
加上健康检查和关键头透传
光设 weight 不足以保障灰度稳定，还需配套机制：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 每个 server 行加上 max_fails=2 fail_timeout=30s，连续失败两次就临时剔除节点，避免故障拖累整体
- proxy_set_header 至少保留：X-Real-IP、Host、X-Forwarded-For，方便后端日志定位真实用户和版本归属
- 如果后端有会话依赖，注意 keepalive 连接复用可能导致实际分流比例漂移，可配合 slow_start 缓解
热重载生效 + 实时观测闭环
每次调权重都不是“改完就完”，要形成验证—监控—回滚闭环：
- 修改完配置先执行 nginx -t 校验语法，再 nginx -s reload 热重载，旧连接不受影响
- 紧盯新版本节点的 5xx 比例、平均响应时间、error_rate，而不是总 QPS；异常明显时立即把 v2 weight 设为 0 并 reload
- 建议用 curl 测试新版本 /health 接口确认可用性，再切流；切完后盯 5 分钟 access 日志，验证请求是否真实到达 v2
知道它能做什么、不能做什么
加权轮询是最轻量的灰度方式，但有明确边界：
- ✅ 支持按请求次数做整体比例分流，适合验证基础功能与稳定性
- ❌ 不保证同一用户始终打到同一版本（无会话保持）
- ❌ 不支持基于 Cookie、Header、用户 ID 或设备类型做精准路由
- ⚠️ 大流量下若新老响应延迟差异大，可能因连接复用导致实际比例偏离；此时需叠加 map 模块做条件路由，或改用 backup + 慢启动组合策略
