1. 蓝绿发布基础概念
1.1 什么是蓝绿部署
蓝绿部署（Blue-Green Deployment）是一种零停机或接近零停机的应用发布策略。其核心思想是维护两套完全独立的生产环境——蓝环境（Blue）和绿环境（Green），在任何时刻只有一套环境承载全部生产流量，另一套环境处于待命或空闲状态。
核心目标：通过环境冗余实现瞬时切换，将发布风险与流量隔离，使回滚操作如同一次路由切换般简单快速。
当需要发布新版本时，操作流程如下：
- 在空闲环境（例如当前未承载流量的绿环境）中部署新版本应用。
- 对绿环境执行全面的功能验证、健康检查和SLO预检。
- 通过负载均衡器或网关将流量从蓝环境一次性或逐步切换到绿环境。
- 蓝环境进入待命状态，作为下一轮发布的回滚目标。
1.2 蓝绿环境定义
蓝绿环境在基础设施层面必须保持对等性，即两套环境拥有相同的计算资源、网络配置、中间件服务和数据存储拓扑。以下是环境定义的关键要素：
| 环境维度 | 蓝环境 (Blue) | 绿环境 (Green) |
|---|---|---|
| 当前状态 | 承载生产流量（活跃） | 空闲或部署新版本（待命） |
| 应用版本 | 稳定版本 v1.0 | 新版本 v2.0（部署后） |
| 基础设施 | K8s 集群 A / 服务网格 A | K8s 集群 B / 服务网格 B |
| 数据库 | 共享数据库（兼容模式） | 共享数据库（兼容模式） |
| DNS/路由 | 指向负载均衡器主入口 | 指向负载均衡器备用入口 |
| 监控告警 | 全量生产监控 | 全量生产监控（预检中） |
实践建议：数据库兼容性是蓝绿部署的最大挑战。通常采用“前向兼容”策略——新版本代码必须同时读写新旧两种数据格式，确保切换后旧版本回滚时仍能正常操作数据。
1.3 流量切换原理
流量切换是蓝绿部署的核心操作，其本质是修改流量路由规则，将用户请求从蓝环境导向绿环境（或反向）。切换粒度可分为以下三种模式：
- 瞬时全量切换：一次性将100%流量从蓝切到绿。切换时间通常在秒级，适用于对切换速度要求极高的场景。
- 渐进式切换：按比例逐步迁移流量（如10% → 30% → 50% → 100%），每阶段观察SLO指标，发现异常立即暂停或回切。
- 灰度前置切换：先切一小部分内部测试流量或金丝雀流量到绿环境，验证通过后再全量切换。
1.4 与传统滚动更新的区别
滚动更新（Rolling Update）是Kubernetes等编排平台的默认更新策略，它通过逐步替换旧版本Pod实例来完成发布。蓝绿部署与滚动更新在多个维度存在本质差异：
| 对比维度 | 蓝绿部署 | 滚动更新 |
|---|---|---|
| 环境数量 | 两套完整生产环境 | 单套环境，逐步替换 |
| 切换速度 | 秒级（路由切换） | 分钟级（Pod逐个替换） |
| 回滚速度 | 秒级（切回旧环境） | 分钟级（反向滚动替换） |
| 资源成本 | 高（双倍资源占用） | 低（仅需额外10%-25%缓冲） |
| 流量影响 | 零停机 | 接近零停机（连接排空期） |
| 版本隔离 | 完全隔离，无混合流量 | 新旧版本短暂共存 |
| 适用场景 | 关键业务、高风险变更、SLO敏感 | 常规迭代、资源受限、低风险更新 |
注意：蓝绿部署并非银弹。双倍资源开销在大型微服务架构中可能非常昂贵。实践中常采用“逻辑蓝绿”方案——通过Kubernetes命名空间或服务网格标签实现环境隔离，而非完全独立的物理集群，以降低成本。
选择建议：对于SLO要求极高（如99.99%可用性）的核心服务，优先采用蓝绿部署+自动SLO违约检测；对于非关键服务或快速迭代场景，滚动更新配合金丝雀发布是更经济的选择。