CN110297620A - 一种基于Drools的动态规则维护和生成的方法 - Google Patents

Abstract

本发明公开了一种基于Drools的动态规则维护和生成的方法，所述方法包括：利用关系型数据库的二维表单对业务规则进行管理，将每一类的Drools的规则文件转换成一张张的二维表；调用统一的的规则生成引擎，把二维表翻译成Drools的规则文件，并存储到Redis缓存中；通过MQ异步消息实时通知规则消费方并发送规则变更的消息；规则消费方监听到规则变更的消息后，从Redis缓存中获取最新的规则文件，并对规则文件进行解析、编译成对应的JAVA CLASS文件，通过加载使得最新的规则生效。本发明解决了现有的web引擎的处理规则维护不便、生成效率不高的问题。

Description

一种基于Drools的动态规则维护和生成的方法

技术领域

本发明属于Web技术领域，涉及对业务支撑型系统的开发，具体涉及一种 基于Drools的动态规则维护和生成的方法。

技术背景

在业务支撑型系统的开发过程中，系统一旦上线，架构上大的调整几乎 微乎其微，变化最多的却是系统的业务规则。系统如何能有效地实现业务规 则和整体架构的解耦，是开发过程中经常要去考虑和解决的一个问题。

规则引擎通常是一个比较理想的解决方案，我们把复杂的、多变的业务 规则单独独立出来，使其与整体的应用架构分离，通过在应用中对其进行模 块化的移植引用，进而达到即具较高的灵活性又能快速地响应业务需求。

Drools是JBoss推出的一款基于Java语言的规则引擎框架，其大致工作 原理是：基于DRL等规则配置文件，通过规则解析器，把规则文件编译成Java 的Class代码，在程序运行的时候，虚拟机加载这些规则对应的Class文件并 运行，依据工作内存空间的规则和事实是否匹配来判断规则是否应该执行。

Drools是一款成熟的规则引擎框架，但是也存在一定的改进和优化空间， 例如DRL语法的独特性，其语法与大家普遍熟悉的面向对象、SQL均不同， 开发过程中如果需要采用Drools，研发人员需要一定的学习成本去掌握这些 语法；Drools的规则基于文件管理，动态维护尤其是在运行时的动态维护较 为困难，同时这些DRL语法的规则文件，可读性也不高，业务人员与研发人 员较难在规则文件的理解上达成一致。

发明内容

基于现有技术的上述缺陷，本发明的目的是提供一种基于Drools的动态 规则维护和生成的方法，以解决现有的web引擎的处理规则维护不便、生成 效率不高的问题。

为解决上述技术问题，本发明提供了一种基于Drools的动态规则维护和 生成的方法，该方法包括：

1、利用关系型数据库的二维表单对业务规则进行管理，将每一类的 Drools的规则文件转换成一张张的二维表，系统提供UI界面以允 许用户线上对业务规则进行管理和维护；

2、对Drools的DRL语法按照面向对象的方式做了高度的提炼和抽象， 把整个规则文件抽象为一系列的规则类，这些类包含：Drools规 则文件类(DroolsInfo.java)、Drools规则类(DroolsRuleInfo.java)、 Drools规则IF判断类(DroolsRuleWhenInfo.java)、Drools规则 IF判断事实属性匹配类(DroolsRuleFieldOperates.java)；

3、通过对二维表的解析，生成DroolsInfo对象，即得到我们需要的 Drools规则文件；

4、把生成的Drools规则文件存储到Redis中；

5、发送规则更新消息到MQ消息队列；

6、通过MQ的监听，实时触发应用从Redis中获取最新的Drools规 则文件；

7、利用Zookeeper的监听模式处理分布式应用间的规则文件同步，实 现集群间的规则一致性，完成分布式环境下的动态规则引擎解决 方案。

与现有技术相比，本发明所公开的一种基于Drools的动态规则维护和生 成的方法，具有如下技术效果：

(1)本发明对Drools的DRL语法做了高度的提炼和抽象，使其原有语法 的复杂性变得透明，研发人员可以继续沿用熟悉的JAVA面向对象编程方式来 生成规则文件，使得规则文件的生成变得即高效又易于理解。当业务规则需 要调整，可以在线上随时修改，规则便可以实时生效，不需要定时去刷新或 系统发布、重启，能应对各种紧急突发情况。

(2)本发明利用关系型数据库的二维表来管理业务规则，规则信息存储 在数据库的表中，方便业务人员与研发人员对规则的统一理解与认识；通过 把DRL规则元素的抽象提取为JAVA类，大大地提升了开发效率，测试调试 也得到有效的提高；规则维护如同普通的表单维护一般简单，提高了规则的 理解度，降低了规则的维护复杂度。

