蓝绿发布通过流量切换实现无感知部署，核心是路由控制、版本隔离与快速回滚；需双栈服务+七层网关（如Nginx），配置upstream指向蓝/绿环境，发布时验证→切流→观测，异常则秒级回滚，辅以自动化告警、Git化配置、Header标识、数据库向前兼容及静态资源哈希。

蓝绿发布在 Linux 环境下实现无感知部署，核心是通过流量切换而非停机更新，保障服务连续性。关键不在于“多一套环境”，而在于路由控制、版本隔离和快速回滚能力。

环境准备：双栈服务 + 流量网关

需提前部署两套独立的服务实例（蓝环境与绿环境），监听不同端口或 IP，但共用同一域名。推荐使用 Nginx 或 Traefik 作为七层网关，避免直接操作 DNS 或客户端负载均衡器——延迟高、不可控。

• 蓝环境运行 v1.0，绑定 upstream 名为 blue，监听 8081

• 绿环境部署 v1.1，upstream 名为 green，监听 8082
• Nginx 配置中仅将 default upstream 指向当前生产组，如 proxy_pass http://blue;

发布流程：三步完成平滑切换

发布不是“启动新版本再关旧版”，而是“验证新版本 → 切流量 → 观察指标”，全程无需重启进程或中断连接。

• 先启动绿环境，调用其健康接口（如 /healthz）确认就绪
• 修改 Nginx upstream 指向 green，执行 nginx -s reload（毫秒级生效，已有连接不受影响）
• 观察 2–5 分钟：错误率、响应延迟、日志关键词（如 v1.1）、CPU/内存趋势

回滚机制：比发布更快的关键保障

一旦发现异常，回滚不是重跑部署脚本，而是秒级切回原 upstream，并保留绿环境待查。重点在于自动化验证和阈值告警。

• 预设 Prometheus 告警规则：5xx 错误率 > 0.5% 或 P99 延迟突增 200ms 持续 60 秒，自动触发回滚脚本
• 回滚脚本只需改一行配置 + reload，建议封装为单条命令，如 deploy-rollback blue
• 所有配置变更必须进 Git，Nginx 配置 diff 可追溯，避免手工编辑遗漏

进阶建议：降低运维负担的实用技巧

真实生产中，蓝绿不只是“两套代码”，更是可观测性与协作流程的延伸。

• 在响应 Header 中注入 X-Env: blue 和 X-Version: v1.0，便于排查问题时快速定位实例
• 数据库兼容性必须向前兼容：绿环境上线期间，蓝环境仍在写库，不能删字段或改约束
• 静态资源（JS/CSS）加哈希后缀，避免浏览器缓存导致前后端版本错配