4. 在线推理架构:事件驱动架构、规则加载与评估流程、低延迟要求
在线推理架构是规则冲突处理系统的运行时骨架。它必须同时满足三个核心约束:事件驱动(被动响应而非轮询)、规则动态加载(不停机更新)、低延迟(毫秒级判定)。本章从架构分层、规则加载机制、评估流水线三个维度展开,并给出满足生产要求的参考实现。
4.1 事件驱动架构分层
在线推理系统采用典型的事件驱动微服务架构,分为四层:
| 层级 | 组件 | 职责 | 延迟要求 |
|---|---|---|---|
| 接入层 | Kafka / Pulsar / HTTP Gateway | 接收原始事件,反序列化,分配 Partition Key | < 5 ms |
| 规则引擎层 | Flink CEP / Drools / 自研状态机 | 规则匹配、冲突检测、动作编排 | < 50 ms |
| 状态管理层 | RocksDB + Flink State | 会话窗口、计数、模式序列缓存 | < 10 ms (本地读写) |
| 输出层 | Kafka / gRPC / Webhook | 发送冲突告警、动作指令、审计日志 | < 5 ms |
关键设计原则: 每一层都必须是异步非阻塞的。接入层不等待规则引擎结果;规则引擎不等待状态管理层的远程调用。所有跨层通信通过消息队列解耦。
4.2 规则加载与评估流程
规则加载分为冷启动和热更新两种场景。冷启动在作业启动时从外部存储(MySQL / Apollo / Git)全量拉取;热更新通过监听配置变更 Topic 增量推送。
4.2.1 规则加载流程
- 规则源监听:Flink Source 订阅规则变更 Topic(如
rule-change-v1),解析 JSON/YAML 格式的规则定义。 - 规则编译:将 DSL 规则编译为可执行的 Pattern / 状态机。编译结果包含:规则 ID、优先级、条件表达式、动作列表、冲突分组。
- 规则注册:将编译后的规则对象写入
BroadcastState(MapState<String, Rule>),保证所有并行子任务同时生效。 - 版本校验:每条规则携带
version和effectiveTimestamp,引擎按时间戳决定是否覆盖旧规则。
生产建议: 规则变更 Topic 使用
log-compacted 策略,保证重启时能恢复最新规则快照。同时保留全量规则快照在 HDFS,用于作业恢复。
4.2.2 在线评估流程
每个事件到达后,经过以下流水线:
// 伪代码:在线推理评估主循环
void evaluate(Event event, BroadcastState<String, Rule> rules, ValueState<Session> session) {
// 1. 会话关联
Session s = session.value();
if (s == null) { s = new Session(event.getUserId()); }
s.addEvent(event);
// 2. 规则遍历(按优先级降序)
for (Rule rule : rules.values().sortByPriority()) {
if (!rule.isActive()) continue;
if (rule.getGroup() != null && !s.getGroup().equals(rule.getGroup())) continue;
// 3. 条件评估
boolean matched = rule.getCondition().evaluate(s, event);
if (!matched) continue;
// 4. 冲突检测
ConflictResult conflict = conflictDetector.detect(rule, s.getMatchedRules());
if (conflict.isConflict()) {
// 5. 冲突处理:按策略(丢弃/覆盖/合并)
handleConflict(conflict, rule, s);
} else {
// 6. 执行动作
executeAction(rule.getAction(), event, s);
s.addMatchedRule(rule.getRuleId());
}
}
// 7. 更新会话状态
session.update(s);
}
4.3 低延迟保障措施
在线推理对延迟极度敏感。以下措施是生产环境的标配:
| 措施 | 实现方式 | 预期效果 |
|---|---|---|
| 状态本地化 | RocksDB + 异步写 WAL,避免远程 RPC | 状态读写 < 1 ms |
| 规则索引 | 按事件类型、用户分组建立哈希索引 | 规则匹配 O(1) ~ O(log n) |
| 预编译条件 | 将 DSL 编译为字节码或表达式树 | 条件评估 < 0.1 ms |
| 批量处理 | 按 Partition 攒批,减少序列化开销 | 吞吐提升 3~5 倍 |
| 背压感知 | Flink 自动反压 + 限流 | 避免 OOM 和延迟抖动 |
避坑提醒: 不要在规则评估过程中做任何 I/O 操作(如查数据库、调用外部 API)。所有外部数据必须在事件进入引擎前预加载到状态或广播变量中。一次外部调用可能将延迟从 5 ms 拉高到 200 ms。
4.4 在线推理架构总览
下图展示了完整的在线推理架构,包含事件流入、规则加载、评估流水线和输出路径:
4.5 规则冲突检测的在线评估流程
冲突检测是规则引擎中最复杂的环节。下图展示了冲突检测在评估流程中的具体位置和分支逻辑:
性能关键点: 冲突检测必须在规则引擎内部完成,不能依赖外部服务。建议使用内存中的
BitMap 或 BloomFilter 快速判断规则是否已匹配,避免全量遍历会话历史。