蓝绿发布通过流量切换实现无感知部署，核心是路由控制、版本隔离与快速回滚；需双栈服务+七层网关（如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;
发布流程：三步完成平滑切换
发布不是“启动新版本再关旧版”，而是“验证新版本 → 切流量 → 观察指标”，全程无需重启进程或中断连接。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 先启动绿环境，调用其健康接口（如
/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）加哈希后缀，避免浏览器缓存导致前后端版本错配
