1. 蓝绿部署概述
1.1 定义与核心思想
蓝绿部署（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机发布与快速回滚的部署策略。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境处于待命或闲置状态。
核心原则：流量一次性切换，而非逐步滚动。切换前，新版本已在隔离环境中完成全量验证；切换后，旧版本环境保留作为即时回滚目标。
蓝绿部署与传统滚动更新的本质区别在于：滚动更新通过逐个替换实例来渐进式上线新版本，而蓝绿部署通过路由层一次性切换完成版本更替。下表从多个维度对比两种策略：
| 对比维度 | 蓝绿部署 | 滚动更新 |
|---|---|---|
| 环境数量 | 两套完整环境（蓝+绿） | 单套环境，逐步替换 |
| 切换方式 | 路由/负载均衡器一次性切换 | 逐个实例滚动替换 |
| 回滚速度 | 秒级（切回旧环境） | 分钟级（需重新滚动） |
| 资源占用 | 双倍资源（切换后可释放旧环境） | 基本不变（仅额外保留一个实例） |
| 验证窗口 | 切换前可在隔离环境全量验证 | 仅能验证已替换的部分实例 |
| 适用场景 | 关键业务、要求秒级回滚、可接受双倍资源 | 资源敏感、变更风险低、可接受分钟级回滚 |
SRE 视角：蓝绿部署的本质是用资源冗余换取切换确定性。在流量切换的瞬间，系统状态从"全量旧版本"直接变为"全量新版本"，中间不存在混合版本窗口，这极大降低了分布式系统在发布期间的兼容性风险。
1.2 蓝绿部署的标准流程
一次完整的蓝绿部署包含以下五个阶段：
- 准备阶段：确认当前生产环境（假设为蓝环境），绿环境保持与蓝环境一致的基线版本。
- 部署阶段：将新版本应用部署到绿环境，执行数据库迁移、配置更新等操作。
- 验证阶段：在绿环境上执行冒烟测试、健康检查、预发布验证，确保新版本功能与性能达标。
- 切换阶段：通过负载均衡器/网关将生产流量从蓝环境一次性切换到绿环境。
- 观察与清理：观察新环境运行状态，确认稳定后释放旧环境资源；若异常则立即切回蓝环境。
下图展示了蓝绿部署的核心架构与流量切换路径：
1.3 蓝绿部署的关键成功要素
在实际生产环境中实施蓝绿部署，SRE 团队需要关注以下关键要素：
- 环境一致性：蓝绿两套环境在基础设施规格、网络配置、中间件版本上必须保持完全一致，否则切换后可能出现非预期行为。
- 数据兼容性：数据库 schema 变更必须向前兼容，确保切换前旧版本仍可读写；通常采用"增字段不删字段、加索引不加锁"的策略。
- 会话保持：若应用有状态，需在切换前处理会话迁移或使用分布式会话存储（如 Redis），避免用户登录态丢失。
- 切换原子性：DNS 变更或负载均衡配置更新应尽量做到原子操作，避免部分流量进入新环境而部分仍留在旧环境。
- 监控与可观测性：切换前后需对比蓝绿环境的错误率、延迟、吞吐量等核心指标，确保新版本表现不劣于旧版本。
常见陷阱：蓝绿部署并非银弹。当数据库向后不兼容的变更（如删除字段、重命名表）无法避免时，蓝绿部署需要配合扩展的蓝绿模式或并行运行期来逐步迁移数据。此外，微服务架构中若服务间存在网状调用，蓝绿切换可能引发级联兼容性问题，需配合流量染色或版本路由策略。
1.4 蓝绿部署 vs 滚动更新：决策矩阵
以下决策矩阵帮助团队根据自身情况选择部署策略：
| 决策条件 | 推荐策略 | 理由 |
|---|---|---|
| 回滚时间要求 < 30 秒 | 蓝绿部署 | 旧环境保持运行，切换即回滚 |
| 资源预算有限，无法承担双倍环境 | 滚动更新 | 仅需额外 1 个实例的冗余 |
| 数据库变更无法向前兼容 | 滚动更新 + 分阶段迁移 | 蓝绿切换时旧环境无法处理新 schema |
| 需要全量预发布验证 | 蓝绿部署 | 新版本在隔离环境完成全量测试后再切换 |
| 服务间存在强依赖版本耦合 | 蓝绿部署 + 流量染色 | 确保调用链路上所有服务版本一致 |
| 变更频率高（每日多次） | 蓝绿部署 | 切换速度快，适合高频迭代 |