跳到主要内容

规则引擎核心

引用文件

本文引用的文件

目录​

  1. 简介
  2. 项目结构
  3. 核心组件
  4. 架构总览
  5. 详细组件分析
  6. 依赖分析
  7. 性能考虑
  8. 故障排查指南
  9. 结论
  10. 附录

简介​

本文件面向规则引擎核心功能的技术文档，聚焦于 LiteFlow 规则引擎在业务系统中的集成与落地，涵盖以下主题：

  • FlowExecutor 的使用与规则链执行流程
  • 规则匹配算法与候选规则筛选逻辑
  • 设备上下文 DeviceContext 的设计理念与数据结构
  • 规则执行完整流程：候选规则获取、规则条件判断、业务 ID 提取
  • 规则引擎配置参数说明与性能优化建议
  • 实际使用场景与代码路径指引

项目结构​

规则引擎相关代码主要位于 yudao-module-rule 模块的 API 层，包含工具类、上下文、DAO、API 接口、自动配置与缓存常量等。

Mermaid Diagram Code:

graph TB
subgraph "规则引擎API层"
Util["RuleRunUtil<br/>规则运行工具类"]
Ctx["DeviceContext<br/>设备上下文"]
CtxUtil["DeviceContextUtil<br/>上下文工具类"]
DAO["ApiLiteflowChainRedisDAO<br/>Redis缓存DAO"]
API["RuleBusinessApi<br/>业务交互API(Feign)"]
AutoCfg["RuleComponentAutoConfiguration<br/>组件自动配置"]
Enums["CacheConstants<br/>缓存常量"]
RC["RuleConstants<br/>规则常量"]
end
Util --> DAO
Util --> API
Util --> Ctx
Util --> Enums
Ctx --> CtxUtil
AutoCfg --> |"扫描组件包"| Util
AutoCfg --> |"扫描事件包"| Util

图表来源

章节来源

核心组件​

  • RuleRunUtil：规则运行主入口，负责三级缓存查询、候选规则筛选、规则链执行、业务 ID 提取与数量限制检查。
  • DeviceContext：设备上下文扩展，继承设备响应 DTO 并增加 properties、心跳时间等字段，便于规则节点读取。
  • ApiLiteflowChainRedisDAO：Redis 缓存访问层，提供规则详情、规则集合、业务 ID 集合、数量限制等缓存读写。
  • RuleBusinessApi：Feign 接口，定义与规则业务系统的 RPC 交互方法。
  • RuleComponentAutoConfiguration：自动装配 LiteFlow 组件与事件扫描，使其他模块可加载 rule-api 中的组件。
  • CacheConstants：统一缓存键前缀与本地缓存键规范，支撑多级缓存策略。
  • RuleConstants：规则引擎相关常量，如应用名等。

章节来源

架构总览​

规则引擎整体采用“三级缓存 + 分布式锁”的读路径，结合 LiteFlow 规则链执行器完成规则匹配与业务 ID 提取。

Mermaid Diagram Code:

sequenceDiagram
participant Caller as "调用方"
participant Util as "RuleRunUtil"
participant DAO as "ApiLiteflowChainRedisDAO"
participant API as "RuleBusinessApi(Feign)"
participant Exec as "FlowExecutor(LiteFlow)"
participant Ctx as "DeviceContext"
Caller->>Util : "matchBusinessIds(businessType, device)"
Util->>Util : "构建设备上下文 DeviceContext"
Util->>DAO : "按MAC/业务类型/渠道/无限制规则集合取候选集"
DAO-->>Util : "候选规则ID集合"
Util->>Util : "遍历候选规则，逐条执行规则链"
Util->>Exec : "execute2Resp(chainName, null, Ctx)"
Exec-->>Util : "规则执行结果"
Util->>DAO : "按规则+业务类型取业务ID集合"
DAO-->>Util : "业务ID集合"
Util-->>Caller : "返回匹配成功的业务ID集合"

图表来源

详细组件分析​

RuleRunUtil：规则运行与执行编排​

  • 三级缓存策略：本地缓存 -> Redis -> 数据库，结合分布式锁避免缓存击穿。
  • 候选规则筛选：基于 MAC 专属规则、业务类型规则、渠道规则、无设备限制规则进行集合运算，得到候选集。
  • 规则链执行：通过 FlowExecutor.execute2Resp 执行 LiteFlow 规则链，传入 DeviceContext 上下文。
  • 业务 ID 提取：对匹配成功的规则，按规则+业务类型查询业务 ID 集合，并支持数量限制检查。
  • 防穿透占位符：当数据库无数据时，Redis 写入占位符以降低缓存穿透风险。

Mermaid Diagram Code:

flowchart TD
Start(["开始"]) --> BuildCtx["构建设备上下文 DeviceContext"]
BuildCtx --> GetCandidates["获取候选规则ID集合"]
GetCandidates --> EmptyCandidates{"候选集为空？"}
EmptyCandidates -- 是 --> ReturnEmpty["返回空集合"]
EmptyCandidates -- 否 --> LoopRules["遍历候选规则"]
LoopRules --> FetchDetail["获取规则详情(含启用/生效/地区/EL)"]
FetchDetail --> Enabled{"规则启用且生效？"}
Enabled -- 否 --> NextRule["跳过规则"]
Enabled -- 是 --> EvalEL["执行规则链 execute2Resp"]
EvalEL --> Matched{"规则匹配成功？"}
Matched -- 否 --> NextRule
Matched -- 是 --> AddMatched["加入匹配集"]
NextRule --> LoopRules
LoopRules --> ExtractBiz["按规则+业务类型提取业务ID集合"]
ExtractBiz --> LimitCheck["数量限制检查(本地/Redis/DB)"]
LimitCheck --> Done(["结束"])

