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 规则加载流程

  1. 规则源监听:Flink Source 订阅规则变更 Topic(如 rule-change-v1),解析 JSON/YAML 格式的规则定义。
  2. 规则编译:将 DSL 规则编译为可执行的 Pattern / 状态机。编译结果包含:规则 ID、优先级、条件表达式、动作列表、冲突分组。
  3. 规则注册:将编译后的规则对象写入 BroadcastState(MapState<String, Rule>),保证所有并行子任务同时生效。
  4. 版本校验:每条规则携带 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 在线推理架构总览

下图展示了完整的在线推理架构,包含事件流入、规则加载、评估流水线和输出路径:

在线推理事件驱动架构图 在线推理事件驱动架构 接入层 Kafka / Pulsar 反序列化 · 分配 Key 规则引擎层 Flink CEP / Drools 匹配 · 冲突检测 · 动作 状态管理层 RocksDB + Flink State 会话 · 计数 · 模式缓存 输出层 Kafka / gRPC 告警 · 指令 · 审计 规则加载 MySQL / Apollo / Git 编译 · 注册 · 版本校验 事件流 结果 读写状态 规则广播 说明: 规则加载与事件处理完全异步。规则变更通过 BroadcastState 广播到所有并行子任务,无需重启作业。 端到端延迟预算(P99 < 100 ms) 接入层 5 ms → 规则引擎 50 ms → 状态管理 10 ms → 输出层 5 ms 网络传输 & 序列化 30 ms(含 Kafka 内部延迟) 总预算:5 + 50 + 10 + 5 + 30 = 100 ms

4.5 规则冲突检测的在线评估流程

冲突检测是规则引擎中最复杂的环节。下图展示了冲突检测在评估流程中的具体位置和分支逻辑:

规则冲突检测在线评估流程 规则冲突检测在线评估流程 事件到达 会话关联 规则遍历(优先级降序) 条件评估 匹配? 否 继续下一条规则 是 冲突检测 冲突? 否 执行动作 是 冲突处理 冲突处理策略: • 丢弃:低优先级规则不执行 • 覆盖:高优先级覆盖低优先级 • 合并:同时执行(需幂等)
性能关键点: 冲突检测必须在规则引擎内部完成,不能依赖外部服务。建议使用内存中的 BitMap 或 BloomFilter 快速判断规则是否已匹配,避免全量遍历会话历史。

4.6 总结