(3)本发明通过MQ异步消息实时通知规则消费方，告知规则已有更新， 规则消费方监听到更新消息之后，便可以立即从Redis中获取最新的规则文件。 利用MQ异步消息机制，一方面进一步降低了规则引擎与规则消费方之间的 系统耦合性，同时也达到了规则的实时更新与生效。

(4)本发明利用Zookeeper的监听模式处理分布式应用间的规则文件同 步，实现集群间的规则一致性，完成分布式环境下的动态规则引擎解决方案。

附图说明

图1为采用本发明实施例所述的一种基于Drools的动态规则维护和生成 的方法的流程图。

图2为本发明实施例所述的一种基于Drools的动态规则维护和生成的方 法的架构图。

图3是本发明实施例中的规则维护界面示意图。

图4是本发明实施例中添加一条规则后的界面示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具 体实施方式对本发明作进一步详细描述。

参照图1所示，本发明实施例公开了一种基于Drools的动态规则维护和 生成的方法，该方法包括如下步骤：

S11、利用关系型数据库的二维表单对业务规则进行管理，将每一类的 Drools(JBoss Rules)的规则文件转换成一张张的二维表；

首先，Drools的DRL语法，对于很多人来讲是不熟悉的，具有一定的学 习成本，并且其语法与大家普遍熟悉的面向对象、SQL都不一样，上手不容 易。针对DRL语法的独特性，本发明事先对Drools的DRL语法做了高度的 提炼和抽象，把整个规则文件抽象为一系列的规则类，在类中提供符合规则 语法的方法，这样处理之后，使Drools原有DRL语法的复杂性变得透明，通 过把DRL规则元素的抽象提取为JAVA类，研发人员可以不用关注DRL的语 法，而继续沿用熟悉的JAVA面向对象的方式来生成规则文件，使得规则文件 的生成变得高效与易于理解。

本发明按照面向对象的方式，把Drools的DRL规则抽象为：Drools规则 文件类(DroolsInfo.java)、Drools规则类(DroolsRuleInfo.java)、Drools规则 IF判断类(DroolsRuleWhenInfo.java)、Drools规则IF判断事实属性匹配类(DroolsRuleFieldOperates.java)。整个Drools规则文件的生成过程其实就演变 为一张张二维表的解析加上DroolsInfo对象的拼接。

在类中提供符合规则语法的方法，这样处理之后，使Drools原有DRL语 法的复杂性变得透明，研发人员可以不用关注DRL的语法，而继续沿用熟悉 的JAVA面向对象的方式来生成规则文件，使得规则文件的生成变得高效与易 于理解。

其次，Drools的规则文件，无论是采用XML方式，还是DRL文件方式， 其本质都是一个文件，不管是可读性，还是可维护性，都是较低的。本发明 中，首先利用数据库的二维表单对业务规则进行管理，每一类规则都被抽象 为一张张二维表，而且，针对二维表形式的规则文件文件，系统提供UI界面 以允许用户线上实时对业务规则进行管理和维护，规则不再是一个个的静态 文件，而是可以动态维护的、更容易理解的二维表。当业务规则需要调整， 可以在线上随时修改，规则便可以实时生效，不需要定时去刷新或系统发布、 重启。规则的维护变得如同普通的表单维护一般简单，这种改进，不仅提高 了规则的理解度，更降低了规则的维护成本，开发人员与业务人员都能对规 则一目了然。图3为本发明实施例中的一个业务类型解析的逻辑表的一种界 面方式，在该界面上，可以进行业务规则的更改。而如未出现新增规则字段， 业务规则可以完全通过配置实现；总体统计来讲，新增业务规则的开发量能 够降低90％以上。

步骤S12：调用统一的的规则生成引擎，把二维表翻译成Drools的规则 文件，并存储到Redis(REmote DIctionary Server)缓存中；

具体来说，本发明提供了统一的规则生成引擎，只需要调用该引擎就可 以生成符合DRL语法的规则文件。与此同时，无论规则的消费方有多少，一 个规则文件在整个规则处理链路中都只会生成一次，即本发明的“一方生产， 多方消费”模式，规则文件的生成完全在规则引擎中进行处理，而不是由规 则消费方各自通过解析二维表重新去生成，规则引擎生成好规则文件之后， 统一存储到Redis缓存中，存储在Redis的规则文件，一方面可以达到规则共 享，再一方面也可以减少规则二维表的翻译，提高了规则的生成效率。以上 这些处理，从规则引擎的整体链路上来讲，不但提高了规则引擎代码的完整 性，还提升了规则整体链路的处理效率。

