4. 规则表示与存储：基于JSON/YAML的规则表示、规则元数据管理、规则版本控制

在低延迟风控规则引擎中，规则的表示与存储是决定推理性能与可维护性的基础层。本章聚焦于规则的结构化表示（JSON/YAML）、元数据管理机制以及版本控制策略，确保规则在高速推理链路中既能被高效解析，又能被安全、可追溯地管理。

4.1 基于JSON/YAML的规则表示

规则引擎的输入格式直接影响解析效率与跨系统兼容性。JSON与YAML是业界最广泛使用的两种结构化表示格式，各有适用场景。

以下是一个典型的风控规则在JSON中的表示示例，包含条件、动作与元数据字段：

{
  "ruleId": "R10042",
  "name": "高频交易拦截",
  "priority": 10,
  "enabled": true,
  "conditions": {
    "operator": "AND",
    "items": [
      { "field": "transactionAmount", "operator": "GT", "value": 50000 },
      { "field": "transactionCount1h", "operator": "GTE", "value": 10 },
      { "field": "userRiskLevel", "operator": "IN", "value": ["high", "critical"] }
    ]
  },
  "action": {
    "type": "BLOCK",
    "reasonCode": "HIGH_FREQ_LARGE_AMT",
    "notify": true
  },
  "metadata": {
    "version": 3,
    "author": "risk-team",
    "effectiveFrom": "2025-06-01T00:00:00Z"
  }
}

YAML版本更适用于人工编写与审核的场景：

ruleId: R10042
name: 高频交易拦截
priority: 10
enabled: true
conditions:
  operator: AND
  items:
    - field: transactionAmount
      operator: GT
      value: 50000
    - field: transactionCount1h
      operator: GTE
      value: 10
    - field: userRiskLevel
      operator: IN
      value: [high, critical]
action:
  type: BLOCK
  reasonCode: HIGH_FREQ_LARGE_AMT
  notify: true
metadata:
  version: 3
  author: risk-team
  effectiveFrom: 2025-06-01T00:00:00Z

4.2 规则元数据管理

元数据是规则的可观测性与治理基础。每条规则除了条件与动作外，必须携带足够的元数据字段，以支持审计、性能分析、灰度发布与回滚。

核心元数据字段清单：

• 标识与版本： ruleId（全局唯一）、version（递增整数）、commitId（Git提交哈希）
• 生命周期： status（draft / active / deprecated / retired）、effectiveFrom、effectiveTo
• 归属与责任： owner（团队或个人）、author（最后修改者）、reviewer（审批人）
• 性能特征： avgEvalTimeMs（平均评估耗时）、hitCount（命中次数）、errorCount（异常次数）
• 依赖关系： dependsOn（前置规则ID列表）、tags（业务标签，如“跨境支付”“新用户”）

以下是一个包含完整元数据的规则存储表结构示例（关系型数据库视角）：

4.3 规则版本控制

规则版本控制确保每次变更都可追溯、可回滚、可灰度。低延迟引擎通常采用“快照+增量”的版本管理策略，而非全量复制。

版本控制核心机制：

1. 语义化版本号： 主版本号（不兼容变更）+ 次版本号（兼容新增）+ 修订号（缺陷修复），例如 v2.3.1。
2. 快照发布： 每次发布生成一个不可变的规则快照（包含所有规则在某一时刻的完整状态），快照ID与版本号绑定。
3. 增量补丁： 在快照基础上，仅存储变更的规则增量（diff），减少存储与加载开销。
4. 灰度路由： 通过元数据中的effectiveFrom + 流量百分比字段，实现按规则版本灰度放量。

以下SVG图展示了规则从编辑到发布、再到灰度与回滚的完整版本控制流程：

4.4 规则存储架构

低延迟规则引擎的存储层通常采用“冷热分离”架构：热存储（内存/Redis）存放当前活跃规则快照，冷存储（MySQL/对象存储）存放全量历史版本。规则变更时，通过异步管道将增量同步至热存储，保证推理链路无阻塞。

以下SVG图展示了规则存储的冷热分离架构：