蓝绿发布基础：蓝绿环境定义、流量切换原理、回滚机制

蓝绿发布（Blue-Green Deployment）是一种零停机或接近零停机的发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现流量的瞬时切换与快速回滚。本节将系统定义蓝绿环境的核心要素，解析流量切换的原子操作原理，并建立可验证的回滚机制模型。

2.1 蓝绿环境定义

蓝绿环境并非简单的“测试环境”与“生产环境”，而是两套均具备完整生产能力的独立基础设施栈。在任何时刻，只有一套环境承载全部生产流量（活跃环境），另一套环境处于待命或预热状态（空闲环境）。

蓝绿环境的命名约定通常以“蓝”代表当前生产环境，“绿”代表新版本环境；切换后角色互换。在自动化变更冻结闸口中，闸口开放前绿环境必须通过全部预发布验证。

2.2 流量切换原理

蓝绿发布中的流量切换本质上是负载均衡器或网关层的一次原子性路由规则更新。切换不涉及应用实例的重启、代码的热加载或容器的重新编排，而是将入口流量的目标后端池从蓝环境整体替换为绿环境。

切换的原子操作步骤

1. 预验证完成：绿环境通过全部自动化测试、冒烟测试与验收测试，闸口状态为“通过”。
2. 数据库一致性确认：检查蓝绿数据库的 schema 版本与数据偏移量在允许范围内。
3. 负载均衡器规则更新：将生产域名（app.example.com）的后端目标从蓝环境池切换至绿环境池。
4. 连接 draining 处理：蓝环境进入“排空”模式，等待已有长连接处理完毕（通常 30–60 秒）。
5. 流量观测窗口：切换后保持 5–15 分钟的观测期，监控错误率、延迟、吞吐量等黄金信号。

流量切换的典型实现方式

2.3 回滚机制

蓝绿发布的核心优势之一在于回滚的瞬时性。由于旧版本环境（蓝环境）在切换后并未立即销毁，而是保持完整运行状态，回滚操作只需将负载均衡器的目标再次指回蓝环境即可。

回滚触发条件

• 错误率突增：观测期内 5xx 错误率超过阈值（如 > 1%）。
• 延迟恶化：P99 延迟超过基线的 2 倍。
• 功能验证失败：自动化验收测试在绿环境上出现失败。
• 业务指标异常：订单转化率、支付成功率等核心业务指标下降。
• 基础设施告警：CPU/内存/磁盘等资源使用率超过安全水位。

回滚的三种模式

回滚后的环境状态

回滚完成后，蓝环境重新承载 100% 流量，绿环境进入“隔离待查”状态。此时绿环境不应立即销毁，而是保留现场用于根因分析。自动化变更冻结闸口会记录本次回滚事件，并自动增加下一次发布的验证强度。

# 回滚操作的伪代码示例（负载均衡器 API）
def rollback_deployment(lb_client, blue_pool_id, green_pool_id):
    """
    执行蓝绿回滚：将流量从绿环境切回蓝环境
    """
    # 1. 将生产域名指向蓝环境
    lb_client.update_target_group(domain="app.example.com", pool_id=blue_pool_id)
    
    # 2. 将绿环境置为排空状态
    lb_client.drain_connections(pool_id=green_pool_id, drain_timeout=60)
    
    # 3. 记录回滚事件
    audit_log.record(event="ROLLBACK", from_env="green", to_env="blue", reason="黄金信号异常")
    
    # 4. 触发根因分析流程
    incident_trigger.create(env="green", severity="critical")
    
    return {"status": "rolled_back", "active_env": "blue"}