规则引擎解决什么

设备上报的数据到了平台，接下来怎么办？逐条写代码，业务一变就得改程序。规则引擎把「当某设备的某指标超过阈值时，执行某动作」配置化：触发条件 + 过滤条件 + 动作。业务方自己拖拖拽拽就能配好，不用排开发。

规则引擎的价值：把业务逻辑从代码里搬出来，变成可配置的规则。
规则三要素
  • 触发什么设备、什么指标。
  • 条件阈值、持续时间、组合逻辑。
  • 动作告警、发指令、转存。
规则引擎配图：蓝青色背景上多个圆形发光节点，节点之间用箭头光路连接成网格
节点成网，箭头光路把触发一路连到动作。

触发条件与动作

触发可以是某个属性上报、某个定时、某个设备上下线。动作可以是：发告警到通知中心、给设备下发控制指令、把数据转发到别的 Topic 或数据库。一条规则就是「X 发生 → 满足 Y → 执行 Z」。

// 伪代码：一条温度超限规则
when 设备.temperature > 60
for 持续 5 秒
do 告警(高温) 且 下发指令(降温)

数据流转与过滤

不是所有数据都要进规则。先按设备分组、按指标过滤，只把有用的流进引擎。还要做去抖和静默：同一告警别每秒刷一次，持续超时才报、恢复后才消。

告警与通知联动

告警要分级：提示、重要、紧急。不同级别走不同通道——低级别进后台，高级别发短信或推到值班人。联动要能闭环：告警触发自动派单，处理完自动恢复设备状态。

低代码编排的边界

低代码解决常见、重复的逻辑。但复杂的计算、AI 判断、跨系统编排，还是要回到代码。合理分工：80% 标准场景用低代码，20% 复杂逻辑用函数或服务扩展。别迷信低代码能包打天下。

落地清单
  • 去抖静默防告警刷屏。
  • 分级通道按级别选通知方式。
  • 边界清楚复杂逻辑交代码。
  • 可回滚规则改动能回退。