3. 蓝绿发布原理：蓝绿环境定义、流量切换机制、回滚策略
蓝绿发布（Blue-Green Deployment）是一种零停机或接近零停机的应用发布策略。其核心思想是维护两套完全独立的生产环境（蓝环境与绿环境），通过流量调度器在两者之间瞬间切换用户流量，从而实现平滑上线与快速回滚。
3.1 蓝绿环境定义与基础设施模型
在蓝绿模型中，任意时刻只有一套环境承载全部生产流量，另一套环境处于待命或空闲状态。两套环境在逻辑与物理上必须保持对称，即拥有相同的资源配置、中间件版本、网络策略与数据访问权限。
| 维度 | 蓝环境（当前生产） | 绿环境（新版本） |
|---|---|---|
| 运行版本 | v1.2.0（稳定版） | v1.3.0（待发布版） |
| 流量状态 | 100% 用户流量 | 0% 用户流量（内部验证） |
| 数据库 | 共享主库（兼容读写） | 共享主库（只读验证） |
| 配置/Secrets | 当前生产密钥集 | 新版本密钥集（预注入） |
| 健康检查 | 持续监控 | 预部署验证通过 |
关键约束：数据库向后兼容是蓝绿发布的前提。如果新版本修改了表结构或数据格式，必须保证蓝环境在切换前仍能正常读写，否则切换后无法回滚。
3.2 流量切换机制
流量切换是蓝绿发布的核心动作，要求原子性、瞬时性与可观测性。切换通常由负载均衡器、网关或 DNS 记录变更触发，而非逐个重启实例。
3.2.1 切换流程
- 预部署验证：在新环境（绿）上运行冒烟测试、Secrets 注入校验与健康检查，确保所有端点返回 200。
- 流量预热（可选）：通过内部 DNS 或 Header 路由，将 1%~5% 的测试流量导入绿环境，验证延迟与错误率。
- 原子切换：修改负载均衡器后端池，将 100% 流量指向绿环境。切换应在 1~3 秒内完成。
- 切换后监控：观察 5~15 分钟，确认错误率、P99 延迟、吞吐量无异常。
- 旧环境保留：蓝环境保持运行，作为回滚目标。
Secrets 切换要点：流量切换前，必须确保绿环境已通过 Secrets 管理服务（如 Vault / AWS Secrets Manager）拉取到正确的密钥版本。切换后，蓝环境的 Secrets 应被自动轮转或标记为“已退役”，防止密钥泄露。
3.2.2 切换方式对比
| 切换方式 | 切换时间 | 流量损失 | 适用场景 |
|---|---|---|---|
| DNS 记录切换 | 1~5 分钟（TTL 依赖） | 部分客户端缓存导致混合流量 | 非关键业务、可接受短暂混合 |
| 负载均衡器后端池切换 | 1~3 秒 | 接近零 | 生产环境、高可用要求 |
| 网关路由规则切换 | 毫秒级 | 零 | 微服务架构、精细化流量控制 |
3.3 回滚策略
蓝绿发布的最大优势在于回滚速度极快——只需将流量调度器指回旧环境即可，无需重新部署或构建镜像。但回滚并非无代价，必须提前制定策略。
3.3.1 回滚触发条件
- 错误率飙升：切换后 5 分钟内错误率超过基线 2 倍。
- P99 延迟恶化：延迟超过切换前 1.5 倍且持续 3 分钟。
- Secrets 注入失败：新环境无法正确读取密钥，导致认证或解密失败。
- 数据库兼容性异常：新版本写入的数据格式导致旧版本无法读取。
3.3.2 回滚执行步骤
- 停止新流量：立即将负载均衡器后端池切回蓝环境（旧版本）。
- 恢复 Secrets：确保蓝环境使用的 Secrets 版本未被轮转或撤销。如果 Secrets 已被自动轮转，需从备份版本恢复。
- 数据库回滚（如有必要）：如果新版本执行了 DDL 或数据迁移，需执行逆向迁移脚本。
- 保留绿环境：不要立即销毁绿环境，保留现场用于事后根因分析。
- 通知与记录：将回滚事件写入审计日志，并触发告警通知。
回滚陷阱：如果新版本修改了数据库 Schema 且未设计逆向迁移，回滚将导致数据不一致。蓝绿发布必须搭配数据库版本兼容策略（如新增列允许 NULL、不删除旧列）。
3.4 蓝绿发布与 Secrets 管理的集成要点
- 环境隔离：蓝绿环境必须使用独立的 Secrets 路径或命名空间，避免密钥串扰。
- 预注入校验：在流量切换前，通过 CI/CD 流水线自动验证新环境能否正确解密 Secrets。
- 版本对齐：Secrets 版本与应用版本绑定，切换时同时切换 Secrets 版本。
- 回滚密钥恢复：回滚时确保旧环境使用的 Secrets 版本未被自动轮转或删除。
最佳实践：在蓝绿发布流水线中增加一个“Secrets 一致性检查”阶段，对比蓝绿环境拉取的密钥指纹（SHA256），确保两者在切换前后不会意外交叉。