📚 课程目录第3章门禁机制设计

门禁机制设计：门禁触发条件、门禁检查项（错误率、延迟、饱和度）

蓝绿发布门禁是保障生产环境稳定性的第一道防线。门禁机制的核心在于：在什么条件下触发检查，以及检查哪些黄金指标。本章围绕门禁的触发条件与三大检查项（错误率、延迟、饱和度）展开设计，确保发布过程可观测、可度量、可自动恢复。

3.1 门禁触发条件

门禁并非在发布流程的每个阶段都全量运行，而是根据发布阶段和流量特征设定不同的触发策略。常见的触发条件分为三类：

触发类型	触发时机	典型场景
时间触发	发布开始后固定时间窗口（如 5min、15min）	灰度批次切换后自动启动门禁评估
流量触发	新版本接收流量达到阈值（如 QPS > 1000）	蓝环境承接 10% 流量后触发首次检查
事件触发	监控告警、错误率突增、延迟抖动等异常事件	错误率超过基线 2 倍时立即触发门禁

设计建议：推荐采用“时间 + 流量”双重触发作为默认策略，事件触发作为紧急熔断补充。避免仅依赖单一触发条件导致门禁失效。

门禁触发后，系统进入评估窗口（Evaluation Window），在该窗口内持续采集指标并与 SLO 阈值比对。评估窗口长度通常设置为 5~10 个完整的数据采集周期（如 Prometheus 每 15s 采集一次，窗口设为 2~3 分钟）。

3.2 门禁检查项：错误率、延迟、饱和度

门禁检查项遵循 Google 提出的 USE 方法论（Utilization、Saturation、Errors）和 RED 方法论（Rate、Errors、Duration），聚焦以下三个黄金指标：

错误率（Error Rate）：请求失败的比例，包括 HTTP 5xx、超时、业务错误码。
延迟（Latency）：请求响应时间，重点关注高百分位（P99、P95）延迟。
饱和度（Saturation）：服务资源（CPU、内存、连接数）的使用程度，反映过载风险。

3.2.1 错误率检查

错误率是门禁中最敏感的指标。检查策略如下：

阈值：新版本错误率 > 1% 时直接阻断发布。
相对阈值：新版本错误率相比旧版本基线上升超过 50% 时触发门禁。
持续窗口：错误率在评估窗口内连续 3 个数据点均超标才判定为违约，避免毛刺误报。

# 示例：PromQL 错误率门禁查询
# 新版本错误率（5xx / 总请求）
sum(rate(http_requests_total{version="blue", status=~"5.."}[2m]))
/
sum(rate(http_requests_total{version="blue"}[2m]))
> 0.01

3.2.2 延迟检查

延迟检查关注用户体验，通常以 P99 延迟作为核心指标：

延迟分位	门禁阈值（示例）	说明
P50	< 200ms	一般体验基线，超标触发警告
P95	< 500ms	多数用户可接受上限，超标触发门禁
P99	< 1000ms	长尾用户容忍度，超标立即阻断

注意：延迟检查必须与旧版本基线对比。如果旧版本 P99 延迟为 800ms，新版本 P99 为 900ms，虽然未超过 1000ms 阈值，但相对上升 12.5%，应触发警告而非阻断。建议设置“相对变化率”作为辅助条件。

3.2.3 饱和度检查

饱和度反映服务是否接近容量瓶颈。常见检查项包括：

CPU 使用率：新版本 Pod 平均 CPU > 80% 时触发门禁。
内存使用率：新版本 Pod 平均内存 > 85% 时触发门禁。
连接数/线程数：数据库连接池使用率 > 70% 或线程池活跃线程 > 80% 时触发门禁。
队列深度：消息队列积压量超过基线 2 倍时触发门禁。

# 示例：PromQL 饱和度门禁查询
# 新版本 CPU 使用率（容器级别）
avg(rate(container_cpu_usage_seconds_total{namespace="production", pod=~"blue-.*"}[2m]))
> 0.8

3.3 门禁检查流程与决策树

