1. 蓝绿发布概述
1.1 蓝绿发布定义
蓝绿发布（Blue-Green Deployment）是一种零停机的应用发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现无缝切换。在任意时刻，只有一套环境承载全部生产流量，另一套环境处于待命或空闲状态，用于部署新版本应用并进行最终验证。
核心定义：蓝绿发布 = 两套独立环境 + 流量瞬时切换 + 快速回滚能力。蓝环境与绿环境在基础设施层面完全对等，共享数据库、存储等有状态服务，但应用代码与配置各自独立。
1.2 核心价值
蓝绿发布的核心价值体现在以下四个维度，直接解决传统发布模式中的痛点：
| 价值维度 | 具体收益 | 关键指标 |
|---|---|---|
| 零停机发布 | 流量切换在网关层瞬时完成，用户无感知 | 切换耗时 < 1s，RTO ≈ 0 |
| 即时回滚 | 发现异常后立即切回旧环境，无需重新部署 | 回滚耗时 < 5s，MTTR 降低 90%+ |
| 环境隔离 | 新旧版本完全隔离，互不干扰，可并行验证 | 故障爆炸半径 = 单环境 |
| 验证充分性 | 新版本在真实生产环境中验证后再切换流量 | 验证窗口 = 任意时长 |
自动化关键：蓝绿发布的价值高度依赖自动化能力。手动切换流量或配置回滚会引入人为失误，抵消零停机与即时回滚的优势。本课程后续章节将重点讲解如何通过 Automation 实现蓝绿发布的网络配置自动回滚。
1.3 与传统发布对比
下表从 8 个关键维度对比蓝绿发布与传统滚动发布、灰度发布的核心差异：
| 对比维度 | 传统滚动发布 | 灰度发布（金丝雀） | 蓝绿发布 |
|---|---|---|---|
| 环境数量 | 1 套（原地替换） | 1 套（混合运行） | 2 套（完全独立） |
| 停机时间 | 分钟级（分批重启） | 无（流量逐步迁移） | 零（瞬时切换） |
| 回滚速度 | 慢（需重新部署旧版本） | 中等（调整流量比例） | 极快（切换回旧环境） |
| 资源成本 | 低（仅 1 倍资源） | 低（仅 1 倍资源） | 高（需 2 倍资源） |
| 验证能力 | 弱（无法预验证） | 中（小流量验证） | 强（全量预验证） |
| 配置回滚 | 依赖版本管理工具 | 需回退配置变更 | 环境整体回滚 |
| 网络切换 | DNS/LB 逐步更新 | 权重动态调整 | 一次性全量切换 |
| 适用规模 | 中小规模应用 | 中大规模应用 | 关键业务 / 高可用要求 |
1.4 适用场景分析
蓝绿发布并非万能方案，其适用性取决于业务需求、基础设施能力和团队成熟度。以下从推荐使用与谨慎使用两个维度进行场景分析：
✅ 推荐使用场景
- 关键业务系统：支付网关、交易系统、用户认证等要求零停机的核心服务。
- 高频发布项目：每日多次发布的需求，需要快速验证与即时回滚能力。
- 基础设施标准化：使用容器化（Kubernetes）、基础设施即代码（Terraform/CloudFormation）的环境。
- 网络配置复杂场景：涉及防火墙规则、负载均衡策略、DNS 记录等多层网络配置变更。
- 合规审计要求：需要完整发布记录与回滚审计日志的金融、医疗等行业。
⚠️ 谨慎使用场景
- 有状态应用：数据库 schema 变更、文件存储迁移等场景，双环境共享有状态服务可能引入兼容性问题。
- 资源受限环境：无法承担 2 倍基础设施成本的小团队或边缘项目。
- 长连接服务：WebSocket、gRPC 长连接在流量切换时可能断连，需额外处理连接迁移。
- 配置一致性要求极高：蓝绿环境配置差异可能导致流量切换后出现非预期行为，需自动化配置校验。
网络配置回滚特别提示：蓝绿发布中网络配置（负载均衡规则、安全组策略、DNS 记录、路由表）的回滚比应用代码回滚更复杂。自动化回滚策略必须覆盖网络配置的版本化、一致性校验与原子性切换，否则可能出现“应用回滚成功但网络配置残留”的故障状态。本课程第 4-8 章将深入讲解网络配置回滚的自动化实现。