什么时候使用规则引擎drools

Posted 2023-03-26

参考技术A 规则引擎一般是一下情况使用
1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂。
2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新。
3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序开发人员参与。

使用规则引擎后有哪些好处
分离商业决策者的商业决策逻辑和应用开发者的技术决策；
能有效的提高实现复杂逻辑的代码的可维护性；
在开发期间或部署后修复代码缺陷；
应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内；
符合组织对敏捷或迭代开发过程的使用；

规则引擎产品的代表
大多数规则引擎都支持规则的次序和规则冲突检验，支持简单脚本语言的规则实现，支持通用开发语言的嵌入开发。目前业内有多个规则引擎可供使用，其中包括商业和开放源码选择。开源的代表是Drools，商业的代表是旗正规则引擎VisualRules ,iLog。本回答被提问者和网友采纳 参考技术B 钢线有没有问题。单点还是多点

使用Drools来实现规则引擎

参考技术A 之前的文章介绍过，边缘部署的时候，flink on yarn模式比较重，太耗资源。于是我们打算采用Drools对目前的规则引擎进行改造，以满足边缘侧部署的需求。业务上规则引擎主要包括如下两部分：

1、数据转发

基于Flink Table Api &SQL实现，以写SQL的方式，实现IOT平台数据的转发，支持对数据按照产品key、设备key、产品标签、设备标签来过滤。

2、场景联动

基于Flink CEP来实现。主要包括：触发条件配置、执行条件配置、执行动作配置三部分。支持IOT设备间的联动，比如：当室内温度大于30℃的时候，自动开启空调。

1、资源占用大

规则需要独立运行，至少做到租户级别的隔离。那么就需要一个租户一个job，Flink 一个job的占用内存约1G左右。无法支撑大量租户。

2、启停耗时长

尽管使用了session模式来启停job，但是整体耗时还是非常大。

3、无法动态加载

规则一旦更改，需要重启整个job。这是flink机制来决定的，flink会先在本地生成描述任务的有向无环图，然后提交给jobmanager。规则变了之后，还是需要在本地进行编译，然后提交给jobmanager。

4、组件依赖多

flink on yarn模式：需要hdfs、yarn和zookeeper。

由于存在以上的问题，所以边缘部署的时候由于资源受限，不能采用此模式。于是基于Drools来实现边缘侧的规则引擎方案应运而生。采用JAVA API方式集成Drools，能很好的解决我们的所有痛点。

1、定义统一的规则生成接口。

2、以数据转发为例，需要支持Flink SQL和Drools。提供两个不同的实现。

3、根据模板生成对应的规则信息，规则信息账户间隔离。

4、规则信息存储在MYSQL中，方便后续提供统一的规则查询服务。或者存储在分布式文件系统中。

1、规则信息按照orgId%16，均匀分配的不同节点上执行。

2、执行节点启动的时候，加载与自己节点相关规则信息。

3、直接通过JAVA API的方式集成Drools。

1)规则变更，以规则粒度通知规则调度程序。变更规则的信息发送到kafka的rule_notify。

规则信息包括：org_id、rule_id等

2)规则调度程序监听topic：rule_notify,判断此规则是否属于本节点，如果属于则通过rule_id

调用获取规则信息接口，得到规则的drl详情信息，然后本节点之前的rule删除，加载新规则。

3)整个流程为动态加载，不需要重启。