蓝绿发布基本原理
蓝绿发布（Blue-Green Deployment）是一种零停机部署策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现流量瞬间切换与快速回滚。其核心在于环境隔离与流量路由的原子性，确保用户在任何时刻都只访问稳定版本。
2.1 蓝环境与绿环境的定义
在蓝绿发布模型中，两套环境在逻辑和物理上完全对等，但同一时刻只有一套环境承载全部生产流量，另一套处于待命或预热状态。
| 环境角色 | 状态定义 | 典型用途 | 流量承载 |
|---|---|---|---|
| 蓝环境（Blue） | 当前运行稳定版本的生产环境 | 承载所有用户请求，对外提供服务 | 100% 生产流量 |
| 绿环境（Green） | 部署新版本、待切换的预备环境 | 运行新版本代码，执行集成测试与验证 | 0% 生产流量（仅内部验证） |
| 切换后蓝环境 | 旧版本保留，作为快速回滚目标 | 保持原版本不变，随时准备接管流量 | 0% 生产流量（冷备） |
| 切换后绿环境 | 新版本正式上线，成为新的生产环境 | 承载所有用户请求 | 100% 生产流量 |
关键原则：蓝绿环境必须保持基础设施、配置、数据层的一致性。数据库通常采用双向同步或共享存储方案，确保切换后数据不丢失。
2.2 流量切换的原子性
流量切换是蓝绿发布中最关键的操作，必须保证原子性（Atomicity）——即切换操作要么全部成功，要么全部失败，不存在中间状态。原子性切换避免了部分用户访问新版本、部分用户访问旧版本的混乱局面，也消除了因切换中断导致的请求丢失风险。
原子性切换的实现方式
- 负载均衡器路由规则更新：通过修改 Nginx、HAProxy、AWS ALB 或 Kubernetes Service 的流量分发规则，将流量目标从蓝环境 IP/端口 瞬间切换至绿环境。
- DNS 解析切换：修改 DNS A 记录或 CNAME，将域名指向绿环境入口。受 DNS 缓存影响，此方式原子性较弱，通常配合短 TTL 使用。
- 网关/路由表批量更新：在 API 网关或服务网格（如 Istio）中，通过一次配置变更同时切换所有路由规则，确保切换的全局一致性。
最佳实践：在发布工程自助门户中，流量切换应封装为一键操作，后端执行前先做预检查（环境健康、版本一致性、数据库状态），确认无误后执行原子性切换，并自动记录切换审计日志。
2.3 零停机部署的核心思想
零停机部署（Zero-Downtime Deployment）的目标是在应用版本升级过程中，用户完全感知不到服务中断或性能下降。蓝绿发布通过以下机制实现这一目标：
- 预部署与预热：新版本在绿环境提前部署并完成初始化、缓存预热、数据库迁移，确保切换后立即提供完整服务。
- 瞬间切换：利用原子性路由切换，将用户请求从蓝环境无缝转移至绿环境，切换时间通常在毫秒级。
- 连接平滑迁移：通过优雅关闭（Graceful Shutdown）和连接耗尽（Connection Draining）机制，确保正在处理的请求在切换后正常完成，不被强制中断。
- 快速回滚：一旦切换后发现新版本异常，立即将流量切回蓝环境，回滚时间与切换时间相同，用户几乎无感知。
| 阶段 | 操作 | 用户感知 | 关键指标 |
|---|---|---|---|
| 部署阶段 | 新版本部署至绿环境，运行自动化测试 | 无感知（绿环境未接入流量） | 部署成功率、测试通过率 |
| 预热阶段 | 绿环境加载数据、建立连接池、预热缓存 | 无感知 | 预热完成时间、资源利用率 |
| 切换阶段 | 负载均衡器原子性切换流量至绿环境 | 无感知（毫秒级切换） | 切换耗时、错误率变化 |
| 验证阶段 | 监控新版本运行状态，确认无异常 | 无感知（持续提供服务） | 请求延迟、错误率、吞吐量 |
| 回滚阶段（如需） | 流量切回蓝环境，绿环境下线 | 无感知（毫秒级回滚） | 回滚耗时、数据一致性 |
注意：零停机部署要求数据库或持久化存储支持向后兼容的 schema 变更。如果新版本修改了数据库结构，必须确保旧版本（蓝环境）在回滚后仍能正常读写数据。常见的做法是采用增量式迁移，分多个发布周期完成 schema 变更。
2.4 蓝绿发布的核心优势与适用场景
- 优势：部署风险极低、回滚速度极快、版本切换对用户透明、便于进行生产环境验证。
- 适用场景：微服务架构、Web 应用、API 服务、移动后端、需要高可用 SLA 的关键业务系统。
- 限制：需要双倍基础设施资源（两套环境）、数据库兼容性要求高、不适合有状态应用或长连接密集型系统。
在发布工程自助门户中，蓝绿发布的流量切换与验证机制被封装为标准化工作流，用户只需选择目标版本、确认预检查结果、点击“切换”按钮，系统即可自动完成上述所有步骤，并实时展示切换进度与环境健康状态。