规则引擎浅谈

137 阅读2分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第4天

摘要

本期主要以规则引擎业务实现为例,陈述在陌生业务前如何进行业务深入、调研、技术选型、设计及实现全过程分析,如果你对规则引擎不感冒、也可以从中了解一些抽象实现过程。

诉求

从硬件采集到的数据提供的形式多种多样,会有库直连,MQtt传输,其他设备网关传输,接口API传输等多种形式,且传输的数据结构不具备通用性,即数据运行时为变化状态,进行的操作包含数据预处理、逻辑判断、预警、保存等诉求,扩展诉求包含函数、异常处理、完成监控、任务调度等

业务深入

这个过程主要结合需求和现状进行分析

需求主要指当下最紧要需要解决的问题及后续可能存在的扩展进行初步的评估,界定清楚需求主干及优先级,包括时间要求等 现状主要指当前人员支持情况及配置人员技术掌握情况进行分析,便于结合人员及技术情况作为评判依据,有效的组合人员的“刀尖”共力去完成任务 业务深入,如果这项工作之前没有相关的设计开发经验,通过常规的沟通很容易对当前业务的复杂度及逻辑产生误判,闭门造车、想当然等虚假结果导向,因此业务深入,不仅仅指的是理解业务,还需要多找一找相关处理的开源项目或是理论,充分的理顺要点及过程后,相关的设计及开发才不会偏离太远。

规则引擎用例

在保存到数据库之前对接收的遥测数据或属性进行验证和修改。 将遥测或属性从设备复制到相关资产以便可以汇总遥测。例如:可以将多个设备中的数据汇总到相关资产中。 根据定义的条件对报警进行创建、更新、清除。 根据设备生命周期事件触发操作。例如:如果设备处于在线/离线状态,则创建警告。 加载所需的其他处理数据。例如:在客户设备或租户属性中定义的设备的playload温度阈值。 调用外部系统的REST API。 发生复杂事件时发送电子邮件并使用“电子邮件模板”中其他实体的属性。 在事件处理期间要考虑用户的偏好。 根据定义的条件进行RPC调用。 集成第三方消息队列等。