Drools基本了解

谈谈对业务规则管理系统的了解 举例说明

规则引擎系统是一个规则管理系统，接受数据输入、解释业务规则、根据业务规则做出业务决策的一个系统，其适用场景有贷款风险评估、积分优惠系统、保险理赔系统。规则是由“条件+动作”组成，对应代码中的when-then。

• 例如在贷款风险评估系统，系统后台中业务人员通过图形化界面预设好客户信用评级良好且无历史违约记录则允许申请贷款（这是一个规则），之后根据其收入情况设置其有能力偿还的最高限额（这又是一个规则）。其中信用评级良好、无历史违约记录、收入情况都是条件，允许申请贷款、贷款最高限额是在满足条件的情况下执行的动作。用户在申请贷款时，输入其个人情况（在规则引擎系统中称为条件）与规则库中的条件做匹配，匹配后产生相应的动作判定，用户就能知道自己能否申请贷款和贷款最高限额。
• 例如在积分优惠系统中，业务人员在系统后台中设置当积分达到800分后（条件）购买的商品打九折（动作），当积分达到1000分后（条件）购买的商品打八折（动作）。以上是场景中的两条规则，积分达到800分、达到1000分两个条件对应的动作分别是打九折打八折。用户在付款时，其积分情况（条件）会被输入到规则管理系统中，与规则库中的规则进行匹配，如果某条规则所有的条件都得到满足，那么相应的动作就会执行，用户界面会有相应的打折判定返回。
• 例如在保险理赔系统中，业务人员在后台预设了伤病情况、历史住院行为、年龄、报销比例等条件 确定理赔金额（动作），业务人员添加条件并设置对应的动作，形成了一条保险理赔规则。用户在使用APP进行理赔申请时，输入的条件与规则引擎系统中规则进行匹配，当某条规则的所有条件都得到满足，那么规则的动作就会被执行，用户就能看到相应的理赔额度。

Drools相比于if-else编写的程序有哪些优点

高效：

1. 优先级顺序的树形（网络）结构：Drools的规则机制是有优先级的树形结构（通过Rete网络高效地匹配和触发规则，这个网络是一个有向无环图），这里的优先级是指将条件出现频次高距离近的条件排在前面，出现频次高的首先被执行。
2. 缓存机制：当条件触发了动作后，该动作会被缓存起来，当有相同的条件再次执行时，直接从缓存机制中找到要触发的动作，而不用去内存中查找。
3. 多线程 ：Drools支持多线程环境，可以并行处理多个规则互相不影响，加快了规则的处理速度。

易维护：Drools通过drl文件来定义业务规则，这些规则与应用程序的代码分离，当业务逻辑变更时不需要修改应用程序代码，只调整drl文件;而普通的if-else逻辑结构是写在java文件，按类和对象高内聚模块化管理代码，散落在多个文件中，当业务调整后需要调整代码时，要在多个文件中修改，所以drools更易于维护。

Drools的格式

package:位于文件的顶部，唯一标识文件的名称空间；

import:导入需要使用的类的包或类；

function：函数定义；Query:根据规则名称查找符合条件的结果对象；Declare:声明一个类

global：定义全局变量；

rule：定义此规则的唯一标识，when、then、end出现在其范围内

when：条件判定

then：满足条件时触发的动作，包括增删改

end：规则执行结束标识符

一个规则的大致机构如下：

no-loop: no-loop为true防止死循环，当规则被再次激活时，从而导致死循环。

agenda-group:对规则分组，这些组在议程中独立存在，只有当对应的组被赋予焦点（Focus）时，该组中的规则才有可能被执行。

lock-on-active:lock-on-active为true时控制当前的规则只会被执行一次。

Drools的执行流程(原理)

文件一经启动加载为规则树，存入到内存中，规则树与事实相匹配，继而执行相应的动作

1.创建规则文件.drl，定义规则的名称、属性、条件和动作；

2.创建知识库KieBase，加载规则文件.drl并编译为字节码；

3.创建会话KieSession，从知识库KieBase中获取会话对象

4.插入事实，将业务数据插入到工作内存Working Memory中

5.执行规则，在.drl文件中触发推理机制根据事实和规则进行匹配和执行

6.处理结果，获取规则执行的结果并进行相应的处理

项目

项目提出的背景（Drools存在的问题）

业务与技术耦合：项目的目标用户是上层系统的业务人员，业务逻辑的变更时需要修改配置文件，但是业务人员不懂代码（如应该在哪个文件的什么地方修改代码，代码中的rule when then又是什么意思），就需要懂代码的技术人员来修改配置文件。对于业务人员难以独立完成规则文件的配置实现数据处理，需要技术人员介入。

维护性差：业务与技术耦合让不同专业的人员来操作，维护操作也需要技术人员参与。

难使用，出错率高：业务人员无法独立使用产品；类比java文件是按类、对象存储的，一个规则完整逻辑形式和语法配置写在一个drl文件，可读性差，代码分层可视化阅读程度不高；并且规则文件没有语法检查机制，规则配置极易出错。

无法热部署、实时性差：规则文件内置在系统中，需要提前配置好，系统系统的时候会加载该规则文件，但是一旦规则文件更改就需要重新启动服务，新配置的内容才能生效,无法更改完就能生效。

没有规则提示：复杂规则引擎系统有非常多的规则配置，规则的条件满足后会触发相应的动作，然而规则配置多，业务人员极有可能不知道是什么原因触发了动作，难以对规则进行分析与统计。

解决耦合性与难使用的问题？

提供可视化页面给业务人员，提供规则库、决策集、决策表、决策树、评分卡、决策流编辑页面，业务人员根据文字提示录入规则条件和动作，不用考虑业务逻辑内部实现原理。

业务人员输入的中文内容如何映射到drl文件？

技术人员添加变量库，在变量库中实现中文字段与drl文件中变量映射，变量库会加载到业务人员编辑规则的页面，业务人员就能看到中文的字段，但实际传给服务端的是被映射后的名称（购买数量映射为purchaseNum）。

业务员在图形化界面添加规则条件经历哪些过程关联到代码中

先由技术人员在变量库中完成规则字段的映射，并在drl文件中按照业务逻辑编写规则；接着业务员在图形化界面用技术人员映射好的属性名称添加条件，管理规则，添加好的规则会在数据库中形成一个个表；项目启动后动态拼接从数据库中获得这些规则，并根据事实来评估规则条件是否满足，从而触发相应的动作。

项目执行流程

项目启动后，前端输入的规则经后台服务器传递到数据库中，先加载缓存机制（如果缓存中存在则直接使用，否则从数据库中加载并更新缓存），之后从数据库中捞出包、条件、动作等信息，程序加载（import）执行时依赖包，之后将包、条件、动作等信息按照drools语法构建drl文件，将drl文加载到Drools的KieBase中，当有事实触发时，Drools引擎基于规则进行决策。

项目启动->数据传递与存储->缓存机制->加载条件和动作->构建drools规则文件->执行规则