如图2所示，在规则维护界面，点击规则维护的请求后，保存规则文件， 然后生成规则文件，判断是否生成成功，如成功则存储规则文件同时发送规 则变更的消息。譬如现在要维护一条业务类型解析的规则：业务人员只需要 在“业务类型解析维护”界面，添加一条记录，提交即可。提交后，系统在 后台首先是把界面录入的数据保存到MySQL数据库中，然后调用“Drools 规则生成工厂类”的“业务类型解析规则生成器”生成Drools规则文件。

其中，将规则文件构建为规则类对象(buildDroolsInfo)的过程包括如下：

首先，添加规则包名称；即设定当前Drools规则文件的包名，如package com.suning.nbilling.rules.nbillingan.commonparserule.matchrule；

其次，添加import信息，即导入当前Drools规则文件中用到的对应JAVA 类，如import com.suning.nbillingos.drools.droolsutiles.facts.CommomParseRuleMatchFact；

最后，生成droolsrules规则对象，根据二维表去解析、生成droolsrules 规则对象。

其中，生成droolsRules规则对象的过程具体包括如下步骤：

添加规则名称，因为规则名称是不能重复的，此处的处理需要确认规则 名称的唯一性，譬如rule"commonparserule-OVSP29.276514080720272"，此处 的规则命名规则是：规则类型+业务类型编码+一串随机数；

设置规则权重，权重的作用主要是设置同一规则文件中规则的执行先后 顺序，如salience 10；

判断设置规则是否重复执行标记；如否，则：

处理when部分，这里是解析二维表生成DRL的IF判断部分，其中的逻 辑主要是对传入的事实进行相关的匹配判断，如 info:CommomParseRuleMatchFact((businessCode＝＝"OVSP")&&(debtId＝＝"Y")&& (statusName＝＝"45")&&(orderitemStatus＝＝"ID"))，此处的判断就是判断当前传入事 实的businessCode是否等于OVSP并且debtId是否等于Y并且statusName等 于45且orderitemStatus等于ID；

处理then部分，then部分就是当上面的when部分匹配之后，规则需要执 行的逻辑，譬如info.setRuleId("190")，此处的含义就是当上面的when匹配成 功，则把事实中的ruleId赋值为190。

最终的DroolsParsHelper的generateDroolsInfo处理代码为：

以上的处理，不仅提高了开发效率，同时对于后期的规则调试、问题定 位也是十分便利

步骤S13：通过MQ异步消息实时通知规则消费方并发送规则变更的消 息；

利用MQ异步消息机制，一方面进一步降低了规则引擎与规则消费方之 间的系统耦合性，同时也达到了规则的实时更新与生效。其中，异步方式指 消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复， 而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消 息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信 方式是由消息中间件中的消息队列及其服务机制保障的。

步骤S14：规则消费方监听到规则变更的消息后，从Redis缓存中获取最 新的规则文件，并对规则文件进行解析、编译成对应的JAVA CLASS文件， 通过加载使得最新的规则生效。Class类是在Java语言中定义一个特定类的实 现。

规则引擎在生产完规则文件之后，通过MQ异步消息实时通知规则消费 方，告知规则已经有所跟新，规则消费方监听到更新消息之后，便可以立即 从Redis中获取最新的规则文件，继而对规则文件进行解析、编译生产对应的 JAVA CLASS文件，通过加载，便可以在应用中立即生效。

此外，在分布式集群环境下，为了保持多个规则消费方之间的规则文件 一致性，本发明采用Zookeeper来解决该问题，利用Zookeeper的监听模式处 理分布式应用间的规则文件同步，实现集群间的规则一致性，完成分布式环 境下的动态规则引擎解决。

其中，Zookeeper监听规则变更的消息后判断是否为消费信息，如是，则 更新ZK节点上的信息，同时，还监听ZK节点值是否已变化，如是，则重新 初始化规则规则引擎。

以下通过一个具体的实施例来对本发明的实现过程做一个完整的说明。

第一步，在规则维护界面中，添加1条规则，如图4所示。

第二步，保存该规则之后，形成如下表所示的界面。

其中，该界面内容在数据库中的信息如下表所示：

在系统中自动生成的规则文件日志如下代码所示：

第三步，规则维护系统通过MQ实时通知规则使用方进行规则更新，系 统日志日如下所示：

