蓝绿发布基础：蓝绿环境架构原理、流量切换策略、回滚机制与风险控制
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机发布与快速回滚的部署模式。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境保持空闲或用于新版本验证，通过流量调度网关完成瞬间切换。
2.1 蓝绿环境架构原理
蓝绿架构要求两套环境在基础设施、网络配置、中间件、数据库 schema 层面保持高度一致，仅在应用代码版本上存在差异。典型的蓝绿部署拓扑如下图所示：
架构要点：蓝绿环境共享同一套数据库主从架构，但应用层完全隔离。新版本在绿环境完成集成测试、冒烟测试和 SLO 预检后，通过网关一次性切换流量，实现秒级发布。
2.2 流量切换策略
流量切换是蓝绿发布的核心操作，根据业务场景和风险容忍度，通常采用以下三种策略：
| 策略名称 | 切换方式 | 切换耗时 | 适用场景 | 风险等级 |
|---|---|---|---|---|
| 全量即时切换 | DNS / 负载均衡器权重一键切换 | 秒级 | 非关键业务、内部系统 | 中 |
| 灰度渐进切换 | 按权重逐步调整（10% → 50% → 100%） | 分钟级 | 核心交易、用户敏感业务 | 低 |
| Cookie/Session 粘性切换 | 基于用户标识路由到指定环境 | 持续 | A/B 测试、金丝雀发布 | 低 |
全量即时切换的典型操作流程如下：
- 预部署验证：在绿环境完成应用部署、数据库迁移、缓存预热，并执行自动化冒烟测试。
- SLO 门禁检查：采集绿环境的延迟、错误率、吞吐量等指标，与基线 SLO 进行比对。
- 流量切换：修改负载均衡器（如 Nginx upstream）的权重配置，将 100% 流量指向绿环境。
- 健康观测：持续观测绿环境指标 5-15 分钟，确认无异常后标记蓝环境为待回收状态。
最佳实践：建议在流量切换前执行一次“预切换演练”，即在非生产时段将测试流量导入绿环境，验证网关路由、会话保持和数据一致性。演练通过后再执行正式切换，可大幅降低生产事故概率。
2.3 回滚机制与风险控制
蓝绿发布的最大优势在于回滚速度极快——只需将流量调度切回原环境即可，无需重新部署或回滚代码。但回滚操作本身也存在风险，需要建立规范的触发条件和执行流程。
2.3.1 回滚触发条件
- 错误率突增：新环境 5xx 错误率超过基线 SLO 阈值（如 > 1%）。
- 延迟劣化：P99 延迟超过基线值的 1.5 倍。
- 业务指标异常：订单成功率、支付转化率等核心业务指标下降超过 5%。
- 基础设施告警：CPU/内存/连接数等资源使用率超过安全水位。
2.3.2 回滚执行流程
2.3.3 风险控制清单
| 风险类别 | 风险描述 | 控制措施 |
|---|---|---|
| 数据兼容性 | 新版本数据库 schema 变更导致回滚后数据不兼容 | 采用向后兼容的 schema 变更策略；回滚前执行数据回迁脚本 |
| 缓存污染 | 新版本写入的缓存格式与旧版本不兼容 | 回滚后执行缓存全量刷新；使用双写 + 版本号隔离 |
| 会话丢失 | 流量切换导致用户会话状态中断 | 使用分布式会话存储（Redis）；切换时保持会话亲和性 |
| 监控盲区 | 回滚后未及时恢复监控告警 | 回滚流程中自动恢复监控基线；执行告警规则自检 |
| 人为误判 | 指标抖动导致不必要的回滚 | 设置回滚冷静期（如持续异常 30 秒以上才触发）；支持手动确认 |
关键提醒：蓝绿发布并非银弹。当数据库 schema 变更涉及数据迁移或字段重命名时，回滚将变得复杂。建议在发布周期中采用“向前兼容 + 渐进式数据迁移”策略，确保新旧版本代码都能读写同一份数据。对于无法兼容的变更，应拆分为多个小版本逐步发布。
2.4 蓝绿环境与 SLO 门禁的衔接
在蓝绿发布流程中，SLO 门禁系统在流量切换前对绿环境进行质量评估，只有通过门禁检查的环境才能承接生产流量。门禁检查项通常包括：
- 延迟 SLO：绿环境 P99 延迟 ≤ 基线 P99 × 1.2
- 错误率 SLO：绿环境 5xx 错误率 ≤ 0.5%
- 吞吐量 SLO：绿环境 QPS ≥ 基线 QPS × 0.9
- 资源水位：CPU 使用率 ≤ 70%，内存使用率 ≤ 80%
- 健康检查：所有实例通过 HTTP 健康检查，无重启或 CrashLoopBackOff
门禁检查通过后，系统自动执行流量切换；若检查失败，则阻断发布并触发告警，由 SRE 工程师介入排查。这种“门禁前置”的设计将质量左移，有效防止劣化版本流入生产环境。