1. 蓝绿发布概述
1.1 什么是蓝绿发布
蓝绿发布（Blue-Green Deployment）是一种零停机的应用发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现新版本的平滑上线与快速回滚。在任意时刻，只有一套环境承载全部生产流量，另一套环境处于待命或闲置状态。
核心思想： 流量瞬间切换，而非逐步替换。发布过程不涉及对运行中实例的原地升级，而是直接切换流量入口。
1.2 工作原理
蓝绿发布遵循“保留旧环境，部署新环境，切换流量”的三步流程。整个过程对用户透明，切换时间通常在秒级。
- 准备阶段： 保持蓝环境（当前生产环境）正常运行，承载全部用户流量。
- 部署阶段： 在绿环境中部署新版本应用，运行完整的 Health Check 脚本验证新环境就绪。
- 切换阶段： 将负载均衡器/网关的流量指向绿环境，绿环境成为新的生产环境。
- 观察与回滚： 监控新环境运行状态；若出现问题，立即将流量切回蓝环境。
关键门禁： 在流量切换前，必须通过 Health Check 脚本验证新环境的全部依赖（数据库连接、缓存、下游服务、磁盘空间等）均处于健康状态。这是蓝绿发布的安全门禁。
1.3 与传统滚动发布的区别
滚动发布（Rolling Update）逐步替换运行中的实例，而蓝绿发布通过环境整体切换实现版本更新。两者在风险控制、回滚速度、资源消耗等方面存在显著差异。
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 停机时间 | 零停机（切换瞬间完成） | 接近零停机（逐个替换实例） |
| 回滚速度 | 秒级（流量切回旧环境） | 分钟级（逐个回滚实例） |
| 资源消耗 | 高（需同时运行两套完整环境） | 低（仅需额外 1 个实例缓冲） |
| 环境一致性 | 高（新旧环境完全独立） | 中（新旧实例共存于同一环境） |
| 数据库兼容性 | 需前后兼容（新旧版本共享数据库） | 需前后兼容（逐步替换） |
| 适用发布规模 | 大版本、高风险变更 | 小版本、低风险修复 |
1.4 适用场景
蓝绿发布并非适用于所有场景，其高资源消耗特性决定了它最适合高风险、高影响的发布场景。
- 核心业务系统发布： 支付、交易、用户认证等不可中断的核心服务。
- 重大版本升级： 架构重构、数据库迁移、协议变更等高风险变更。
- 合规与审计要求： 需要保留旧环境用于回滚审计或灰度验证。
- 快速回滚需求： 业务要求故障恢复时间（RTO）在分钟级以内。
不适用场景： 数据库 Schema 不兼容且无法做前后兼容改造时，蓝绿发布无法直接切换；资源受限的小团队或低频变更项目，双环境成本过高。
1.5 蓝绿发布的关键挑战
| 挑战 | 说明 | 应对策略 |
|---|---|---|
| 数据库兼容性 | 新旧版本共享同一数据库，Schema 变更需前后兼容 | 采用增量迁移、读写分离、扩展字段而非修改字段 |
| 环境一致性 | 两套环境配置、依赖、数据必须完全一致 | 基础设施即代码（IaC）、配置管理工具、自动化部署 |
| 资源成本 | 双环境运行导致计算/存储资源翻倍 | 闲置环境缩容至最小副本、使用按需实例 |
| Health Check 可靠性 | 切换前必须全面验证新环境健康状态 | 编写多维度 Health Check 脚本（本章核心内容） |