在我们的印象中,我们感觉规则引擎就是解决业务逻辑层的实现问题的。因此我们理所当然的觉得工作流中的某个节点的逻辑处理,应该可以用规则引擎来解决,斗晌散那么工作流本身的逻辑也应该可以由规则引擎来解决。另外我们也会觉得,平时项目当中的业务逻辑应该都可以用规则引擎来解决。
但是当我们在使用上述这些规则引擎,却发现很难和我们实际应用的业务逻辑层的业务逻辑实现相对应。
我们以JBoss的Drools为例,由于其规则引擎使用了匹配规则的方式来进行,因此在应用这些规则引擎时。首先需要将我们具体应用中的业务逻辑做抽象,抽象成一条条规则之后,再打包成一个规则包。一个规则包相当于一个智能块。当数据传递给这个智能块后,系统会以匹配的方式应用满足条件的逻辑处理。
当采用这种方式时,应该说逻辑更抽象了,在一个更高的层次加以抽象化的定义。但是也使得规则引擎的应用得到了很大的限制。
首先这种抽象本身需要一个复杂的分析过程,这需要有很强的分析设计能力。另外我们平时具体应用中的业务逻辑层,大量的逻辑都是对实际数据的处理,很多时候还是一个批量数据的处理,甚至有些逻辑需要的参数我们并不能定义在规则中,而是在数据库表中进行配置。因此我们常见的业务逻辑层的开发,并不能先设计出一个数据模型,然后再在此基础上抽象逻辑。
因此我们发现Drools等规则空氏引擎很难用,根本不是我们所需要的那样。
我们研究规则引擎也有一段时间了。有时候我们发现自己做的规则引擎并不是一谨核个规则引擎。因为我们和像Drools这些规则引擎有很大的差别。但我们确实解决了业务逻辑层的业务逻辑配置问题。应该说我们的更实用一些。但是我们却没法去实现JSR94标准。我们不光处理业务逻辑,还把所有业务逻辑层需要处理的 *** 作全部采用规则配置的形式,包括数据库处理逻辑等。
之前的文章介绍过,边缘部署的时候,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)整让陆亏个流程为动态加载,不需要重启。
规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业哗枝悄务决策。大多数规则引擎都支持规则的次序和规则冲突检验,支持简单脚本语言的规则实现,支持通用开发语言的嵌入开发。目前业内有多个规则引擎可供使用,其中包括商业和开放源码选择。开源的代表是Drools,商业的代表是VisualRules,iLog。
VisualRules规则引擎会根据规则包名称,取得对应规则包编译后的rsc文件。然后将rsc加载到内存中,生成规则包执行上下文。同时规则引擎将传递的参数传递到规则包执行上下文中,然后开始执行规则包。执行完毕后,再将规则包执行上下文中的数据,传回给调用规则包的应用程序。整个执行原理非常简单,因此最大限度的保证了规则运行平台的稳定乱渣以搭团及最佳的性能。
我来贷的规则引擎审核通过技术手段看你在别的 网贷 平台是否贷过、有无外债、是否有逾期记录,然后是专门的审核人员审核、通过综合评估审批、若是还款能力不够、会改你的额度,审核完成发放 贷款 。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)