然后，规则使用方开始更新最新规则文件，如下所示：

此时，规则使用方在使用规则时，执行的规则文件就是这个最新的规则。 第四步，现在，对以上规则做在线修改操作，如下表所示。

提交之后，进行保存，保存后如下表所示：

此时的数据库信息更改为如下表所示：

第五步，系统最新规则生成如下代码所示：

第六步，MQ通知的最新更新触发日志，如下所示：

2018-10-21 15:39:34公共解析规则有更新，现在开始触发Drools规则文件更新。

第七步，规则使用方获取的最新规则文件如下所示：

本发明实施例所公开的方法，具有如下技术效果：

1、快速响应业务需求，提高系统生产力：由于本方案提供易用的动态规 则维护功能，使得系统能快速响应业务规则的变化，经测试，如未出现新增 规则字段，业务规则可以完全通过配置实现；统计得到新增业务规则的开发 量降低了90％以上；

2、有效地提高了规则开发和维护的效率：规则信息存储在数据库的表中， 便于维护与查看、理解；通过把DRL规则元素的抽象提取为JAVA类，大大 地提升了开发效率，测试调试也得到有效的提高；整体上提高了研发效率；

3、高效、实时的规则生效：当业务规则需要调整，可以在线上随时修改， 规则便可以实时生效，不需要定时去刷新或系统发布、重启，能应对各种紧 急突发情况。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理 解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除， 而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内， 通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改 动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护 范围内。

Claims (9)

1.一种基于Drools的动态规则维护和生成的方法，其特征在于，所述方法包括：

利用关系型数据库的二维表单对业务规则进行管理，将每一类的Drools的规则文件转换成一张张的二维表；

调用统一的的规则生成引擎，把二维表翻译成Drools的规则文件，并存储到Redis缓存中；

通过MQ异步消息实时通知规则消费方并发送规则变更的消息；

规则消费方监听到规则变更的消息后，从Redis缓存中获取最新的规则文件，并对规则文件进行解析、编译成对应的JAVA CLASS文件，通过加载使得最新的规则生效。

2.根据权利要求1所述的基于Drools的动态规则维护和生成的方法，其特征在于，针对二维表形式的规则文件，通过UI界面形式以允许用户线上对业务规则进行管理和维护。

3.根据权利要求2所述的基于Drools的动态规则维护和生成的方法，其特征在于，利用规则生成引擎生成规则文件包括：事先对Drools的DRL语法做高度的提炼和抽象，把整个规则文件抽象为一系列的规则类。

4.根据权利要求1-3任一权利要求所述的基于Drools的动态规则维护和生成的方法，其特征在于，所述方法还包括：系统安装Zookeeper，通过Zookeeper的监听模式处理分布式应用间的规则文件同步，其中，Zookeeper监听规则变更的消息后判断是否为消费信息，如是，则更新ZK节点上的信息，同时，还监听ZK节点值是否已变化，如是，则重新初始化规则规则引擎。

5.根据权利要求3所述的基于Drools的动态规则维护和生成的方法，其特征在于，

对Drools的DRL语法按照面向对象的方式进行高度的提炼和抽象，把整个规则文件抽象为一系列的规则类，这些类包含：Drools规则文件类、Drools规则类、Drools规则IF判断类、Drools规则IF判断事实属性匹配类。

6.根据权利要求5所述的基于Drools的动态规则维护和生成的方法，其特征在于，构建规则类对象的过程包括：

添加规则包名称，设定当前Drools规则文件的包名；

添加import信息，导入当前Drools规则文件中用到的对应JAVA类；

根据二维表去解析、生成droolsrules规则对象。

7.根据权利要求6所述的基于Drools的动态规则维护和生成的方法，其特征在于，生成droolsRules规则对象的过程包括：

添加规则名称；

设置规则权重；

判断设置规则是否重复执行标记，如否则继续下述过程；

处理when部分，也即解析二维表生成DRL的IF判断部分，其中的逻辑主要是对传入的事实进行相关的匹配判断；

处理then部分，也即当上面的when部分匹配之后，规则需要执行的逻辑。

8.根据权利要求1所述的基于Drools的动态规则维护和生成的方法，其特征在于，多个规则消费方共享Redis缓存中的规则文件。

9.根据权利要求2或3所述的基于Drools的动态规则维护和生成的方法，其特征在于，通过在业务类型解析维护界面，添加一条记录，提交后，系统在后台先把界面录入的数据保存到MySQL数据库中，然后调用Drools规则生成工厂类的业务类型解析规则生成器生成Drools规则文件。