准入指标门禁概念
灰度发布的核心挑战在于：如何在不中断线上服务的前提下，安全地将新版本流量逐步放大。准入指标门禁正是解决这一挑战的关键机制——它通过在灰度流程的关键节点设置可量化的“检查点”，确保只有满足预设健康条件的版本才能继续扩大流量。
什么是准入指标
准入指标（Admission Metrics）是指在灰度发布流程中，用于判断当前版本是否具备进入下一阶段资格的一组预定义可量化数据。这些指标通常来源于可观测性平台（如 Prometheus、Grafana Mimir、Datadog 等），涵盖服务健康、业务质量、资源消耗等多个维度。
| 指标类别 | 典型指标 | 说明 |
|---|---|---|
| 服务可用性 | 请求成功率、错误率、5xx 占比 | 反映服务是否正常处理请求 |
| 响应性能 | P50/P95/P99 延迟、平均响应时间 | 反映用户体验是否劣化 |
| 资源消耗 | CPU 使用率、内存占用、GC 频率 | 反映版本是否存在资源泄漏或异常 |
| 业务指标 | 订单转化率、支付成功率、DAU 波动 | 反映版本对核心业务的影响 |
| 基础设施 | Pod 重启次数、连接池水位、磁盘 IO | 反映基础设施层面的稳定性 |
实践建议：准入指标应遵循“少而精”原则。建议每个灰度阶段选择 3~5 个核心指标作为门禁判断依据，避免指标过多导致门禁频繁误触发或难以排查。
门禁策略的作用
门禁策略（Gating Policy）是将准入指标与阈值、持续时间、对比基线等规则组合而成的决策逻辑。它的核心作用包括：
- 自动化决策：替代人工观察 Grafana 仪表盘，由系统自动判断版本是否健康。
- 风险拦截：在指标异常时立即阻断流量继续扩大，防止故障扩散。
- 回滚触发：当指标严重偏离基线时，自动触发回滚操作，恢复稳定版本。
- 灰度节奏控制：根据指标表现动态调整流量比例，而非固定时间窗口。
关键认知：门禁策略不是简单的“指标 > 阈值”判断，而是包含持续时间窗口（如持续异常 30 秒）、对比基线（如与上一版本对比偏差 > 10%）、多指标组合（如成功率 < 99.9% 且延迟 > 200ms）的复合逻辑。
门禁在灰度流程中的位置
在典型的灰度发布流程中，门禁检查点通常部署在流量切换的关键节点。下图展示了门禁在灰度流程中的核心位置：
门禁检查的典型流程
在灰度发布的每个阶段，门禁检查遵循以下标准步骤：
- 指标采集：从可观测性平台拉取当前版本的准入指标数据。
- 基线对比：将当前指标与稳定版本基线或预设阈值进行对比。
- 持续时间验证：确认异常状态是否持续超过预设窗口（如 30 秒）。
- 多指标聚合：综合所有准入指标进行加权或组合判断。
- 决策输出：输出“通过 / 阻断 / 回滚”三种结果。
常见误区：门禁检查不应仅依赖单一时间点的指标快照。由于指标采集存在延迟（通常 10~30 秒），且瞬时的毛刺可能误触发门禁，建议设置至少 2~3 个采集周期的持续观察窗口。
门禁策略的配置示例
以下是一个基于 Prometheus 指标的门禁策略配置示例，使用 YAML 格式定义：
gating_policy:
name: "production-canary-gate"
stages:
- stage: "1%_canary"
duration: "5m"
rules:
- metric: "http_request_success_rate"
query: "sum(rate(http_requests_total{status=~'2..|3..'}[1m])) / sum(rate(http_requests_total[1m]))"
threshold: 0.999
operator: "gt"
window: "30s"
- metric: "p99_latency"
query: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1m])) by (le))"
threshold: 0.5
operator: "lt"
baseline_deviation: 0.1
- stage: "10%_scale"
duration: "10m"
rules:
- metric: "error_rate_5xx"
threshold: 0.001
operator: "lt"
window: "1m"
- metric: "cpu_usage_percent"
threshold: 80
operator: "lt"
window: "2m"