nginx 实现 node.js 蓝绿发布与灰度切换的核心是反向代理配置：通过统一 upstream + weight 动态调比实现渐进灰度；用变量控制 upstream 切换实现秒级全量切换；借助 map 指令基于 header 或 cookie 实现定向灰度；并需配套健康检查、日志增强及接口兼容保障。
用 Nginx 实现 Node.js 应用的蓝绿发布与灰度流量切换，关键不在改 Node 代码，而在 Nginx 的反向代理配置方式——它把流量调度变成可配置、可观察、可回滚的操作。
统一 upstream + weight 动态调比（适合渐进灰度）
蓝版（v1）和绿版（v2）两个 Node 服务必须运行在不同地址或端口，比如 127.0.0.1:3000 和 127.0.0.1:3001。它们共用一个 upstream，靠 weight 控制比例：
- 初始上线时设为
weight=95（蓝）和weight=5（绿），只放 5% 流量到新版本 - 观察 access 日志、错误率、响应延迟后，逐步调高绿版 weight，比如 20→50→90
- 每次调整只需改配置 + 执行
nginx -s reload，不中断已有连接 - 建议搭配
max_fails=2 fail_timeout=30s做基础健康检查，避免把流量打到已挂的 Node 进程上
变量控制 upstream 切换（适合秒级蓝绿全量切换）
当需要快速倒换或紧急回滚时，不依赖权重渐变，而是直接切换主路由目标：
- 定义两个独立 upstream：
app_blue指向旧版 Node，app_green指向新版 Node - 在 server 块里用
set $active_env "blue";控制流向，proxy_pass http://app_$active_env; - 切流时只改这一行变量值，reload 后所有新请求立刻走新环境
- 配合 curl 探活脚本（如
curl -f http://127.0.0.1:3001/health）可自动校验绿版就绪后再执行切换
基于 Header 或 Cookie 的定向灰度（适合 AB 测试或内测）
如果你只想让特定用户或测试人员访问新版本，Nginx 原生支持条件路由：
- 用
map指令提取请求头：map $http_x_release_mode $backend { "canary" "app_green"; default "app_blue"; } - 再在 location 中写
proxy_pass http://$backend;，带X-Release-Mode: canary的请求就进绿版 - 也可用 cookie 实现类似效果：
map $cookie_canary $backend { "true" "app_green"; default "app_blue"; } - 这种方式不改变整体流量比例，但能精准控制谁看到新功能，适合内部验证或小范围试跑
配套动作不能少
光配对 upstream 不够，真实落地还要注意这几件事：
- Node 服务自身要暴露 /health 端点，返回 200 + JSON，方便 Nginx 或外部监控判断存活
- access log 加字段记录 upstream 地址，例如
log_format main '$remote_addr - $upstream_addr ...'，便于排查哪台 Node 处理了请求 - 所有 Node 实例保持相同 API 协议和数据结构，避免因接口不兼容导致 502/500
- 数据库变更需提前兼容（如字段新增加默认值、接口保留旧字段），不能等绿版切流后再改库
