蓝绿发布流量切换MTTR复盘口径与渐进式验证 - 第1节
1.1 蓝绿发布定义与核心目标
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现应用版本平滑切换的发布策略。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境保持空闲或用于部署新版本，通过流量调度器（如负载均衡器、网关或DNS）完成瞬间切换。
核心定义：蓝绿发布 = 两套独立环境 + 流量全量切换 + 零停机 + 即时回滚。
核心目标
- 零停机（Zero Downtime）：用户在整个发布过程中无感知，业务不中断。切换操作通常在秒级完成，不涉及应用重启或连接断开。
- 快速回滚（Instant Rollback）：若新版本出现异常，只需将流量调度器切回旧环境即可，回滚时间等于一次流量切换的时间（通常 < 30秒），无需重新部署旧版本。
- 环境隔离（Environment Isolation）：蓝绿两套环境在基础设施层面完全独立（独立计算资源、独立数据库实例或Schema、独立配置），避免相互干扰。
- 验证前置（Pre-validation）：新版本在绿环境（或蓝环境）部署完成后，可在不承接生产流量的情况下进行完整的集成测试、冒烟测试和预生产验证。
关键指标：蓝绿发布的MTTR（平均恢复时间）理论上等于流量切换时间，而非重新部署时间。这是其相比滚动发布最显著的优势。
1.2 与传统滚动发布的对比
滚动发布（Rolling Deployment）是另一种常见的发布策略，其核心是逐步替换旧版本实例。下表从多个维度对比蓝绿发布与滚动发布的关键差异：
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套完整独立环境（蓝/绿） | 一套环境，逐步替换实例 |
| 停机时间 | 零停机（切换瞬间完成） | 理论上零停机，但需处理连接耗尽 |
| 回滚速度 | 秒级（流量切回旧环境） | 分钟级（需逐步回滚实例） |
| 资源成本 | 高（双倍资源占用） | 低（仅需少量额外缓冲实例） |
| 验证能力 | 强（可在隔离环境完整验证） | 弱（新版本逐步暴露给用户） |
| 数据库兼容性 | 需前后兼容（两套环境共享或切换DB） | 需前后兼容（新旧实例共存） |
| 适用场景 | 核心业务、高可用要求、快速回滚需求 | 资源敏感、非关键业务、小版本迭代 |
常见误区：蓝绿发布并非“零成本”方案。双倍资源开销在大型微服务架构中可能非常昂贵。此外，数据库Schema变更需要严格的前后向兼容，否则切换后可能导致旧环境无法回滚。
滚动发布的核心流程
- 启动更新：从负载均衡器中摘除一个旧版本实例。
- 等待连接耗尽：等待该实例的现有请求处理完毕（graceful shutdown）。
- 部署新版本：在该实例位置启动新版本容器/进程。
- 健康检查：确认新实例通过健康检查后，重新加入负载均衡池。
- 重复步骤1-4：逐个替换所有实例，直到全部更新完成。
1.3 蓝绿发布的关键成功要素
实施蓝绿发布前必须确认的三项前提：
- 流量调度能力：负载均衡器、网关或DNS必须支持瞬时、原子化的流量切换，且切换过程中不中断现有连接（或支持连接 draining）。
- 数据层兼容性：数据库Schema变更必须向前兼容（新增字段允许null或默认值，不删除旧字段），确保切换后两套环境都能正常读写。
- 环境一致性：蓝绿两套环境的配置、依赖、中间件版本必须保持一致，避免因环境差异导致新版本表现异常。
最佳实践：建议在蓝绿发布流程中引入“预切换验证”环节——在流量正式切换前，先通过内部测试账号或影子流量对绿环境进行冒烟测试，确认核心接口可用后再执行全量切换。