2. 指标门禁概念
2.1 指标门禁的定义
指标门禁（Metric Gate）是一套基于预定义可观测性指标的自动化准入/准出判定机制。在灰度发布场景中，它通过实时采集新版本实例的黄金指标（延迟、流量、错误、饱和度），与基线或阈值进行比对，输出“通过”或“阻断”的二元决策，从而控制灰度流量比例的自动演进。
核心公式：指标门禁 = 可观测性指标 × 判定策略 × 自动化动作。三者缺一不可。
指标门禁的典型工作流程如下：
- 指标采集：从 Prometheus、Datadog 等监控系统拉取新版本实例的实时指标。
- 基线对齐：将新版本指标与旧版本基线（或预设静态阈值）进行对比。
- 策略判定：根据配置的容忍度（如 P99 延迟偏差 < 20%）输出通过/阻断。
- 自动化动作：通过则继续扩大灰度比例；阻断则触发回滚或暂停发布。
关键认知：指标门禁不是“告警”，而是发布流程中的前置条件检查。告警通知人，门禁阻止坏版本。
2.2 在灰度发布准入中的作用
指标门禁在灰度发布中承担“安全阀”与“加速器”的双重角色。其核心作用可归纳为以下四点：
| 作用维度 | 具体说明 | 典型场景 |
|---|---|---|
| 风险前置拦截 | 在灰度流量比例较小时（如 1%~5%）快速发现异常，阻止坏版本扩散到全量用户。 | 新版本内存泄漏导致 OOM，门禁在 2 分钟内阻断。 |
| 自动化决策 | 替代人工盯屏，根据指标自动判定是否允许进入下一阶段（如 10% → 50% → 100%）。 | P99 延迟稳定在基线 +5% 以内，自动推进灰度比例。 |
| 多维度健康评估 | 同时检查延迟、错误率、CPU、内存等多个指标，避免单一指标误判。 | 错误率正常但延迟飙升，门禁仍会阻断。 |
| 发布节奏控制 | 通过门禁的通过/阻断信号，控制灰度流水线的下一步执行（推进/暂停/回滚）。 | 阻断后自动触发回滚脚本，并通知 SRE 介入。 |
下图展示了指标门禁在灰度发布流水线中的位置与决策逻辑：
2.3 指标门禁与健康检查的区别
健康检查（Health Check）和指标门禁是两种不同粒度的可用性验证手段，常被混淆。下表从多个维度进行对比：
| 对比维度 | 健康检查 | 指标门禁 |
|---|---|---|
| 检查目标 | 进程/服务是否存活、端口是否监听 | 服务质量是否满足 SLO、性能是否劣化 |
| 检查粒度 | 二元（存活/死亡） | 连续值（延迟、错误率、资源使用率） |
| 触发时机 | 持续周期性探测（如每 5s） | 发布阶段切换时触发（如灰度比例变更前） |
| 判定标准 | HTTP 200 / TCP 连通 / 进程 PID 存在 | P99 < 500ms、错误率 < 0.1%、CPU < 80% |
| 自动化动作 | 重启实例、摘除流量、通知告警 | 阻断发布、触发回滚、调整灰度比例 |
| 覆盖范围 | 单实例/单进程 | 整个灰度分组（多实例聚合指标） |
| 误报率 | 低（仅检测存活） | 中等（需合理配置阈值避免抖动误判） |
常见误区：健康检查通过 ≠ 版本质量合格。一个服务进程存活但 P99 延迟从 100ms 飙升到 5s，健康检查仍会返回“正常”，而指标门禁会立即阻断。两者是互补关系，不可相互替代。
下图直观展示了两者在发布流程中的不同作用层次：
最佳实践：在灰度发布准入中，健康检查作为前置条件（实例必须存活才能接入流量），指标门禁作为准入条件（服务质量必须达标才能扩大灰度）。两者串联使用，形成“存活 → 质量 → 推进”的完整安全链路。