nginx集群实现基于权重的业务平滑切换需结合upstream weight、健康检查、灰度路由与可观测机制。权重控制流量概率分布，需reload生效且避免悬殊；必须配置健康检查防导流至异常节点；可用map或split_clients实现细粒度灰度；全程需监控qps、延迟、错误率并支持快速降权回滚。
用 Nginx 集群实现基于权重的业务平滑切换，核心是让流量按预设比例分发到不同后端，同时确保旧连接不中断、新节点逐步承接压力。这不是“一键切流”，而是一套需设计节奏、配套观测与响应机制的操作闭环。
用 upstream + weight 控制流量比例
权重是 Nginx 加权轮询的基础参数，默认为 1。它不决定绝对请求数，而是影响调度概率——例如两台服务器配置为 weight=80 和 weight=20，理论请求占比约为 80% 和 20%。
- 权重修改后必须执行
nginx -t && nginx -s reload才会生效，reload 不中断已有连接，只影响新建立的请求 - 避免权重悬殊过大（如 1:100），否则低权值节点可能长期无流量，失去健康检查意义
- 初始上线新服务时，建议从 weight=1 开始（老服务保持 weight=10），让其先承接约 9% 的流量
必须搭配健康检查，否则权重只是摆设
没有健康检查的权重调整，等于把流量主动导向可能未就绪或已异常的节点。Nginx 开源版虽无原生主动探测，但可通过以下方式补足：
- 在
server行中添加max_fails=2 fail_timeout=30s，配合proxy_next_upstream error timeout http_502实现基础被动摘除 - 使用
nginx_upstream_check_module等开源模块，配置独立健康探测路径（如/health?env=green），避免和业务接口耦合 - 新版本加入 upstream 后，先观察健康检查通过再提升权重，而不是“一加就切”
结合 map 或 split_clients 实现运行时灰度路由
单纯靠 reload 改权重适合阶段性切流，若需更细粒度（如按用户 ID、请求头、地域）实时分流，应引入变量路由：
- 用
map指令将请求特征映射为 upstream 名称，例如根据$http_x_version头决定走 blue 还是 green - 用
split_clients做哈希分流，比如按$arg_uid将 5% 用户固定导向新版本，便于定向验证 - 两种方式都支持不 reload 切换逻辑：改 map 规则或 split_clients 分配比例后 reload 即可秒级生效
切流过程要配套可观测与快速响应
权重调优不是调完就完事，关键在“看得到、判得准、回得快”：
- 所有后端服务统一打
version标签和 trace ID，确保监控大盘能分别统计蓝/绿两组的 QPS、P99 延迟、5xx 错误率 - 当 green 权重升至 20% 后错误率突增 >0.5%，立即降权（如 green:20 → green:5），而不是等全量失败再回滚
- 对新版本开启慢日志、SQL 审计等深度诊断能力；老版本保持轻量采集，形成对比基线
