1. 蓝绿发布概述
1.1 蓝绿发布定义
蓝绿发布（Blue-Green Deployment）是一种零停机或接近零停机的应用发布策略。其核心思想是维护两套完全独立的生产环境——蓝环境（Blue）与绿环境（Green），在任何时刻只有一套环境承载全部生产流量，另一套环境处于空闲或待发布状态。
当需要发布新版本时，团队将新版本应用部署到当前空闲的环境（例如绿环境），完成集成验证与冒烟测试后，通过负载均衡器或网关将流量从蓝环境瞬时切换至绿环境。切换完成后，原蓝环境变为空闲，可用于下一次发布或作为快速回滚的备份。
关键特征： 两套环境 + 流量瞬时切换 + 快速回滚能力。
1.2 与传统滚动发布对比
传统滚动发布（Rolling Deployment）通过逐步替换现有实例的方式完成版本更新，而蓝绿发布采用全量环境切换策略。两者在多个维度存在显著差异：
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套完整环境（蓝 + 绿） | 一套环境，逐步替换实例 |
| 切换方式 | 流量瞬时全量切换（秒级） | 实例逐个或分批替换（分钟~小时级） |
| 回滚速度 | 瞬时回滚：切回原环境即可 | 需反向滚动，耗时较长 |
| 资源成本 | 较高（需维护双倍环境） | 较低（仅需少量额外缓冲） |
| 发布期间容量 | 100% 容量始终在线 | 可能降级（部分实例被替换） |
| 测试验证窗口 | 切换前可在空闲环境充分验证 | 验证窗口有限，与生产流量共存 |
| 适用场景 | 关键业务、高可用要求、数据库兼容 | 资源敏感、非关键服务、小版本迭代 |
经验提示： 滚动发布在 Kubernetes 中通过 Deployment 的 maxSurge 和 maxUnavailable 参数控制，而蓝绿发布通常需要 Service + Label Selector 或 Service Mesh 层面的流量路由支持。
1.3 蓝绿发布核心优势
- 零停机发布： 流量切换在负载均衡层面完成，用户会话无中断，业务连续性得到保障。
- 瞬时回滚： 一旦新版本出现异常，只需将流量切回原环境，回滚时间从分钟级缩短到秒级。
- 隔离验证： 新版本在空闲环境部署，与生产流量完全隔离，可执行完整的集成测试、性能测试和安全扫描。
- 降低发布风险： 通过门禁机制（如自动化测试通过率、性能基线、安全合规检查）控制切换决策，避免有缺陷版本流入生产。
- 环境一致性： 两套环境配置完全一致（除版本差异外），减少环境差异导致的发布故障。
1.4 适用场景与限制
蓝绿发布并非银弹，其适用性取决于业务特征与基础设施能力：
| 适用场景 | 不适用或需谨慎的场景 |
|---|---|
| 关键业务系统（支付、交易、核心服务） | 资源受限环境（无法承担双倍资源开销） |
| 需要快速回滚能力的高风险发布 | 数据库 Schema 不兼容的版本（需额外处理数据迁移） |
| 微服务架构中独立部署的服务 | 长连接或状态密集型应用（会话状态未外部化） |
| 合规性要求严格的发布流程 | 发布频率极高且每次变更极小的场景（资源浪费） |
| 需要灰度验证但希望快速全量切换 | 基础设施不支持流量瞬时切换（如传统 LB 配置慢） |
注意： 数据库兼容性是蓝绿发布的最大挑战。如果新版本包含数据库 Schema 变更，必须确保变更向后兼容（Backward Compatible），否则切换后旧环境无法正常运行，回滚将变得困难。本课程后续章节将专门讲解数据库兼容性门禁的配置方法。
1.5 蓝绿发布与门禁的关系
蓝绿发布的核心价值在于门禁（Gate）机制。门禁是部署流水线中设置在环境切换前的自动化检查关卡，只有通过所有门禁检查的版本才能触发流量切换。常见的门禁类型包括：
- 单元测试门禁： 新版本单元测试通过率 ≥ 指定阈值（如 95%）。
- 集成测试门禁： 关键业务场景的集成测试全部通过。
- 性能基线门禁： 响应时间、吞吐量、错误率等指标不劣于基线。
- 安全扫描门禁： 无高危或严重漏洞。
- 配置一致性门禁： 蓝绿环境配置参数差异在允许范围内。
课程核心： 本课程将重点讲解如何通过标准模板实现蓝绿发布门禁，以及环境配置参数的自动化同步机制，确保每次发布都经过严格验证且环境配置一致。