1. 蓝绿发布概述
1.1 蓝绿发布定义
蓝绿发布（Blue-Green Deployment）是一种零宕机的应用发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现流量在旧版本与新版本之间的瞬时切换。其核心目标是：降低发布风险、缩短故障恢复时间、消除环境差异导致的配置漂移。
关键指标：蓝绿发布的 MTTR（平均修复时间）理论上可压缩至 秒级，仅取决于负载均衡器或网关的流量切换时间，而非传统发布的回滚部署耗时。
1.2 核心思想
蓝绿发布遵循“双环境、单流量”的运行模型：
- 蓝环境（Blue）：当前承载所有生产流量的稳定版本。
- 绿环境（Green）：部署新版本应用的待发布环境，与蓝环境保持完全一致的配置、中间件、数据层。
- 流量切换：验证绿环境通过后，通过路由层（如 Nginx、Kubernetes Service、API Gateway）将流量从蓝环境瞬时切换至绿环境。
- 快速回滚：若绿环境出现异常，只需将流量切回蓝环境，回滚时间等同于切换时间。
1.3 与传统发布对比优势
传统发布（滚动更新、灰度发布、金丝雀发布）在环境一致性、回滚速度、配置同步方面存在显著短板。蓝绿发布通过环境隔离 + 全量切换机制，在以下维度形成代差优势：
| 对比维度 | 传统滚动发布 | 蓝绿发布 | 优势说明 |
|---|---|---|---|
| 回滚速度 | 分钟~小时级（需重新部署旧版本） | 秒级（仅需切换流量） | MTTR 从小时级降至秒级 |
| 环境一致性 | 新旧版本共享同一环境，配置易漂移 | 两套独立环境，配置可严格比对 | 消除“在我机器上是好的”问题 |
| 发布风险 | 影响范围逐步扩大，问题发现滞后 | 全量切换前可完整验证 | 降低生产故障概率 |
| 配置同步 | 依赖配置中心推送，易遗漏 | 环境级配置快照，切换即同步 | 配置变更与版本发布解耦 |
| 资源占用 | 低（复用环境） | 高（双倍资源） | 需权衡成本与可用性 |
| 数据库兼容 | 需向前兼容，回滚复杂 | 需设计双向兼容 schema | 数据层是蓝绿最大挑战 |
SRE 视角：蓝绿发布并非银弹。当数据库 schema 变更不兼容时，蓝绿切换可能导致数据损坏。本课程后续章节将专门讲解数据库兼容性设计与配置同步方案，这是蓝绿发布落地的关键难点。
1.4 蓝绿发布适用场景
- 无状态应用：Web 服务、API 网关、微服务（最理想场景）。
- 配置频繁变更：需要环境级配置快照比对，避免配置漂移。
- 高可用要求：SLA 要求 99.99%+，发布不能导致停机。
- 合规审计：需要保留完整的环境快照用于回滚审计。
不适用场景：有状态应用（数据库、缓存集群）、长连接服务（WebSocket）、数据迁移中的系统。这些场景需要结合灰度发布或双写模式，本课程将在第 18 章专门讨论。
1.5 蓝绿发布与 MTTR 的关系
MTTR（Mean Time to Repair）是 SRE 衡量发布可靠性的核心指标。蓝绿发布通过以下机制直接优化 MTTR：
- 故障隔离：绿环境故障不影响蓝环境，用户无感知。
- 瞬时回滚：回滚操作 = 1 次 DNS 或路由配置变更，典型耗时 < 10 秒。
- 环境差异可观测：蓝绿环境配置可做逐项差异比对，定位问题从“猜”变为“查表”。
- 复盘数据完整：两套环境日志、指标、配置快照均可保留，便于事后根因分析。