3. 蓝绿发布门禁原理：流量切换策略、健康检查、回滚机制与日志关联

蓝绿发布门禁的核心在于通过两套独立环境（蓝环境与绿环境）实现零停机部署。门禁系统在流量切换、健康检查与回滚三个环节中充当“安全闸门”，确保只有通过验证的新版本才能承接生产流量。本章将拆解门禁的工作原理，并建立与日志数据的关联模型。

3.1 流量切换策略：从权重分配到全量切换

蓝绿发布的流量切换并非简单的“一键切换”，而是遵循渐进式、可观测的步骤。门禁系统通常支持以下三种切换模式：

在权重递增模式下，门禁系统通过负载均衡器（如 Nginx、Envoy）逐步调整流量比例：

1. 初始验证：新版本（绿环境）承接 0% 流量，仅内部健康检查与合成监控访问。
2. 小比例放量：将 5% 生产流量导入绿环境，持续观察 5-10 分钟。
3. 逐步提升：按 25% → 50% → 75% → 100% 阶梯递增，每阶段停留一个观测窗口。
4. 全量切换：确认无异常后，将 100% 流量切至绿环境，蓝环境进入待回滚状态。

3.2 健康检查体系：多层门禁探测

门禁系统的健康检查并非单一探针，而是由三层探测构成的金字塔结构。任何一层探测失败，门禁都将阻止流量切换或触发回滚。

• L1 存活与就绪探针：Kubernetes livenessProbe 与 readinessProbe，检测进程是否存活、端口是否响应。失败阈值：连续 3 次失败。
• L2 业务功能探针：模拟用户核心操作（如登录、下单、查询），验证 API 返回状态码与响应体结构。失败阈值：5 分钟内错误率 > 1%。
• L3 数据一致性探针：对比蓝绿环境对同一数据集的查询结果，确保新版本未破坏数据完整性。失败阈值：任意字段不一致即告警。

3.3 回滚机制：快速恢复与数据保护

当门禁判定新版本异常时，回滚操作必须在 60 秒内完成。回滚机制包含以下关键步骤：

1. 流量切回：负载均衡器将 100% 流量瞬间切回蓝环境（原稳定版本）。
2. 数据库回滚：若新版本涉及 Schema 变更，执行 ALTER TABLE ... ROLLBACK 或切换至数据库快照。
3. 缓存预热：蓝环境重新加载热点缓存，避免回滚后出现缓存雪崩。
4. 日志标记：在 Loki 中写入一条 rollback_triggered 事件日志，记录回滚原因、触发时间、涉及服务列表。

3.4 日志关联模型：从门禁事件到可观测性

蓝绿发布门禁产生的所有事件（流量切换、健康检查结果、回滚触发）都应通过 结构化日志 写入 Loki，并与应用日志、基础设施日志建立关联。关联模型基于以下三个维度：

• 时间维度：所有日志统一使用 timestamp 字段，精度到毫秒，支持按时间窗口关联。
• 环境标签：每条日志携带 env=blue 或 env=green 标签，便于在 Grafana 中按环境筛选。
• 发布 ID：每次发布生成唯一 release_id，贯穿健康检查、流量切换、回滚全流程。

3.5 门禁与日志的协同工作流

在实际部署中，门禁系统与 Loki 日志平台通过以下工作流实现闭环：

1. 预切换检查：门禁向 Loki 发起查询，确认绿环境在过去 10 分钟内无 ERROR 级别日志。
2. 切换中监控：每切换 10% 流量，门禁读取 Loki 中绿环境的 request_duration_seconds 与 http_status 日志，计算实时错误率。
3. 回滚决策：若错误率超过 2%，门禁自动执行回滚，并将回滚原因写入 Loki 的 rollback_events 流。
4. 事后审计：通过 release_id 在 Loki 中检索完整发布周期日志，生成发布报告。