图表来源

章节来源

DeviceContext：设备上下文设计与数据结构​

  • 继承自设备响应 DTO，复用设备字段，同时新增 properties 映射、心跳时间 heartbeatTime 与标记 hasHeartbeatUpdated。
  • 通过构造函数将设备 DTO 转换为 Map，便于规则节点直接读取任意设备属性。
  • 心跳时间仅在规则节点实际使用时懒加载，避免不必要的 IO。

Mermaid Diagram Code:

classDiagram
class DeviceRespRuleDTO {
+字段 : "设备相关字段"
}
class DeviceContext {
+Map~String,Object~ properties
+Long heartbeatTime
+boolean hasHeartbeatUpdated
+setHeartbeatTime(heartbeatTime)
+isHasHeartbeatUpdated() boolean
}
DeviceContext --|> DeviceRespRuleDTO : "继承"

图表来源

章节来源

ApiLiteflowChainRedisDAO：缓存访问层​

  • 提供规则详情、规则集合、业务 ID 集合、数量限制等缓存读写方法。
  • 使用随机过期时间与占位符机制，提升缓存命中率与一致性。
  • 提供本地缓存清理事件发送，确保多节点一致性。

章节来源

RuleBusinessApi：业务交互接口​

  • Feign 接口，定义规则引擎与业务系统的 RPC 方法，如按 MAC/业务类型/渠道获取规则 ID、按规则+业务类型获取业务 ID、获取规则详情、数量限制等。
  • 通过 fallbackFactory 提供降级能力，保障系统稳定性。

章节来源

RuleComponentAutoConfiguration：组件自动配置​

  • 自动扫描 rule-api 中的 LiteFlow 组件与事件，使其他模块（如 task-server）可加载这些组件。

章节来源

缓存常量与规则常量​

  • CacheConstants：统一 Redis 缓存键命名规范，区分集合、哈希与普通键；同时定义本地缓存键，避免 SpEL 解析问题。
  • RuleConstants：规则引擎相关常量，如应用名等。

章节来源

依赖分析​

  • RuleRunUtil 依赖 FlowExecutor（Spring Bean）、ApiLiteflowChainRedisDAO、RuleBusinessApi、DeviceContext、CacheConstants。
  • ApiLiteflowChainRedisDAO 依赖 RedisClient 与 CacheConstants。
  • RuleBusinessApi 为 Feign 接口，依赖 ApiConstants。
  • RuleComponentAutoConfiguration 依赖组件扫描与事件扫描。

Mermaid Diagram Code:

graph LR
Util["RuleRunUtil"] --> Exec["FlowExecutor"]
Util --> DAO["ApiLiteflowChainRedisDAO"]
Util --> API["RuleBusinessApi"]
Util --> Ctx["DeviceContext"]
DAO --> RC["CacheConstants"]
AutoCfg["RuleComponentAutoConfiguration"] --> Util

图表来源

章节来源

性能考虑​

  • 三级缓存策略：优先本地缓存，其次 Redis，最后数据库，减少后端压力。
  • 分布式锁：缓存未命中时加锁查询数据库，避免缓存击穿。
  • 随机过期时间：降低缓存雪崩概率。
  • 防穿透占位符：当数据库无数据时写入占位符，减少后续重复查询。
  • 本地缓存清理事件：通过事件广播清理多节点本地缓存，保证最终一致性。
  • 规则链执行：仅对候选规则执行，避免全量扫描。
  • 数量限制检查：优先使用本地缓存，必要时再查 Redis/DB。

章节来源

故障排查指南​

  • 规则链执行失败：检查 FlowExecutor Bean 是否存在，确认 chainName 是否正确，查看日志输出的响应消息。
  • 候选规则为空：确认 MAC/业务类型/渠道/无限制规则缓存是否正确，检查 Redis 中对应键是否存在。
  • 数量限制异常：确认业务数量限制缓存是否命中，检查占位符与本地缓存清理事件是否正常触发。
  • 分布式锁竞争：观察锁等待与释放日志，适当调整锁超时时间。
  • 设备信息刷新：可通过配置项控制是否在规则执行时重新从设备中心拉取设备信息。

章节来源

结论​

本规则引擎方案通过“三级缓存 + 分布式锁”与 LiteFlow 规则链执行器，实现了高性能、可扩展的规则匹配与业务 ID 提取能力。DeviceContext 作为上下文载体，提供了灵活的数据访问方式；配合统一的缓存常量与自动配置，降低了模块间的耦合度。建议在生产环境中结合监控与告警，持续优化缓存命中率与规则链执行效率。

附录​

配置参数说明​

  • liteflow.getDeviceOnRule：布尔型，控制规则执行时是否重新从设备中心拉取设备信息。默认关闭，避免额外 IO。

章节来源

使用场景与代码路径​

用户文档
AI 助手
Agent 列表
请选择一个 Agent 开始对话
AI 问答