1. 蓝绿发布概述
1.1 蓝绿发布定义
蓝绿发布（Blue-Green Deployment）是一种零停机或接近零停机的应用发布策略，其核心思想是通过维护两套完全独立的生产环境——蓝环境（Blue）与绿环境（Green）——来实现版本切换。在任何时刻，只有一套环境承载全部生产流量，另一套环境则处于待命或空闲状态，用于部署新版本并进行最终验证。
关键特征：两套环境、流量瞬时切换、快速回滚、版本隔离。
1.2 核心思想
蓝绿发布遵循“保留旧版本，部署新版本，切换流量”的三步原则。其核心思想可拆解为以下四点：
- 环境双活准备：始终维护两套逻辑上独立、配置对等的生产环境（蓝/绿）。
- 版本隔离部署：新版本（V2）部署至空闲环境（如绿环境），与当前承载流量的生产环境（蓝环境，V1）完全隔离，互不干扰。
- 流量瞬时切换：通过负载均衡器、网关或DNS，将生产流量从蓝环境瞬间全部切换至绿环境，切换时间通常在秒级甚至毫秒级。
- 快速回滚能力：若新版本出现异常，只需将流量切回原环境（蓝环境），即可实现秒级回滚，无需重新部署旧版本。
实践要点：蓝绿发布并非要求两套环境物理上完全独立，但必须保证逻辑隔离，包括数据库Schema兼容、缓存预热、消息队列消费偏移等状态依赖问题需要提前处理。
1.3 与传统滚动发布的区别
滚动发布（Rolling Deployment）是另一种常见的发布策略，它通过逐步替换旧版本实例的方式完成升级。蓝绿发布与滚动发布在部署模式、风险控制、回滚速度等方面存在显著差异。下表从多个维度进行对比：
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套独立生产环境（蓝/绿） | 一套生产环境，逐步替换实例 |
| 部署方式 | 新版本一次性部署至空闲环境 | 新版本分批替换旧版本实例 |
| 流量切换 | 瞬时切换（秒级） | 逐步切换（分钟级到小时级） |
| 回滚速度 | 秒级（流量切回原环境） | 较慢（需反向逐步替换实例） |
| 资源成本 | 较高（需维护两套环境） | 较低（仅需一套环境+少量缓冲） |
| 版本兼容性 | 要求新老版本与后端完全兼容 | 要求新老版本在切换期间共存兼容 |
| 适用场景 | 核心业务、高可用要求、需快速回滚 | 资源受限、版本兼容性好、风险较低 |
注意：蓝绿发布并非银弹。当新版本涉及数据库Schema变更（如新增非空字段、删除表）或消息协议不兼容时，简单的流量切换可能导致数据不一致或服务中断。此时需要结合灰度发布或数据库迁移策略（如并行Schema、特性开关）来弥补。
1.4 蓝绿发布的典型适用场景
基于上述特性，蓝绿发布在以下场景中具有明显优势：
- 核心交易系统：如支付、订单、账户服务，要求发布期间零停机且具备秒级回滚能力。
- 前端/移动端API网关：版本切换频繁，需要快速验证新版本并随时回退。
- 基础设施升级：如Kubernetes集群版本、中间件（Redis、Kafka）版本升级，通过蓝绿环境降低风险。
- 合规与审计要求：需要保留旧版本环境以备审计或快速恢复。
选型建议：如果团队资源充足、业务对可用性要求极高（如99.99%以上），且具备自动化基础设施管理能力（如Terraform、Kubernetes），蓝绿发布是首选策略。反之，若资源紧张或发布频率较低，滚动发布结合灰度策略可能更经济。