4. 核验引擎架构

核验引擎是云原生运行基线核验系统的核心执行单元。本章从架构视角将其拆解为四个逻辑层：输入层、规则引擎层、评估层与输出层。每一层职责清晰、接口明确，共同构成可水平扩展、可热插拔规则的核验流水线。

4.1 四层架构总览

核验引擎采用分层流水线模式，数据依次经过四个阶段，每个阶段只处理本层关注的问题，避免跨层耦合。下表总结了各层的核心职责与输入输出关系：

4.2 输入层：数据采集与归一化

输入层负责从多个异构数据源获取集群的实时状态与配置信息，并将其转换为统一的内部数据结构——统一资源模型（URM）。URM 是一个扁平化的键值结构，包含资源类型、名称、命名空间、标签、规范字段与状态字段。

输入层需要处理的数据源类型包括：

• Kubernetes API Server：通过 Informer 机制监听 Pod、Deployment、Service、NetworkPolicy 等资源变化。
• Prometheus / VictoriaMetrics：查询指标数据，如 CPU 使用率、内存使用率、API Server 延迟。
• 日志系统：从 Loki 或 Elasticsearch 提取审计日志、容器标准输出。
• CMDB / 基础设施 API：获取节点规格、可用区、安全组等元数据。

输入层的关键设计要点：

• 适配器模式：每种数据源对应一个适配器，负责协议转换与错误重试。
• 增量与全量结合：首次启动执行全量采集，后续通过 Watch/Webhook 接收增量变更。
• 数据新鲜度标记：每个 URM 对象携带采集时间戳，供评估层判断数据是否过期。

4.3 规则引擎层：规则加载与条件匹配

规则引擎层是核验引擎的“大脑”，负责加载基线规则、解析条件表达式、并将规则与 URM 数据进行匹配，生成待执行的断言集合。

规则引擎的核心组件：

• 规则仓库：支持从本地文件、Git 仓库、ConfigMap 或 OPA Bundle 加载规则。规则格式采用 YAML 或 Rego。
• 条件解析器：将规则中的条件表达式（如 cpu_usage > 80、replicas < min_replicas）编译为可执行断言函数。
• 上下文构建器：将 URM 数据与规则所需的辅助数据（如集群名称、环境标签）组装成上下文对象。

apiVersion: baseline.核验.io/v1
kind: Rule
metadata:
  name: deployment-min-replicas
spec:
  scope:
    resourceType: Deployment
    namespace: "production"
  conditions:
    - field: spec.replicas
      operator: lt
      value: 3
  severity: critical
  message: "生产环境 Deployment {{.name}} 副本数低于 3"

规则引擎层采用预编译 + 缓存策略：规则在加载时即完成编译，避免每次评估时重复解析。当规则仓库发生变更时，引擎通过热更新机制重新加载，无需重启服务。

4.4 评估层：断言执行与结果聚合

评估层接收规则引擎输出的断言集合，逐条执行断言，并将结果聚合为核验结果记录。评估层是性能敏感区域，需要高效处理大量并发断言。

评估流程分为三个步骤：

1. 断言执行：每个断言是一个无状态函数，输入为上下文对象，输出为布尔值 + 可选消息。执行引擎使用 Goroutine 池并发执行，默认池大小为 100。
2. 结果聚合：同一资源的所有断言结果按规则 ID 聚合，生成 EvaluationResult 对象，包含资源标识、通过/失败状态、失败断言列表、时间戳。
3. 阈值判定：对于数值型指标，评估层支持“软阈值”与“硬阈值”两级判定。软阈值触发 Warning，硬阈值触发 Critical。

4.5 输出层：结果分发与持久化

输出层将评估层生成的核验结果转换为多种输出格式，并分发到不同的消费端。输出层采用观察者模式，支持动态注册输出通道。

输出层支持的输出通道：

输出层还负责结果去重与降噪：对于短时间内重复的相同失败断言，输出层会合并为一条记录，并附带出现次数，避免告警风暴。

4.6 核验引擎架构总图

下图展示了核验引擎的四层架构及其数据流向。输入层从多个数据源采集数据并归一化为 URM；规则引擎层加载规则并生成断言；评估层执行断言并聚合结果；输出层将结果分发到多个通道。

4.7 层间接口契约

为保证各层可独立演进，层间通信采用严格的接口契约。以下为关键接口定义：

4.8 本章小结