4. 规则引擎架构：核心模块、执行流程与性能考量
规则引擎是 Policy Check 自定义规则的“大脑”。它将人类可读的策略声明转化为可执行的判定逻辑，并最终输出合规报告。理解其内部架构，是编写高性能、可维护自定义规则的前提。本章深入解析规则引擎的三大核心模块——解析器、评估器、报告器，梳理一条规则从文本到报告的完整执行流程，并给出生产环境下的关键性能考量。
4.1 核心模块：三组件架构
规则引擎采用经典的“解析-评估-报告”三阶段管道架构。每个模块职责单一、接口清晰，便于独立扩展与测试。
| 模块 | 英文名称 | 核心职责 | 输入 | 输出 |
|---|---|---|---|---|
| 解析器 | Parser | 将规则源码（YAML/JSON/Rego）转换为抽象语法树（AST）或中间表示（IR） | 规则文本 + Schema 定义 | 结构化 AST / IR |
| 评估器 | Evaluator | 遍历 AST/IR，结合上下文数据执行判定逻辑，输出布尔结果与详细原因 | AST/IR + 资源数据 + 上下文 | 判定结果（Pass/Fail/Error） |
| 报告器 | Reporter | 将评估结果格式化为结构化报告，支持多种输出格式（JSON/CSV/表格） | 判定结果 + 元数据 | 合规报告 |
架构原则： 三模块之间通过不可变数据结构通信（AST、判定结果对象），避免共享可变状态。这使得每个模块可以独立进行单元测试、性能优化甚至替换实现语言。
4.2 解析器（Parser）：从文本到结构
解析器是规则引擎的入口。它负责将用户编写的规则定义（如 Rego 策略、自定义 YAML DSL）转换为引擎内部可遍历的树形结构。
- 词法分析（Lexer）： 将原始字符流拆分为有意义的 序列（关键字、标识符、运算符、字面量）。
- 语法分析（Parser）： 根据预定义的文法规则，将 序列组合为抽象语法树（AST）。AST 保留了规则的逻辑层次与操作符优先级。
- 语义分析（Semantic Check）： 验证 AST 中的变量引用、类型匹配、函数调用是否合法。例如，检查引用的服务目录属性是否存在。
- 中间表示生成（IR Generation）： 将 AST 转换为更接近执行引擎的中间表示（如 DAG 或指令列表），便于后续高效评估。
性能关键点： 解析阶段通常只执行一次（规则加载时），因此对速度要求不如评估器苛刻。但解析器必须提供清晰的错误信息（行号、列号、预期 ），帮助开发者快速定位语法错误。
4.3 评估器（Evaluator）：核心判定引擎
评估器是规则引擎的性能核心。它接收解析器产出的 IR 和运行时数据，执行实际的策略判定。
- 数据绑定： 将服务目录中的资源属性、上下文变量注入评估环境。
- 条件求值： 遍历 IR 节点，执行比较、逻辑运算（AND/OR/NOT）、集合操作（in/not in）、正则匹配等。
- 短路优化： 对于 AND 链，一旦遇到 False 立即停止后续条件求值；对于 OR 链，遇到 True 立即返回。大幅减少不必要的计算。
- 缓存策略： 对同一资源多次引用的子查询结果进行缓存，避免重复计算。
- 错误处理： 当数据缺失、类型不匹配或函数执行异常时，评估器应返回 Error 状态而非崩溃，并附带错误原因。
避坑指南： 避免在规则中使用高复杂度循环（如嵌套迭代所有子网）。评估器应设置最大执行步数或超时时间（如 5 秒），防止恶意或错误规则导致引擎挂起。
4.4 报告器（Reporter）：输出合规结论
报告器将评估结果转化为可消费的格式。它不改变判定逻辑，只负责呈现。
| 输出格式 | 适用场景 | 包含字段 |
|---|---|---|
| JSON | API 集成、CI/CD 管道解析 | rule_id, resource_id, status, message, severity, timestamp |
| CSV | 批量导出、Excel 分析 | 同上，以逗号分隔 |
| 表格（终端/Web） | 人工审查、即时反馈 | 带颜色高亮的 Pass/Fail/Error 状态列 |
| SARIF | 集成到 GitHub/Security 工具 | 标准静态分析结果交换格式 |
4.5 执行流程：一条规则的完整生命周期
下图展示了从规则加载到报告输出的完整执行流程，包含三个核心模块的协作关系。
4.6 性能考量：生产环境的关键指标
规则引擎的性能直接影响 CI/CD 管道的反馈速度。以下是需要重点关注的维度：
| 维度 | 关键指标 | 优化策略 |
|---|---|---|
| 规则加载时间 | 解析 + 编译耗时（ms） | 预编译规则为二进制 IR；使用增量加载而非全量重载 |
| 单规则评估延迟 | P50 / P99 耗时（μs/ms） | 启用短路求值；避免正则回溯；限制集合遍历深度 |
| 并发评估吞吐 | 规则数/秒 | 使用无锁数据结构；评估器无状态化，支持水平扩展 |
| 内存占用 | AST/IR 大小 + 缓存大小（MB） | 共享常量池；设置 LRU 缓存上限；及时释放中间结果 |
| 错误恢复 | 单规则崩溃是否影响全局 | 每个规则在独立沙箱中评估；捕获 panic 并转为 Error 状态 |
生产建议： 在规则开发阶段，使用
--benchmark 标志对自定义规则进行性能分析。重点关注评估器中的循环次数和函数调用深度。对于超过 100ms 的规则，应主动优化或拆分。
4.7 架构图：模块间数据流与依赖关系
以下架构图从更高维度展示了规则引擎在服务目录集成中的位置，以及各模块之间的数据流方向。
架构要点： 缓存层位于评估器与报告器之间，对重复的资源属性查询（如“所有 VPC 的 CIDR 列表”）进行缓存，避免每次评估都重新遍历服务目录。缓存失效策略建议使用基于资源版本号的主动失效。