蓝绿部署回滚机制：快速回滚策略、数据一致性保障、回滚触发条件

蓝绿部署的核心优势之一在于其回滚速度极快——本质上是将流量从新环境（绿）切回旧环境（蓝）。然而，快速回滚不等于安全回滚。若未妥善处理数据一致性、未定义明确的触发条件，回滚操作可能引入数据损坏或更长的故障时间。本章聚焦回滚机制的三大支柱：策略、数据保障与触发条件。

1. 快速回滚策略：流量切换与版本保留

蓝绿部署的回滚不涉及重新部署旧版本，而是直接复用仍在运行的蓝环境。回滚速度取决于流量切换的粒度与自动化程度。

2. 数据一致性保障：回滚时的最大挑战

蓝绿部署中，数据层是回滚的最大风险点。如果新版本（绿）在运行期间写入了数据，回滚到旧版本（蓝）可能导致数据丢失或状态冲突。以下是三种常见的数据一致性保障模式：

2.1 只读前移 + 写回滚

• 策略：新版本仅接收读流量，写流量仍指向旧版本数据库。
• 优点：回滚时无需处理数据回迁，零数据丢失。
• 缺点：新版本无法验证写路径，测试覆盖不全。

2.2 双向同步 + 冲突检测

• 策略：蓝绿环境各自连接独立数据库实例，通过 CDC（Change Data Capture）工具（如 Debezium）双向同步。
• 优点：两个环境均可读写，回滚时数据已同步。
• 缺点：存在冲突风险，需定义冲突解决策略（如“蓝环境优先”或“时间戳优先”）。

2.3 共享数据库 + 兼容性契约

• 策略：蓝绿环境共享同一数据库，新版本必须保证 Schema 向后兼容（只加列、不加约束、不删表）。
• 优点：架构简单，回滚无需数据迁移。
• 缺点：对开发团队的数据迁移规范要求极高。

3. 回滚触发条件：自动化决策与熔断

回滚不应依赖人工判断，而应基于预定义的指标阈值自动触发。以下是生产环境中最常用的回滚触发条件分类：

3.1 错误率触发

• HTTP 5xx 比例：新版本错误率超过基线 2% 持续 30 秒。
• 业务错误码：特定业务错误（如订单创建失败）超过 1%。
• 熔断器状态：Circuit Breaker 进入 Open 状态。

3.2 延迟触发

• P99 延迟：新版本 P99 延迟超过基线 200% 持续 1 分钟。
• 平均延迟：连续 5 个采样点平均延迟 > 500ms。

3.3 资源与饱和度触发

• CPU 使用率：新版本 Pod CPU > 85% 持续 2 分钟。
• 内存 OOM：新版本容器重启次数 > 3 次/分钟。
• 连接池耗尽：数据库连接数达到 max_connections 的 90%。

3.4 业务指标触发

• 转化率下降：下单转化率较基线下降 > 5%。
• 收入异常：每分钟交易金额低于基线 10%。

# 回滚触发条件：错误率 > 2% 持续 30 秒
- alert: HighErrorRateRollback
  expr: |
    sum(rate(http_requests_total{status=~"5..", env="green"}[30s]))
    / sum(rate(http_requests_total{env="green"}[30s])) > 0.02
  for: 30s
  labels:
    severity: critical
    action: rollback
  annotations:
    summary: "绿环境错误率超过 2%，触发自动回滚"
    runbook: "https://runbook.company.com/blue-green-rollback"

4. 回滚执行步骤与验证

当触发条件满足时，自动化系统应执行以下步骤：

1. 停止新流量进入绿环境：负载均衡器将绿环境权重置为 0。
2. 等待 in-flight 请求完成：设置连接耗尽超时（通常 30–60 秒）。
3. 切换流量至蓝环境：将蓝环境权重置为 100%。
4. 执行数据一致性检查：比对关键表记录数、校验和。
5. 运行 smoke test：对蓝环境执行 3–5 个核心 API 健康检查。
6. 发送回滚通知：通过 PagerDuty/钉钉/企业微信通知团队。
7. 标记绿环境为“故障保留”：保留现场用于事后排查，不自动销毁。