零停机后端切换通过Nginx upstream动态权重、健康检查与热重载实现：新旧版本共存于同一upstream，仅调weight渐进放量；max_fails/fail_timeout自动摘除异常节点；reload前校验+备份配置，配合map可实现按请求特征精准路由。
在自动化发布流水线中用 Nginx upstream 实现零停机后端切换，核心是把“流量调度”从手动操作变成可编程、可验证、可回滚的配置动作。不依赖重启，也不靠改代码，而是通过 upstream 的动态权重、健康状态感知和热重载机制，在秒级内完成新旧版本平滑过渡。
统一 upstream + 动态 weight 控制灰度比例
蓝绿或金丝雀发布的关键前提，是新旧版本共存于同一个 upstream 块里，仅靠 weight 分流：
- 避免拆成 backend-v1 和 backend-v2 两个独立 upstream——那样只能全量切，无法渐进
- 示例配置：
upstream app_backend {
server 10.0.1.10:8080 weight=95; # 蓝（主版本）
server 10.0.1.20:8080 weight=5; # 绿（新版本，初始 5%）
} - CI 流水线中只需更新 weight 值（如从 5→20→50→100），再执行 reload，即可控制放量节奏
- weight 变更无需重启 worker 进程，nginx -s reload 后新连接立即按新权重分发
健康检查 + max_fails/fail_timeout 自动摘除异常节点
光调权重不够，必须让 Nginx 主动识别并绕过不可用实例：
- 每个 server 行加上 max_fails=3 fail_timeout=30s：连续失败 3 次，30 秒内不再转发请求
- 配合应用层 /health 接口，在 CI 部署新版本后自动 curl 测试：
curl -f http://10.0.1.20:8080/health || exit 1，失败则中断流水线 - 若使用 Nginx Plus 或 OpenResty，可用 health_check interval=5 fails=2 passes=2 实现 HTTP 层主动探测
配置热重载 + 自动化校验闭环
reload 是零停机的命脉，但必须防手误、保安全：
- CI 脚本中强制两步：
nginx -t -c /etc/nginx/nginx.conf && nginx -s reload
缺一不可，-t 失败直接终止发布 - 每次 reload 前备份当前配置：
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%s) - 推荐将 upstream 地址抽离为独立文件（如 conf.d/upstreams.conf），CI 只更新该文件并 reload，降低主配置误改风险
按需路由增强：map + 请求特征实现精准引流
当需要给测试人员、内测用户或特定 Header 流量直连新版本时，可叠加 map 动态路由：
- 在 http 块定义：
map $http_x_env $target_upstream {
default app_backend_blue;
"green" app_backend_green;
} - location 中：
proxy_pass http://$target_upstream; - 这样既保留全局 weight 控制，又支持指定请求头、Cookie 或域名走绿色通道，互不干扰
