加权轮询实现灰度发布需四层协同：权重设最小整数比（如19:1）、独立upstream隔离流量、map动态路由、健康检查保底，并通过响应头与日志验证分流精度。
用加权轮询实现灰度发布的流量精准控制，关键不是“设个 weight 就完事”，而是把权重当作比例起点，再叠加识别、隔离、探测和验证四层动作。它轻量，但不粗糙；简单，但有细节门槛。
权重设置要讲比例，不讲绝对值
weight 不是百分比，也不代表具体请求数，只表达节点之间的相对服务能力。比如想让新版本（v2）承接 5% 流量，老版本（v1）承接 95%，不能直接写 weight=5 和 weight=95——数值越大，Nginx 在连接复用或请求批次调度中越容易出现统计偏差。
- 推荐用最小整数比：v1 设
weight=19，v2 设weight=1，等效于 95% : 5% - 若需 10% 切入，用
weight=9和weight=1，比90/10更稳定 - 避免悬殊过大（如 1 和 100），小权重节点可能几十秒收不到请求，失去灰度意义
必须独立定义 upstream，防止流量混流
灰度和稳定服务不能共用同一个 upstream 块。否则一旦灰度节点健康检查失败，Nginx 会自动把本该丢弃的请求 fallback 到稳定节点，闭环就断了。
- 为灰度集群单独建
upstream canary { server 10.0.1.20:8080; } - 为稳定集群单独建
upstream stable { server 10.0.1.10:8080; } - 用
map或if + set明确路由目标，例如：map $http_x_release_stage $upstream_group { "canary" "canary"; default "stable"; }
再通过proxy_pass http://$upstream_group;动态选择
健康检查不是可选项，是保底安全线
哪怕权重配得再准，如果某台灰度机器响应慢到 3 秒才返回 200，Nginx 仍会按比例继续发请求过去——直到它超时或出错。所以每行 server 必须带探测参数：
-
max_fails=3：连续 3 次超时或 5xx，标记为 down -
fail_timeout=30s：30 秒内不再转发，之后自动试探恢复 - 可配合
down手动下线维护中的节点，或用backup标记灾备机
上线后必须验证真实分流效果
reload 配置只是第一步。实际是否真按 19:1 走量，得靠日志和响应头交叉验证：
- 在后端响应头中加入标识，如
X-Backend: v1或X-Backend: v2 - 用
curl -I发 1000 次请求，统计各标识出现频次（允许 ±5% 偏差） - 查 Nginx access.log，用
awk '{print $NF}' | sort | uniq -c统计upstream_addr分布
