业务背景

之前的文章介绍过，边缘部署的时候，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)整个流程为动态加载，不需要重启。