灰度发布和蓝绿部署均为不中断上线策略，Nginx通过配置实现流量调度：灰度按特征（Header/Cookie/IP）分流验证新版本，蓝绿通过变量切换两套独立upstream实现秒级全量切换，需注意map位置、proxy_pass变量兼容性及避免滥用if。
灰度发布和蓝绿部署本质都是“不中断上线”的策略，Nginx 作为反向代理层，无需改动业务代码，靠配置就能实现流量的精准调度与快速切换。
灰度发布：按特征分流，小范围验证
核心是让一部分用户看到新版本，其余走旧版。关键在“识别+路由”，推荐用 map 指令，稳定且可读性强。
-
基于请求头（Header）：前端或测试工具加
X-Release: v2，Nginx 提前映射：map $http_x_release $upstream_backend { "v2" "backend-canary"; default "backend-stable"; } -
基于 Cookie：适合固定用户长期走灰度，例如内部员工。提取
uid或自定义键：map $cookie_uid $backend_group { ~^(abc123|def456)$ "gray"; default "old"; } -
基于客户端 IP：内网办公网段全部进灰度，配置简单直接：
geo $ip_is_gray { default 0; 192.168.10.0/24 1; } map $ip_is_gray $upstream_backend { 1 "backend-gray"; 0 "backend-stable"; } - 组合使用更稳妥：比如先按 IP 放行内网，再对公网请求按 Cookie 二次筛选，避免规则冲突。
蓝绿部署：两套环境，秒级切换
蓝绿是全量切换，不是渐进式。重点在于隔离、可回滚、无感知——Nginx 只需改一个变量或 upstream 指向，即可完成切换。
-
定义两套独立 upstream：
upstream app_blue { server 10.0.1.10:8080; } upstream app_green { server 10.0.1.20:8080; } -
用变量控制主路由：把后端选择抽象成变量，方便一键切换：
set $active_env "blue"; # 切换时只需改这一行 proxy_pass http://app_$active_env; -
配合健康检查更可靠：为每个 upstream 加
health_check或用第三方模块（如 nginx_upstream_check_module），确保目标服务可用后再切流。 - 回滚就是改回变量值 + reload：整个过程毫秒级，比重启应用快得多，也比滚动更新更可控。
配置落地注意事项
Nginx 的灵活性强，但几个细节容易踩坑，直接影响稳定性。
- map 必须写在 http 块顶层，不能嵌套在 server 或 location 里；
- proxy_pass 中拼接变量要求 Nginx ≥ 1.3.10，低版本需用 if + rewrite 替代，但不推荐；
- 避免滥用 if：尤其不要在 location 外用 if 判断请求头或 Cookie，易引发不可预期行为；
- 建议搭配宝塔等可视化面板管理：修改配置后一键重载，支持备份与历史版本对比，降低误操作风险；
- 上线前务必做真实请求验证：用 curl 模拟不同 Header/Cookie/IP，确认路由结果符合预期。
进阶方向：动态化与可观测性
当灰度策略变复杂（比如按用户画像、地域、设备类型分流），纯静态配置会难维护。
- 引入 OpenResty + Lua，实现运行时逻辑判断，比如调用内部鉴权服务决定路由；
- 结合 Consul 或 etcd 实现上游服务自动注册与发现，灰度组可动态增删；
- 在 proxy_pass 前加日志记录
$upstream_backend，配合 ELK 或 Prometheus，实时看灰度流量占比与错误率。
