3. 架构总览：指标采集层、计算引擎层、准入控制层、发布编排层的分层架构与数据流
指标门禁与灰度发布准入系统采用四层分层架构，各层职责清晰、数据单向流转、控制指令反向传递。理解每一层的边界与数据流是故障排查的基础——80% 的准入异常都可以通过定位数据在哪一层断裂来快速缩小排查范围。
3.1 四层架构总览
系统从下至上分为：指标采集层 → 计算引擎层 → 准入控制层 → 发布编排层。数据自下而上汇聚，控制指令自上而下执行。
排查原则： 故障发生时，先确认数据是否到达计算引擎层（数据面），再确认准入控制层是否收到计算结果（控制面），最后检查发布编排层是否执行了正确的阻断或放行动作。
3.2 各层职责与关键组件
| 层级 | 核心职责 | 关键组件 | 典型故障模式 |
|---|---|---|---|
| 指标采集层 | 从目标服务、中间件、基础设施采集原始指标，打上服务名、版本、实例等标签 | Prometheus Agent、Telegraf、OTel Collector、StatsD Exporter | 采集超时、标签丢失、指标断点、Agent OOM |
| 计算引擎层 | 对原始指标进行窗口聚合、降噪、异常检测，产出门禁判定所需的聚合值 | Flink、StreamPark、自研流计算、PromQL 聚合 | 窗口延迟、数据乱序、聚合结果偏差、计算资源瓶颈 |
| 准入控制层 | 接收聚合指标，对比阈值，输出准入/阻断/熔断决策 | 门禁判定引擎、阈值配置中心、熔断开关 | 阈值配置错误、判定逻辑死循环、熔断信号丢失 |
| 发布编排层 | 根据准入决策控制灰度发布节奏，执行暂停、回滚、继续放量 | 发布引擎、灰度状态机、策略配置中心 | 状态机卡死、策略未生效、回滚指令未执行 |
3.3 数据流详解：从采集到决策
一次完整的指标门禁判定数据流包含 6 个关键步骤，任何一步断裂都会导致准入异常。
- 指标采集与打点： Agent 从目标服务拉取 /metrics 端点，或通过 Exporter 采集系统指标，附加
service=order、version=v2.3.1、instance=pod-abc等标签，写入时序数据库。 - 原始指标存储： 时序数据库（如 VictoriaMetrics、Thanos）存储原始指标，保留最近 N 小时数据用于回溯。
- 流式聚合计算： 计算引擎订阅时序数据，按
service+version维度进行 1 分钟/5 分钟滑动窗口聚合，产出p99_latency、error_rate、qps等聚合指标。 - 异常检测与降噪： 对聚合结果进行同比/环比检测，过滤毛刺和抖动，输出稳定后的指标值。
- 门禁判定： 准入控制层接收聚合指标，与预设阈值（如 p99 < 200ms、error_rate < 0.1%）比对，输出
PASS、WARN、BLOCK决策。 - 发布编排响应： 发布引擎根据决策执行对应动作：
PASS继续放量，WARN暂停观察，BLOCK触发自动回滚。
排查切入点： 当灰度发布被误阻断时，优先检查第 3 步（聚合计算）和第 5 步（门禁判定）的数据是否一致。常见根因是计算引擎的窗口时间与门禁判定层的阈值时间窗口不匹配。
3.4 控制流：反向指令传递
与数据流方向相反，控制指令从发布编排层向下传递：
- 发布编排层 → 准入控制层： 下发灰度批次信息、目标版本、放量比例，通知准入控制层开启/关闭门禁检查。
- 准入控制层 → 计算引擎层： 下发阈值变更、判定规则更新，要求计算引擎调整聚合维度或窗口大小。
- 计算引擎层 → 指标采集层： 下发采集频率调整、新增指标采集指令，要求 Agent 增加或减少采集目标。
控制流故障通常表现为：发布编排层已下发暂停指令，但准入控制层未收到，导致门禁继续放行新流量进入异常版本。
3.5 分层故障排查矩阵
| 故障现象 | 可能故障层 | 快速验证方法 |
|---|---|---|
| 门禁判定结果为空 | 指标采集层 / 计算引擎层 | 检查时序数据库中是否有目标服务的原始指标 |
| 门禁判定持续 BLOCK | 计算引擎层 / 准入控制层 | 对比原始指标与聚合指标，确认聚合是否异常 |
| 发布编排未执行回滚 | 准入控制层 / 发布编排层 | 查看准入控制层是否输出了 BLOCK 信号，以及发布引擎是否收到 |
| 灰度流量未按比例放量 | 发布编排层 | 检查灰度状态机是否卡在某个中间状态 |
| 指标延迟过高 | 指标采集层 / 计算引擎层 | 检查采集 Agent 的抓取间隔和计算引擎的窗口延迟 |
3.6 典型故障场景：数据流断裂
实战案例： 某次灰度发布中，新版本 v2.3.1 的 error_rate 持续升高，但门禁判定始终为 PASS。排查发现：指标采集层正确采集了原始指标，但计算引擎层的聚合维度只按
service 聚合，未按 version 拆分，导致新版本的异常被老版本的平均值掩盖。修复后，门禁正确识别异常并触发回滚。
排查要点：
- 确认指标采集层是否按
service + version + instance三个维度打点 - 确认计算引擎层的聚合 group-by 维度是否包含
version - 确认准入控制层的阈值配置是否与聚合窗口对齐
- 确认发布编排层是否在灰度批次开始时正确通知准入控制层开启门禁