参考：【Drools】规则引擎Drools（一）——简介+springboot结合Drools规则引擎Demo

一、介绍

现实生活中，规则无处不在。法律、法规和各种制度均是；对于企业级应用来说，在IT技术领域，很多地方也应用了规则，比如路由表，防火墙策略，乃至角色权限控制(RBAC)，或者Web框架中的URL匹配。不管是那种规则，都规定了一组确定的条件和此条件所产生的结果。

举一个例子：

IF

• 汽车是红色
• 车是运动型的
• 驾驶员是男性
• 驾驶员在16-25岁之间

THEN

• 保险费用增加20%

从这个例子可以看出：

1. 每条规则都是一组条件决定的一系列结果
2. 一条规则可能与其他规则共同决定最终结果。比如例子中的规则只产生了增量，还需要与确定基数的规则共同作用才能决定最终的费率
3. 可能存在条件互相交叉的规则，此时有必要规定规则的优先级

规则作为一种知识，其典型运用就是通过实际情况，根据给定的一组规则，得出结论。这个结论可能是某种静态的结果，也可能是需要进行的一组操作。这种规则的运用过程叫做推理。如果由程序来处理推理过程，那么这个程序就叫做推理机/推理引擎。推理引擎根据知识表示的不同采取的控制策略也是不同的，常见的类型包括基于神经网络、基于案例和基于规则的推理机。其中，基于规则的推理机易于理解、易于获取、易于管理，被广泛采用。这种推理引擎被称为“规则引擎”。

规则引擎起源于基于规则的专家系统(专家系统CLIPS：源于1984年NASA的人工智能项目，现已开源，由C编写。)，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。基于规则的专家系统（RBES）包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示：

     在复杂多变的业务场景中，单靠我们日常处理判断的能力是不够的，规则变化快，不可
控因素多，业务场景复杂，都会加快开发人员处理规则的难度，减缓项目上线的难度，
同时让业务人员对开发人员更加的敌视。

      规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。

     利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。

      在需求里面我们往往把约束，完整性，校验，分支流等都可以算到业务规则里面。在规则引擎里面谈的业务规则重点是谈当满足什么样的条件的时候，需要执行什么样的操作。因此一个完整的业务规则包括了条件和触发操作两部分内容。而引擎是事物内部的重要的运行机制，规则引擎即重点是解决规则如何描述，如何执行，如何监控等一系列问题。

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

        java开源的规则引擎有：Drools、Easy Rules、Mandarax、IBM ILOG。使用最为广泛并且开源的是Drools。

其它特点： 

1. 规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。
2. 规则引擎具体执行可以分为接受数据输入，解释业务规则，根据业务规则做出业务决策几个过程。
3. 使用规则引擎可以把复杂、冗余的业务规则同整个支撑系统分离开，做到架构的可复用移植。
4. 规则引擎通常允许您在不重新启动系统或部署新的可执行代码的情况下更改规则。规则引擎不是一个新的东西的魔法盒，它旨在成为一个提供更高级别抽象的工具，以便您可以更少地关注开发细节。 

二、规则引擎的优缺点分析

1. 规则的变更非常方便，从而实现业务规则的随需应便。
2. 业务规则与系统代码分离，实现业务规则的集中管理。
3. 在不重启服务的情况下可随时对业务规则进行扩展和维护。
4. 可以动态修改业务规则，从而快速响应需求变更，大大提高了对复杂逻辑代码的可维护性。
5. 规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则。
6. 减少了硬编码业务规则的成本和风险。
7. 使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得简单。

其它优点： 

• 声明式编程
  规则可以很容易地解决困难的问题，并得到解决方案的验证。与代码不同，规则以较不复杂的语言编写; 业务分析师可以轻松阅读和验证一套规则。
• 逻辑和数据分离
  数据位于“域对象”中，业务逻辑位于“规则”中。根据项目的种类，这种分离是非常有利的。
• 速度和可扩展性
  写入Drools的Rete OO算法已经是一个成熟的算法。在Drools的帮助下，您的应用程序变得非常可扩展。如果频繁更改请求，可以添加新规则，而无需修改现有规则。
• 知识集中化
  通过使用规则，您创建一个可执行的知识库（知识库）。这是商业政策的一个真理点。理想情况下，规则是可读的，它们也可以用作文档。

规则引擎的优点和缺点：

三、规则引擎功能结构

推理引擎（Inference Engine）包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。

1. 模式匹配器决定选择执行哪个规则，何时执行规则；
2. 议程管理模式匹配器挑选出来的规则的执行次序；
3. 执行引擎负责执行规则和其他动作。

和人类的思维相对应，规则引擎中也存在两种推理方式：正向推理（Forward-Chaining）和反向推理（Backward-Chaining）。

• 正向推理也叫演绎法，由事实驱动，从 一个初始的事实出发，不断地应用规则得出结论。首先在候选队列中选择一条规则作为启用规则进行推理，记录其结论作为下一步推理时的证据。如此重复这个过程，直到再无可用规则可被选用或者求得了所要求的解为止。
• 反向推理也叫归纳法，由目标驱动，首先提出某个假设，然后寻找支持该假设的证据，若所需的证据都能找到，说明原假设是正确的；若无论如何都找不到所需要的证据，则说明原假设不成立，此时需要另做新的假设。

