2、蓝绿发布基础：蓝绿环境定义、流量切换机制、回滚策略、与传统滚动更新的区别
蓝绿发布（Blue-Green Deployment）是一种通过维护两套独立的生产环境（蓝环境与绿环境）来实现零停机发布与快速回滚的部署策略。在 Prometheus 监控体系下，蓝绿发布的每个环节都可以被精确观测，从而为自动化故障排查提供数据基础。
2.1 蓝绿环境定义
蓝绿发布的核心是同时运行两套完全相同的生产环境，但只有其中一套承载实时用户流量。
| 环境角色 | 状态 | 说明 |
|---|---|---|
| 蓝环境（Blue） | 当前生产环境 | 承载所有用户流量，运行稳定版本（v1） |
| 绿环境（Green） | 预发布/待切换环境 | 部署新版本（v2），完成内部验证与监控预热 |
关键原则：两套环境在基础设施层面（网络、数据库、缓存、配置）必须保持对等，差异仅在于应用版本号。数据库通常采用双向兼容或共享只读副本策略，确保切换后数据不丢失。
2.2 流量切换机制
流量切换是蓝绿发布的核心动作，通过负载均衡器或网关将用户流量从蓝环境瞬间切换到绿环境。切换粒度可以是全量切换，也可以是灰度百分比切换。
切换流程
- 预热阶段：绿环境启动后，内部发送健康检查与合成请求，确保服务正常；Prometheus 开始采集绿环境指标。
- 验证阶段：通过内部测试或小范围灰度流量验证绿环境功能与性能。
- 切换阶段：修改负载均衡配置，将流量权重从蓝环境（100%）调整为绿环境（100%）。
- 观察阶段：保持蓝环境在线，持续观察绿环境指标（错误率、延迟、吞吐量）。
Prometheus 监控关键指标：
up{env="green"}— 绿环境实例存活状态http_requests_total{env="green", status=~"5.."}— 绿环境 5xx 错误率histogram_quantile(0.99, ...)— 绿环境 P99 延迟gateway_traffic_ratio{env="green"}— 网关流量分配比例
2.3 回滚策略
蓝绿发布的最大优势在于回滚速度极快。由于旧版本环境（蓝环境）仍然在线且未被销毁，回滚只需将流量切回即可。
| 回滚场景 | 触发条件 | 操作 | 预期耗时 |
|---|---|---|---|
| 自动回滚 | Prometheus 告警触发（如错误率突增 >5%、P99 延迟 >500ms） | 自动化脚本将流量权重切回蓝环境 | < 30 秒 |
| 手动回滚 | 运维人员发现功能异常或监控告警 | 手动修改网关配置或执行回滚命令 | < 1 分钟 |
| 保留期回滚 | 切换后 24 小时内发现数据不一致 | 蓝环境仍在线，直接切回并修复数据 | < 2 分钟 |
注意：回滚后必须检查数据库兼容性。如果新版本（v2）修改了数据库 Schema 且不可逆，回滚可能导致数据损坏。建议在发布前确保 Schema 变更向前兼容。
2.4 与传统滚动更新的区别
滚动更新（Rolling Update）是 Kubernetes 等编排平台的默认更新策略，与蓝绿发布在原理、风险、资源消耗上存在显著差异。
| 对比维度 | 蓝绿发布 | 滚动更新 |
|---|---|---|
| 环境数量 | 同时运行两套完整环境 | 只有一套环境，逐步替换 Pod |
| 资源消耗 | 高（2x 资源需求） | 低（1x + 少量缓冲） |
| 切换速度 | 秒级（流量切换） | 分钟级（逐批次替换） |
| 回滚速度 | 秒级（切回旧环境） | 分钟级（反向滚动替换） |
| 流量控制粒度 | 全量或灰度百分比 | 按 Pod 数量逐步替换 |
| 监控观测窗口 | 切换前可完整预热与监控 | 新版本逐步暴露，观测窗口碎片化 |
| 适用场景 | 关键业务、高风险变更、需要快速回滚 | 低风险更新、资源受限、无状态服务 |
实践建议：在 Prometheus 监控体系下，蓝绿发布更适合对可用性要求极高的核心服务。滚动更新则适用于资源受限或非关键服务的快速迭代。建议根据服务等级（SLO）和资源预算选择合适的发布策略。