2. 在线推理链路概述
在线推理链路是规则引擎在毫秒级响应约束下，完成从规则加载到动作执行的完整数据流。与离线批量推理不同，在线链路必须同时满足低延迟与高吞吐两个核心约束，任何环节的阻塞都会直接导致服务超时或雪崩。
2.1 链路基本组成
一条标准的在线推理链路由三个串行阶段构成：规则加载 → 条件匹配 → 动作执行。每个阶段内部又包含若干子步骤，如下图所示。
核心原则：规则加载是“一次加载、多次匹配”；条件匹配是“快速剪枝、精确命中”；动作执行是“幂等、可观测、可回滚”。
2.2 规则加载（Rule Loading）
规则加载是链路的第一道关卡，负责将规则定义从持久化存储（数据库、文件、配置中心）拉取到内存中，并转换为引擎可执行的内部结构。该阶段通常由独立的后台线程或定时任务触发，不占用在线请求的 CPU 时间片。
| 子步骤 | 说明 | 典型耗时 |
|---|---|---|
| 规则源拉取 | 从 DB / Git / Apollo 等源获取原始规则文本或 DSL | 10～200 ms |
| 语法校验 & 编译 | 解析 DSL 为 AST，校验类型与引用合法性 | 5～50 ms / 条 |
| RETE / 决策树构建 | 将规则条件编译为匹配网络或决策树结构 | 20～500 ms |
| 内存索引建立 | 为常用字段建立哈希索引，加速后续匹配 | 5～30 ms |
| 版本热加载 | 原子切换规则版本，避免加载中请求读到不一致状态 | < 1 ms（指针切换） |
优化要点：规则加载阶段最容易出现“全量加载阻塞”问题。建议采用增量加载 + 版本快照策略，每次只加载变更规则，并通过 Copy-on-Write 机制保证线上请求无感。
2.3 条件匹配（Condition Matching）
条件匹配是在线推理链路的核心计算瓶颈。引擎接收一个或多个事实对象（Fact），在已加载的规则集中找出所有满足条件的规则，并按优先级排序生成冲突集（Conflict Set）。
现代规则引擎普遍采用 RETE 算法或其变体（RETE-OO、RETE-NT）来优化匹配效率。RETE 网络将规则条件拆解为 Alpha 节点（单条件过滤）和 Beta 节点（多条件 Join），通过状态共享避免重复计算。
常见陷阱：当规则数量超过 10,000 条时，RETE 网络的 Beta 节点 Join 操作可能产生指数级中间结果。必须引入节点共享和约束传播优化，否则匹配延迟会从微秒级飙升到百毫秒级。
2.4 动作执行（Action Execution）
动作执行阶段负责执行匹配成功的规则右部（RHS）逻辑。动作可以是简单的赋值、调用外部服务、发送消息、更新数据库等。由于动作可能产生副作用，该阶段必须保证幂等性和可观测性。
- 动作队列调度：将冲突集中的规则按优先级依次放入执行队列，支持并行或串行模式。
- RHS 表达式求值：执行规则右部的赋值、计算、函数调用等逻辑。
- 副作用操作：调用外部系统（如发短信、扣库存），必须支持重试和熔断。
- 结果聚合 & 返回：将多个规则执行结果合并为统一响应结构返回给调用方。
- 日志 & 监控埋点：记录每条规则的命中次数、执行耗时、异常信息，用于后续分析和告警。
2.5 延迟与吞吐量关键指标
在线推理链路的性能评估必须同时关注延迟和吞吐量两个维度，二者通常存在 trade-off 关系。
| 指标 | 定义 | 典型目标值 | 测量方式 |
|---|---|---|---|
| P50 延迟 | 50% 请求的端到端推理耗时 | < 5 ms | 服务端埋点 + 百分位统计 |
| P99 延迟 | 99% 请求的端到端推理耗时 | < 20 ms | 服务端埋点 + 百分位统计 |
| QPS（吞吐量） | 每秒处理的推理请求数 | > 10,000 / 单机 | 压测工具 + 计数器 |
| 规则匹配耗时 | 条件匹配阶段消耗的 CPU 时间 | < 2 ms | RETE 节点埋点 |
| 规则加载耗时 | 单次全量规则加载的完成时间 | < 1 s | 后台任务日志 |
| 内存占用 | 规则网络 + 事实缓存占用的堆内存 | < 512 MB | JVM / 进程监控 |
延迟与吞吐量的平衡策略：
• 当 QPS 要求高时，可适当增加规则加载的批次大小，减少加载频率，但会略微增加 P99 延迟。
• 当 P99 延迟要求苛刻时，应优先优化 RETE 网络的节点共享率，减少 Beta Join 的中间结果数量。
• 建议设置超时熔断：单次推理超过 50 ms 时直接降级返回默认结果，防止链路雪崩。
• 当 QPS 要求高时，可适当增加规则加载的批次大小，减少加载频率，但会略微增加 P99 延迟。
• 当 P99 延迟要求苛刻时，应优先优化 RETE 网络的节点共享率，减少 Beta Join 的中间结果数量。
• 建议设置超时熔断：单次推理超过 50 ms 时直接降级返回默认结果，防止链路雪崩。
2.6 链路整体延迟拆解
一个典型的在线推理请求，其端到端延迟可以拆解为以下组成部分。理解每个环节的耗时占比，是后续优化工作的前提。
端到端延迟 = 网络传输耗时 + 规则加载耗时（异步） + 条件匹配耗时 + 动作执行耗时 + 序列化耗时
典型占比（P50 场景）：
- 网络传输：0.5～1 ms（同机房内网）
- 规则加载：0 ms（异步，不阻塞）
- 条件匹配：1～3 ms（RETE 网络匹配）
- 动作执行：0.5～2 ms（RHS 求值 + 副作用）
- 序列化：0.2～0.5 ms（JSON/Protobuf）
合计：2.2～6.5 ms（满足 < 10 ms 的 SLA 要求）