将事实与规则进行匹配的算法。常见的模式匹配算法有RETE,LFA,TREAI,LEAPS。Rete算法是目前效率最高的一个演绎法推理算法，许多规则引擎都是基于Rete算法来进行推理计算的。

推理引擎的推理步骤如下：模式匹配、冲突消解、执行引擎。

1. 将初始数据（fact）输入 Working Memory 。
   使用 Pattern Matcher 比较规则库（rule base）中的规则（rule）和数据（fact）。
2. 如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。
3. 解决冲突，将激活的规则按顺序放入Agenda。
4. 使用执行引擎执行Agenda中的规则。重复步骤2至3，直到执行完毕所有Agenda中的规则。

规则引擎的作用：

• 规则外部化，即有利于规则知识的复用，也可避免改变规则时带来的代码变更问题
• 由规则引擎使用某种算法进行推理过程，不需要编写复杂晦涩的逻辑判断代码
• 开发人员的不需要过多关注逻辑判断，可以专注于逻辑处理

四、规则引擎的功能 

• 规则配置-可视化
• 脚本语言编写规则
• 规则优先级执行
• 可视化规则流
• 版本发布，回滚
• 灰度发布
• 评分卡
• 决策表
• 决策树
• 黑白灰名单
• 标签管理
• 可视化决策流编辑
• 规则监控
• 用户权限管理
• AB测试
• 冠军挑战
• 规则效果分析
• 本地化(和业务系统在一个进程中)和服务化(单独部署)

五、应用场景

对于一些存在比较复杂得业务规则并且业务规则会频繁变动的系统比较适合使用规则引擎。

• 风险控制系统----风险贷款、风险评估
• 反欺诈项目----银行贷款、征信验证
• 决策平台系统----财务计算
• 促销平台系统----满减、打折、加价购 等等
• 典型场景-信用卡授信
• 风控模型配置，风控规则的设置。
• 用户积分等配置，如日常操作引起积分变化等。
• 简单的离线计算，各类数据量比较小的统计等。

5.1、风控场景  

       风控系统的简单来说就是告诉业务系统这个动作这个人有没有风险，输入有很多：当前用户的设备信息、当前cookie信息、过往操作记录、接入渠道、四项信息 都是有的，然后过程中经过一些列的规则判断，得出风险的结论或者风险的等级，用于业务系统判断该动作是否可以发生或者以什么样的等级进行。

      首先风控系统对接的业务会非常多，信贷、营销、下单等，这些业务还需要区分具体产品线，每个业务还会有不同的动作场景，整体来看动作场景的量级已经非常庞大了。对于一个动作场景而言：一系列输入数据还需要经过n层规则匹配和算法过滤出一些中间态因子数据，这些因子再作为规则输入产生结果。很显然整个风控判断规则的数量是非常非常庞大的，这时候规则引擎的存在就非常有必要了，风控系统对于规则场景的诉求也几乎是最强的。

5.2、资金决策场景

在信贷、理财、支付场景会存在一个资金流转的问题，一笔资金并不是像我们所想象的，是一个点到另一个点这样的简单，往往中间会因为合规、收益等n多问题发生资金的流转决策，每一笔交易的过程可能对于业务上：出资账户、中间户是不同的，技术上：经过的系统也是不同的，这就需要我们根据不同的场景来决定这笔钱该怎么走，这就需要各种各样的规则来完成这些流转的控制。

5.3、多场景

当我们的系统面临那些易变复杂逻辑的时候，当靠硬编系统代码开始吃力时，就需要引入规则引擎来解决问题了。

5.4、数据打标场景

现在都是数据为营的时代，如果想把这些数据高效的利用起来，肯定就要对这些数据进行清洗、打标、加工，才能产生对应的价值。而清洗、打标的过程实际上就是数据过滤规则产生结果的过程。

六、规则引擎的分类实现

1.事中规则实现

规则配置，规则配置系统，主要是对一些表达式进行封装。然后将表达式交给规则解析程序/库
规则下发，规则建立好了之后实现规则下发，规则下发的方案有很多，可以根据自己系统要求进行实现，比如：

1. 数据库+缓存；
2. 缓存；
3. Mq订阅；
4. Zookeeper的Watcher；

规则执行

规则引擎关注的是时延，不能进行跨进程调用问题，尽量不访问数据库和外部内存，直接使用机器内存规则较多，尽量使用并行执行，不如有依赖，可以分析依赖树，然后并行执行。

2.事后规则实现

主要通过大数据技术栈对多数据源数据在Hive中进行聚合，对于执行实现可以接收一定的延迟，或者采用流式处理降低时延, 对于一些时间窗口的处理，使用flink进行聚合

3.规则引擎的使用注意： 

规则引擎作为一个单独模块，有其自身的笨重与复杂，并不是所有相关业务系统都需要引入规则引擎。
        1、必须建立一些数据模型。
        2、考虑规则的冲突、优先级等。
        3、控制规则的复杂度，以免给规则配置人员增加过多的学习成本。
由此可见，对于一些时间周期短、规则复杂且不常变更的项目，规则引擎并不十分适用。