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）。关键点在于：
- 所有 weight 值需为正整数，Nginx 内部按总和归一化计算概率
- 避免极端值（如 100 和 1），否则小权重节点可能长期收不到请求
- 若某版本暂不对外服务，可设
weight=0（Nginx 1.9.1+ 支持），旧版本可用backup或极低权重（如 1）替代
用 map 指令实现运行时动态路由
仅靠 weight 无法按需切换目标，必须引入变量驱动路由。常见做法是用 map 将请求特征映射为 upstream 名称：
- 根据请求头（如
X-Deploy-Phase: green）选择后端分组 - 也可基于 cookie、URL 参数或 IP 段做映射，例如
map $arg_version $upstream_name { "v1" "backend_v1"; "v2" "backend_v2"; } - map 必须定义在 http 块顶层，不能嵌套在 server 或 location 内
配合健康检查与平滑下线机制
权重只是调度依据，真实可用性要靠探测保障：
- 为每个 server 加上
max_fails=3 fail_timeout=30s，自动隔离异常节点 - 上线新版本前，先将 green 的 weight 设为较小值（如 5），观察日志和错误率
- 下线旧版本时，逐步把 blue 的 weight 降为 0，再移除配置或保留作 fallback
- 建议搭配
least_conn或ip_hash等算法使用，避免权重与连接状态冲突
权重调整后必须重载生效
Nginx 不支持热更新 weight 值，每次修改都要触发配置重载：
- 执行
nginx -t验证语法正确性 - 再执行
nginx -s reload平滑加载新配置（不中断现有连接） - 生产环境建议加监控：用
stub_status或 Prometheus exporter 跟踪各 upstream 的请求计数，验证分流是否符合预期
