3. Traffic Switch 概念：流量切换的定义、切换粒度与触发条件
Traffic Switch（流量切换）是蓝绿部署体系中最核心的执行动作，它决定了用户请求何时、以何种比例、在何种条件下从旧环境（蓝）迁移到新环境（绿）。理解流量切换的完整定义、粒度选择与触发条件，是编写可靠蓝绿剧本、避免漂移事故的前提。
3.1 流量切换的定义
流量切换是指通过网关、负载均衡器或服务网格等流量治理组件，将原本指向蓝环境（当前生产）的请求，有计划地导向绿环境（新版本）的过程。切换不是简单的“一键全切”，而是一个可观测、可控制、可回滚的流量调度行为。
核心公式： 流量切换 = 权重调整 + 会话保持 + 健康检查 + 熔断兜底
从技术实现角度看，流量切换涉及以下三个层面的变更：
| 层面 | 典型组件 | 切换对象 |
|---|---|---|
| 入口网关 | Nginx / HAProxy / ALB | 域名 → 后端服务器组权重 |
| 服务网格 | Istio / Linkerd | VirtualService → DestinationRule 权重 |
| 注册中心 | Consul / Nacos / Eureka | 服务实例上下线 & 权重 |
3.2 切换粒度：全量 vs 灰度
根据业务风险容忍度和验证需求，流量切换分为两种粒度：全量切换与灰度切换。两者在切换速度、验证深度和回滚代价上存在显著差异。
| 对比维度 | 全量切换 | 灰度切换 |
|---|---|---|
| 切换速度 | 一次性完成（秒级） | 分阶段逐步完成（分钟~小时级） |
| 流量比例 | 0% → 100% | 1% → 5% → 20% → 50% → 100% |
| 验证深度 | 仅依赖预发布验证 | 可在每个阶段进行线上真实流量验证 |
| 回滚代价 | 高（全量回切可能影响所有用户） | 低（仅影响当前灰度比例用户） |
| 适用场景 | 紧急修复、非核心模块、内部系统 | 核心交易链路、大版本升级、UI 改版 |
最佳实践： 即使计划做全量切换，也建议在剧本中预留一个“1% 灰度验证”步骤，持续 5~10 分钟，确认无异常后再执行全量。这是防止“上线即故障”的最后一道防线。
3.3 切换触发条件
流量切换不能仅凭“感觉”或“时间到了”就执行，必须满足明确的触发条件。根据触发来源，可分为人工触发和自动触发两类。
3.3.1 人工触发条件
- 预发布验证通过： 绿环境所有功能测试、回归测试、性能压测结果达标。
- 变更审批完成： 获得变更委员会（CAB）或技术负责人的书面/电子审批。
- 监控基线确认： 蓝环境当前监控指标（错误率、延迟、吞吐量）处于正常基线内。
- 窗口时间到达： 处于预定义的变更窗口（如凌晨 02:00~05:00）。
3.3.2 自动触发条件
- 健康检查持续通过： 绿环境所有实例在连续 N 次（通常 3~5 次）健康检查中均返回 200。
- 错误率阈值未触发： 灰度阶段的错误率低于预设阈值（如 < 0.1%）。
- 延迟 P99 达标： 绿环境 P99 延迟不超过蓝环境的 1.2 倍。
- 无关键告警： 在灰度观察期内未产生 P0/P1 级别告警。
避坑提醒： 自动触发条件必须配置“熔断回退”机制。例如：灰度 5% 阶段若错误率突增到 1%，系统应自动将流量切回蓝环境，并终止后续灰度步骤，而不是继续向 20% 推进。
3.4 流量切换流程总览
下图展示了从蓝环境到绿环境的完整流量切换流程，包含全量与灰度两种路径的决策节点：
3.5 切换触发条件检查清单
在实际蓝绿剧本中，建议将触发条件封装为前置检查步骤，只有全部通过才允许执行流量切换。以下是一个标准检查清单：
| 检查项 | 检查方式 | 通过标准 |
|---|---|---|
| 绿环境健康检查 | HTTP GET /healthz | 连续 5 次返回 200，响应时间 < 500ms |
| 蓝环境基线指标 | Prometheus 查询 | 错误率 < 0.05%，P99 延迟 < 200ms |
| 预发布测试结果 | 自动化测试报告 | 通过率 100%，无 P0/P1 缺陷 |
| 变更审批状态 | Jira / 工单系统 API | 状态为“已批准” |
| 窗口时间校验 | 当前时间 vs 窗口配置 | 在窗口范围内（如 02:00~04:00） |
| 依赖服务状态 | 下游服务健康检查 | 所有依赖服务状态为 UP |
剧本编写建议： 将上述检查清单写入蓝绿部署剧本的
pre_switch_checks 阶段，使用 assert 断言机制，任一检查失败则中止剧本并输出失败原因。这能有效防止“带病上线”。