1. 蓝绿发布基础概念
1.1 什么是蓝绿发布
蓝绿发布（Blue-Green Deployment）是一种零停机、快速切换的发布策略。其核心思想是同时维护两套完全独立的生产环境——蓝环境（Blue）和绿环境（Green），在任何时刻只有一套环境承载真实流量，另一套环境处于待命或预热状态。
核心定义：蓝绿发布通过两套独立环境 + 流量路由切换，实现应用版本的瞬时替换，将发布风险与回滚时间压缩到秒级。
典型工作流程：
- 初始状态：蓝环境运行 v1.0 版本，承载 100% 生产流量；绿环境空闲或运行 v1.0 副本。
- 部署新版本：将 v2.0 部署到绿环境，执行完整的功能验证、健康检查、预热。
- 流量切换：验证通过后，将负载均衡器/网关流量从蓝环境瞬时切换到绿环境。
- 保持待命：蓝环境保留 v1.0 作为回滚备份，直到下一次发布确认稳定后再回收。
1.2 蓝绿发布 vs 滚动发布 vs 金丝雀发布
三种主流发布策略在风险控制、发布速度、资源成本和回滚效率上存在显著差异。下表从 8 个关键维度进行对比：
| 对比维度 | 蓝绿发布 | 滚动发布 | 金丝雀发布 |
|---|---|---|---|
| 环境数量 | 2 套完整环境 | 1 套环境，分批替换 | 1 套环境 + 少量金丝雀实例 |
| 流量切换方式 | 瞬时全量切换 | 逐步替换实例 | 按权重/规则灰度引流 |
| 发布速度 | 秒级（路由切换） | 分钟~小时级（分批） | 分钟~小时级（灰度观察） |
| 回滚速度 | 秒级（切回旧环境） | 分钟级（反向滚动） | 秒级（调整流量权重） |
| 资源成本 | 高（双倍资源） | 低（无额外资源） | 中（少量金丝雀实例） |
| 风险暴露面 | 全量用户瞬时暴露 | 逐步暴露 | 小范围灰度验证 |
| 适用版本跨度 | 大版本/架构变更 | 小版本/补丁 | 功能验证/AB 测试 |
| 数据库兼容要求 | 需前后兼容 | 需前后兼容 | 需前后兼容 |
选型建议：蓝绿发布适合核心服务和重大版本，滚动发布适合日常迭代，金丝雀发布适合高风险功能和AB 实验。生产环境中常组合使用：金丝雀验证 → 蓝绿全量切换。
1.3 蓝绿发布的适用场景
蓝绿发布并非万能银弹，其双倍资源成本和全量风险暴露决定了它有明确的适用边界。以下按场景类型分类说明：
核心原则：当「回滚速度」和「发布确定性」的优先级高于「资源成本」时，蓝绿发布是最优选择。
✅ 强烈推荐使用蓝绿发布的场景
- 核心交易链路：支付、订单、账户等不可中断的服务，要求回滚时间 < 10 秒。
- 重大版本/架构变更：数据库迁移、框架升级、微服务拆分等涉及大规模代码变动的发布。
- 合规审计要求：金融、医疗等需要完整发布记录和即时回滚能力的行业。
- 多环境预演：需要在生产环境进行全量压测、预热、流量回放后再切换的场景。
- 基础设施迁移：Kubernetes 集群迁移、Ingress 控制器替换、Service Mesh 切换等。
⚠️ 谨慎使用或需要改造的场景
- 有状态服务：数据库、缓存、消息队列等有状态组件，蓝绿切换可能导致数据不一致。需配合双写或 CDC 方案。
- 长连接服务：WebSocket、gRPC Stream 等长连接在切换时可能断连，需客户端重连机制。
- 资源受限环境：边缘节点、IoT 设备、小型团队，双倍资源成本不可接受。
- 高频发布场景：每天数十次发布时，蓝绿环境的频繁预热和回收会带来额外运维负担。
📋 蓝绿发布适用性评估表
| 评估维度 | 适合蓝绿 | 不适合蓝绿 |
|---|---|---|
| 服务类型 | 无状态微服务 | 有状态服务（DB、MQ） |
| 发布频率 | 每天 < 5 次 | 每天 > 20 次 |
| 回滚要求 | 秒级回滚 | 分钟级可接受 |
| 资源预算 | 可接受 2x 资源 | 资源紧张 |
| 流量特征 | HTTP/HTTPS 短连接 | WebSocket/gRPC 长连接 |
| 数据库变更 | 前后兼容 | 不兼容 schema 变更 |
常见误区：蓝绿发布不等于「两套完全独立的基础设施」。在 Kubernetes 中，蓝绿环境通常共享同一个集群，通过 Namespace、Label、Service 进行隔离。真正的「双环境」是指两套完整的应用实例组，而非两套 Kubernetes 集群。