门禁检查并非并行执行所有指标，而是按照优先级顺序逐步判定，避免资源浪费。推荐流程如下：

快速失败检查：先检查错误率，若超标则直接阻断，不再检查延迟和饱和度。
延迟检查：错误率通过后，检查 P99 延迟是否超标。
饱和度检查：延迟通过后，检查 CPU、内存、连接数等饱和度指标。
综合判定：三项均通过则门禁放行；任意一项超标则进入自动恢复流程。

  最佳实践：门禁检查应设置“宽松期”（Grace Period），即新版本刚上线的前 30~60 秒内不触发阻断，仅记录指标，避免因冷启动、缓存预热导致的误判。

3.4 门禁参数配置示例

以下是一个完整的门禁配置 YAML 示例，展示如何将触发条件与检查项组合为可执行的策略：

apiVersion: deploy.gatekeeper.io/v1
kind: BlueGreenGate
metadata:
  name: production-gate
spec:
  trigger:
    timeWindow: 5m          # 发布后 5 分钟触发
    minTraffic: 0.1         # 流量达到 10% 才触发
    eventDriven: true       # 异常事件可提前触发
  evaluation:
    window: 3m              # 评估窗口 3 分钟
    gracePeriod: 60s        # 宽松期 60 秒
    consecutiveBreaches: 3  # 连续 3 次超标才判定
  checks:
    errorRate:
      absolute: 0.01        # 阈值 1%
      relative: 0.5         # 相对基线上升 50%
      metric: "http_requests_total{status=~'5..'}"
    latency:
      p99: 1000             # P99 延迟 < 1000ms
      p95: 500              # P95 延迟 < 500ms
      relativeRise: 0.2     # 相对基线上升 20%
      metric: "http_request_duration_seconds"
    saturation:
      cpu: 0.8              # CPU 使用率 < 80%
      memory: 0.85          # 内存使用率 < 85%
      connectionPool: 0.7   # 连接池使用率 < 70%
      metric: "container_cpu_usage_seconds_total"
  action:
    onBreach: "rollback"    # 违约后自动回滚
    onPass: "continue"      # 通过后继续发布

参数调优提示：门禁阈值应根据业务特性动态调整。例如，核心交易服务的错误率阈值应设为 0.1%，而内容推荐服务可放宽至 1%。建议每季度根据 SLO 达成情况重新校准门禁参数。

3.5 门禁检查项优先级与权重

在实际生产环境中，不同检查项对用户体验的影响权重不同。建议采用加权评分模型，避免单一指标过度敏感：

检查项	权重	说明
错误率	50%	直接影响可用性，权重最高
延迟（P99）	30%	影响用户体验，权重次之
饱和度	20%	反映容量风险，权重最低

加权评分公式：

门禁得分 = (错误率得分 × 0.5) + (延迟得分 × 0.3) + (饱和度得分 × 0.2)

其中：
- 错误率得分 = 1 - (当前错误率 / 错误率阈值)，上限为 1
- 延迟得分 = 1 - (当前 P99 / P99 阈值)，上限为 1
- 饱和度得分 = 1 - (当前饱和度 / 饱和度阈值)，上限为 1

门禁得分 < 0.6 时触发阻断

注意：加权评分模型适用于“软门禁”场景（允许一定程度的违约但需人工确认）。对于“硬门禁”场景（如金融交易），建议仍采用逐项阻断策略，任何一项超标即阻断。

3.6 门禁检查的常见陷阱与规避

陷阱一：毛刺误报——单次延迟抖动导致门禁阻断。规避：设置连续超标次数（如 3 次）和宽松期。
陷阱二：基线漂移——旧版本长期运行后性能下降，导致相对阈值失效。规避：定期重置基线，或使用滑动窗口基线。
陷阱三：指标口径不一致——错误率计算包含健康检查请求，导致误判。规避：在指标中过滤健康检查路径（如 /healthz）。
陷阱四：饱和度指标滞后——CPU 使用率上升慢于流量突增。规避：增加请求队列深度、连接数等前置指标。