「java调用drl」java调用draw方法
今天给各位分享java调用drl的知识，其中也会对java调用draw方法进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、使用Drools来实现规则引擎
- 2、drools6.5 多个drl 文件怎么的重新加载
- 3、java.lang.IllegalAccessError: tried to access method
- 4、轻量级规则引擎调研
使用Drools来实现规则引擎
之前的文章介绍过，边缘部署的时候，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)整个流程为动态加载，不需要重启。
drools6.5 多个drl 文件怎么的重新加载
drl的when 里面可以调用函数，就先在java文件里面定义函数fun1（List list1，List list2）
例如
rule "XX"
when
$.XX(xxxx,fun1(listpar1,listpar2) == 1 )
then
System.out.println("list相同");
end
rule "XX1"
when
$.XX(fun1(listpar1,listpar2) ==0 )
then
System.out.println("list不相同");
end
我最近在学，但是没什么好办法，目前只想到这个，
我同问，期待更好的回答！！
java.lang.IllegalAccessError: tried to access method
出现这个错一般是因为访问权限错误，好好看看public，protected和private修饰符
轻量级规则引擎调研
我们基于Flink实现了云端的规则引擎，以flink on yarn方式在运行，依赖hadoop和zookeeper，对于边缘侧来说比较重，所以打算调研下轻量级的规则引擎，我们的业务诉求如下：
1、轻量级
2、支持海量规则
4、便捷的规则启停
5、动态加载
从如下几方面对比目前比较流行的几个规则引擎框架：
1、社区活跃度
drools（3.7k），比较活跃的社区。三者中遥遥领先。
2、SQL支持度
不支持，通过DSL定义规则。有开发工具，生成drl文件。
3、开箱即用（支持JAVA API直接调用）
可直接maven引入依赖，开箱即用。规则需要预先加载，环境初始化比较慢2秒左右。需要自己写规则调度。
4、部署方式
可部署多个kie-server，kie-server为单机模式。
1、社区活跃度
Siddhi（1.2k）。
2、SQL支持度
与flink sql类似，流式处理。定义source、sink，支持多流join。丰富的插件：kafka、redis等。通过类SQL的语言描述事件流任务。
3、开箱即用（支持JAVA API直接调用）
可直接maven引入依赖，开箱即用。规则需要预先加载，环境初始化比较慢2秒左右。需要自己写规则调度。
4、部署方式
第一种方式：Standard Deployment ，单机部署，与drools的kie-server的部署方式类似。
第二种方式：完整的分布式部署
此部署规模已经很接近flink了，但是没有checkpoint的机制。
esper的社区活跃度真不高esper（699），所以我们直接略过。
几个主流的规则引擎其实实现机制都差不多，功能都能满足我们的业务场景，drools在sql支持方面比较弱，优势在社区活跃度。Siddhi的部署方式已经接近Flink，网上都说它比较轻量级，我是真的没看出来。最终打算采用drools，直接通过java api进行调用。自己写个简单的调度，如果上了它的执行调度模块，还不如直接使用flink，flink在这方面成熟多了，有checkpoint、status等机制。对于drools的动态加载，我会单独开一篇文章来详细说明，这个是我们的痛点，基于flink目前机制实现不了的。
关于java调用drl和java调用draw方法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。