规则引擎Drools在贷后催收业务中的应用

,在日常业务开发工作中我们经常会遇到一些根据业务规则做决策的场景。为了让开发人员从大量的规则代码的开发维护中释放出来，把规则的维护和生成交由业务人员，为了达到这种目的通常我们会使用规则引擎来帮助我们实现。,本篇文章主要介绍了规则引擎的概念以及Kie和Drools的关系，重点讲解了Drools中规则文件编写以及匹配算法Rete原理。文章的最后为大家展示了规则引擎在催收系统中是如何使用的，主要解决的问题等。,消费贷作为vivo钱包中的重要业务板块当出现逾期的案件需要处理时，我们会将案件统计收集后导入到催收系统中，在催收系统中定义了一系列的规则来帮助业务方根据客户的逾期程度、风险合规评估、操作成本及收益回报最大原则制定催收策略。例如“分案规则” 会根据规则将不同类型的案件分配到不同的队列，再通过队列分配给各个催收岗位和催收员，最终由催收员去进行催收。下面我会结合具体场景进行详细介绍。,1.2.1 问题的引入,案例：根据上述分案规则我们列举了如下的规则集：,代码实现：将以上规则集用代码实现,业务变化：,问题产生：,可以看出如果规则很多或者比较复杂的场景需要在代码中写很多这样if else的代码，而且不容易维护一旦新增条件或者规则有变更则需要改动很多代码。,此时我们需要引入规则引擎来帮助我们将规则从代码中分离出去，让开发人员从规则的代码逻辑中解放出来，把规则的维护和设置交由业务人员去管理。,1.2.2 什么是规则引擎,规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件， 实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。,通过接收数据输入解释业务规则，最终根据业务规则做出业务决策。常用的规则引擎有：Drools，easyRules等等。本篇我们主要来介绍Drools。,2.1.1 KIE介绍,在介绍Drools之前我们不得不提到一个概念KIE，KIE（Knowledge Is Everything）是一个综合性项目，将一些相关技术整合到一起，同时也是各个技术的核心，这里面就包含了今天要讲到的Drools。,技术组成：,,
,2.1.2 Drools介绍,Drools 的基本功能是将传入的数据或事实与规则的条件进行匹配，并确定是否以及如何执行规则。,Drools的优势：基于Java编写易于学习和掌握，可以通过决策表动态生成规则脚本对业务人员十分友好。,Drools 使用以下基本组件：,,当用户在 Drools 中添加或更新规则相关信息时，该信息会以一个或多个事实的形式插入 Drools 引擎的工作内存中。Drools 引擎将这些事实与存储在生产内存中的规则条件进行模式匹配。,当满足规则条件时，Drools 引擎会激活并在议程中注册规则，然后Drools 引擎会按照优先级进行排序并准备执行。,2.2.1 规则文件解析,DRL（Drools 规则语言）是在drl文本文件中定义的业务规则。主要包含：package，import，function，global，query，rule end等，同时Drools也支持Excel文件格式。,function,规则文件中的方法和我们平时代码中定义的方法类似，提升规则逻辑的复用。,使用案例：,query,DRL 文件中的查询是在 Drools 引擎的工作内存中搜索与 DRL 文件中的规则相关的事实。在 DRL 文件中添加查询定义，然后在应用程序代码中获取匹配结果。查询搜索一组定义的条件，不需要when或then规范。,查询名称对于 KIE 库是全局的，因此在项目中的所有其他规则查询中必须是唯一的。返回查询结果ksession.getQueryResults("name")，其中"name"是查询名称。,使用案例：,规则：,全局变量global,通过 KIE 会话配置在 Drools 引擎的工作内存中设置全局值，在 DRL 文件中的规则上方声明全局变量，然后在规则的操作 ( then) 部分中使用它。,使用案例：,规则属性,,
,模式匹配,当事实被插入到工作内存中后，规则引擎会把事实和规则库里的模式进行匹配，对于匹配成功的规则再由 Agenda 执行推理算法中规则的(then)部分。,规则的“when”部分也称为规则的左侧 (LHS)包含执行操作必须满足的条件。如果该when部分为空，则默认为true。如果规则条件有多个可以使用（and,or），默认连词是and。如银行要求贷款申请人年满21岁，那么规则的when条件是Applicant(age < 21),规则的“then”部分也称为规则的右侧（RHS）包含在满足规则的条件部分时要执行的操作。如银行要求贷款申请人年满 21 岁（Applicant( age < 21 )）。不满足则拒绝贷款setApproved(false),内置方法,Drools主要通过insert、update方法对工作内存中的fact数据进行操作，来达到控制规则引擎的目的。,操作完成之后规则引擎会重新匹配规则，原来没有匹配成功的规则在我们修改完数据之后有可能就匹配成功了。,注意：这些方法会导致重新匹配，有可能会导致死循环问题，在编写中最好设置属性no-loop或者lock-on-active属性来规避。,（1）insert：,作用：向工作内存中插入fact数据，并让相关规则重新匹配,（2）update：,作用：修改工作内存中fact数据，并让相关规则重新匹配, 比较操作符,,
,2.3.1 配置文件的引入,需要有一个配置文件告诉代码规则文件drl在哪里，在drools中这个文件就是kmodule.xml，放置到resources/META-INF目录下。,说明：kmodule是6.0 之后引入的一种新的配置和约定方法来构建 KIE 库，而不是使用之前的程序化构建器方法。,2.3.2 代码中的使用,KieServices：可以访问所有 Kie 构建和运行时的接口，通过它来获取的各种对象（例如：KieContainer）来完成规则构建、管理和执行等操作。,KieContainer：KieContainer是一个KModule的容器，提供了获取KBase的方法和创建KSession的方法。其中获取KSession的方法内部依旧通过KBase来创建KSession。,KieSession：KieSession是一个到规则引擎的对话连接，通过它就可以跟规则引擎通讯，并且发起执行规则的操作。例如：通过kSession.insert方法来将事实（Fact）插入到引擎中，也就是Working Memory中，然后通过kSession.fireAllRules方法来通知规则引擎执行规则。,说明：以上案例是使用的Kie的API（6.x之后的版本）,Rete算法由Charles Forgy博士发明，并在1978-79年的博士论文中记录。Rete算法可以分为两部分：规则编译和运行时执行。,编译算法描述了如何处理生产内存中的规则以生成有效的决策网络。在非技术术语中，决策网络用于在数据通过网络传播时对其进行过滤。,网络顶部的节点会有很多匹配，随着网络向下延伸匹配会越来越少，在网络的最底部是终端节点。,关于RETE算法官方给出的说明比较抽象，这里我们结合具体案例进行说明。,2.4.1 案例说明,假设有以下事实对象：,A(a1=1,a2="A"),A(a1=2,a2="A2"),B(b1=1,b2="B"),B(b1=1,b2="B2"),B(b1=2,b2="B3"),C(c1=1,c2="B"),现有规则：,Bete网络：,
,,
,2.4.2 节点说明,1.Root Node：根节点是所有对象进入网络的地方,2.one-input-node(单输入节点),3.two-input-node（双输入节点）,4.TerminalNode：,表示一条规则已匹配其所有条件，带有“或”条件的规则会为每个可能的逻辑分支生成子规则，因此一个规则可以有多个终端节点。,2.4.3 RETE网络构建流程,2.4.4 运行时执行,2.4.5 共享模式,以下是模式共享的案例，两个规则共享第一个模式Cheese( $cheddar : name == "cheddar" ),网络图：（左边的类型为Cheese，右边类型为Person）,,
,2.4.6 小结,rete算法本质上是通过共享规则节点和缓存匹配结果，获得性能提升。,【状态保存】：事实集合中的每次变化，其匹配后的状态都被保存到alphaMemory和betaMemory中。在下一次事实集合发生变化时（绝大多数的结果都不需要变化）通过从内存中取值，避免了大量的重复计算。,Rete算法主要是为那些事实集合变化不大的系统设计的，当每次事实集合的变化非常剧烈时，rete的状态保存算法效果并不理想。,【节点共享】：例如上面的案例不同规则之间含有相同的模式，可以共享同一个节点。,【hash索引】：每次将 AlphaNode 添加到 ObjectTypeNode 后继节点时，它都会将文字值作为键添加到 HashMap，并将 AlphaNode 作为值。当一个新实例进入 ObjectType 节点时，它不会传播到每个 AlphaNode，而是可以从HashMap 中检索正确的 AlphaNode，从而避免不必要的文字检查。,存在问题：,在Drools早期版本中使用的匹配算法是Rete，从6.x开始引入了phreak算法来解决Rete带来的问题。,关于phreak算法可以看官方介绍：,​​https://docs.drools.org/6.5.0.Final/drools-docs/html/ch05.html#PHREAK​​,文章开头问题引出的例子中可以通过编写drl规则脚本实现，每次规则的变更只需要修改drl文件即可。,产生一个新的问题：,虽然通过编写drl可以解决规则维护的问题，但是让业务人员去编写这样一套规则脚本显然是有难度的，那么在催收系统中是怎么做的呢，我们继续往下看。,3.2.1 决策表设计,催收系统自研了一套决策表的解决方案，将drl中的条件和结果语句抽象成结构化数据进行存储并在前端做了可视化页面提供给业务人员进行编辑不需要编写规则脚本。例如新增规则：,将逾期天数大于a天小于b天且逾期总金额小于等于c的案件分配到A队列中。,,表中的每一行都对应一个rule，业务人员可以根据规则情况进行修改和添加，同时也可以根据条件定义对决策表进行拓展。,,决策表的主要构成：,3.2.2 规则生成,催收系统提供了可视化页面配置来动态生成脚本的功能（业务人员根据条件定义和结果定义来编辑决策表进而制定相应规则）。,核心流程：,,1.根据规则类型解析相应的事实对象映射文件，并封装成条件实体entitys与结果实体resultDefs，文件内容如下图：,事实对象映射xml,2.根据规则类型查询规则集完整数据,3.将规则集数据与xml解析后的对象进行整合，拼装成一个drl脚本,4.将拼装好的脚本保存到数据库规则集表中,3.2.3 规则执行,核心流程：,
,,本文主要由催收系统中的一个案例引出规则引擎Drools，然后详细介绍了Drools的概念与用法以及模式匹配的原理Rete算法。最后结合催收系统给大家讲解了Drools在催收系统中是如何使用的。,通过规则引擎的引入让开发人员不再需要参与到规则的开发与维护中来，极大节约了开发成本。通过自研的催收系统可视化决策表，让业务人员可以在系统中灵活配置维护规则而不需要每次编写复杂的规则脚本，解决了业务人员的痛点。系统本质上还是执行的规则脚本，我们这里是把脚本的生成做了优化处理，先通过可视化页面录入规则以结构化的数据进行存储，再将其与规则定义进行整合拼装，最终由系统自动生成规则脚本。,当前催收系统中的规则引擎仍然存在着一些问题，例如：,后续我们会随着版本的迭代不断升级优化，感谢阅读。,参考文档：