Nginx 配置权重参数优化多版本并行部署的流量分发

Nginx 的 weight 参数通过相对权重比例实现多版本流量分配，适用于灰度发布等渐进导流场景；需配合 map 动态路由、健康检查及重载生效机制，weight 为正整数且支持 weight=0（1.9.1+），非百分比。

用 Nginx 的 weight 参数做多版本并行部署，本质是靠权重控制流量比例，而不是“切换开关”。它适合灰度发布、蓝绿过渡这类需要渐进式导流的场景，不依赖额外组件，但需配合路由逻辑和健康检查才能真正落地。

明确 upstream 中各版本的权重分配逻辑

weight 不是百分比，而是相对比例。比如 blue 版本设为 weight=8，green 设为 weight=2，实际分流比就是 8:2（即 80%→blue，20%→green）。关键点在于：

1. 所有 weight 值需为正整数，Nginx 内部按总和归一化计算概率
2. 避免极端值（如 100 和 1），否则小权重节点可能长期收不到请求
3. 若某版本暂不对外服务，可设 weight=0（Nginx 1.9.1+ 支持），旧版本可用 backup 或极低权重（如 1）替代

用 map 指令实现运行时动态路由

仅靠 weight 无法按需切换目标，必须引入变量驱动路由。常见做法是用 map 将请求特征映射为 upstream 名称：

1. 根据请求头（如 X-Deploy-Phase: green）选择后端分组
2. 也可基于 cookie、URL 参数或 IP 段做映射，例如 map $arg_version $upstream_name { "v1" "backend_v1"; "v2" "backend_v2"; }
3. map 必须定义在 http 块顶层，不能嵌套在 server 或 location 内

配合健康检查与平滑下线机制

权重只是调度依据，真实可用性要靠探测保障：

1. 为每个 server 加上 max_fails=3 fail_timeout=30s，自动隔离异常节点
2. 上线新版本前，先将 green 的 weight 设为较小值（如 5），观察日志和错误率
3. 下线旧版本时，逐步把 blue 的 weight 降为 0，再移除配置或保留作 fallback
4. 建议搭配 least_conn 或 ip_hash 等算法使用，避免权重与连接状态冲突

权重调整后必须重载生效

Nginx 不支持热更新 weight 值，每次修改都要触发配置重载：

1. 执行 nginx -t 验证语法正确性
2. 再执行 nginx -s reload 平滑加载新配置（不中断现有连接）
3. 生产环境建议加监控：用 stub_status 或 Prometheus exporter 跟踪各 upstream 的请求计数，验证分流是否符合预期