前言：一个完整的 BMRS系统(业务规则管理系统)一般至少包括规则设计器、规则引擎和规则存储管理三部分组成！

一、drools常见术语

Q1：什么是事实？

我就按照我的理解来说吧。我们可以把它看成数据对象，User对象、Student对象……凡是需要拿到规则里面去匹配处理的数据对象，都叫事实。

Q2：什么是规则文件，什么又是kjar？

规则就是对扔过来的数据对象(事实)，进行模式匹配、加工处理的实体。如 User.java：

public class User{
  private int age;
  //是否成年
  private boolean isAdult; 
  //Setter、Getter忽略
}

UserHandle.drl：

import xx.User;
rule "handleUser01" 
  when
    $user: User(age > 18)
  then
    $student.setIsAdult(true);
end

when部分(也叫LHS，即规则条件)即进行模式匹配，then部分(也叫RHS，即后续处理部分)。

相关语法可以参见：drools入门之LHS和RHS语法

由上也可以看到：

• 规则简单的话，可能就只是这么一个drl规则文件+一个Java Bean；
• 规则复杂的话，可能就是一个Maven形式的规则项目。由于drl支持书写Java代码，所以规则项目还可以任意丰富：写更多的Java类，甚至引入三方依赖包！。

由于规则项目是一个maven项目，所以想要使用这个 “规则”，就需要将这个项目打成一个jar，这个jar就叫做kjar，它是由maven-kjar-plugin插件来进行打包的，相比我们普通的jar而言，它的package：

<package>kjarpackage>

同时它的Resource中，还包含kmodule.xml等配置文件，这些是Kie-Server解析时需要用到的关键文件！

Q3：drools由哪些部分组成？

drools的全家桶包括：WorkBench(规则设计器+规则存储管理) + Kie-Server(规则引擎容器)+规则引擎core(drools核心)+规则(可以是规则文件，也可以是kjar)！

Q4：什么是workbench(以下简称WB)？

实际上，就7.44版本(2020较新版本)来看，我们可以把WB理解为一个gitlab！

1. 可快速创建规则项目，该项目即托管在WB内置的GIT仓库中；
2. 可看到规则项目的目录结构，以及修改任意文件夹中的一个文件；
3. 可看到每个规则项目的提交者有哪些，以及最近提交统计图；
4. 可看到每个规则项目的GIT远程克隆地址(支持GIT、SSH和HTTP方式将项目拉到本地)；
5. 可看到每个规则项目的可视化依赖列表(类似可视化的pom.xml)，同时支持将个别依赖加入到白名单(加白名单这个后续会讲到是干嘛的)；
6. 可设置规则项目的远程Maven仓库和本地仓库(类似操纵pom.xml的)；
7. 可点击build或build&install，将规则项目打包/安装到本地maven仓库(看作gitlab集成了Jenkins)；
8. 可点击depooy将打好的包，扔到Kie-Server上面生成规则服务；

并且它具备Maven私服作用：

1. 在build或build&install执行后，kjar是安装到了本地的maven仓库，同时又会通过Maven私服将其通过HTTP暴露出来；
2. ……

同时它又具备设计器的作用：

1. 支持决策表、决策树、评分卡、规则流的创建、在线编辑(后续会讲到这些术语)；
2. 支持创建测试场景，对写好的规则项目，进行功能测试；
3. 支持根据规则项目的依赖，解析出所有事实对象，在书写规则时，方便导入；
4. ……

最后，它还具备Kie-Server的监控能力(不重点讲)：

1. 可以监控Kie-Server中规则和规则流等执行情况；
2. ……

Q5：什么是Kie-Server？

Kie-Server就相当于tomcat、jboss等容器，所有的kjar(规则项目)都会实例化为KieContainer对象。

同时Kie-Server对外提供restful接口，接受事实对象，并将其扔给KieContainer对象进行规则处理，然后返回给调用者。

目前WB和Kie-Server是无缝集成的！

二、drools运作架构

1、嵌入式

业务系统只需引入规则引擎core部分(即drools-core等相关依赖jar)，然后手动创建规则文件即可。该模式即放弃了WB，以及Kie-Server。

• 优点：简单、便于调试
• 缺点：只取核心，轻量的同时，也失去了分离式的业务逻辑完全隔离、以及分离式的高可用、设计器等优势。

2、分离式(有WB)

上图解释：

• 本地GIT REPO：WB内部自带的GIT仓库，上面有讲到；

  访问地址：http://localhost:8080/kie-wb/rest/spaces/你的空间名；

• MAVEN REPO：WB内部自带的MAVEN仓库，上面有讲到；

  访问地址：http://localhost:8080/kie-wb/rest/maven2/包路径；

• REST API(WB)：WB提供REST接口，供开发者对WB上的规则项目进行一些常规操作(一般很少使用)；
• Controller REST API：仅用于与Kie-Server交互；
• REST API(Kie-Server)：提供统一的API接口，可以让规则调用者或WB完成KieContainer的创建，以及让规则调用者进行规则调用；

  Swagger地址：http://localhost:8080/kie-server/docs；

执行步骤：

1. WB界面创建规则工程(或本地git上传到WB的Git仓库)；
2. WB执行build&install将规则工程打包为kjar，安装到内置Maven仓库；
3. Kie-Server启动，请求WB认证通过后注册到WB，此时WB的Server页面可以看到注册成功的Kie-Server实例；
4. WB点击deploy后，会调用Kie-Server的相关Rest API，同时指定GAV(group、artifactId、version)，请求Kie-Server对指定GAV的kjar进行加载；
5. Kie-Server通过HTTP方式访问WB的Maven私服，将kjar下载下来，实例化为KieContainer，同时会生成一个KieContainerId(该ID是根据GAV生成的)；
6. 调用方根据指定KieContainerId去访问指定的规则项目；
7. WB也可设置定期扫描时间，即让Kie-Server每隔指定时间定期去WB私服上更新最新的kjar。

3、分离式(无WB)

由于WB本身是比较重的，内部包含git和maven服务，以及设计器这样一个超大工程，所以在研发环境上还可能用用，但是在线上部署时就可能需要好好考虑一番。

而以上这是单独使用Kie-Server的部署模式，官方实际上是没有这种模式的。

该模式可能解决以下问题：

• 规则运行环境封闭，且需对外部屏蔽规则设计细节；
• 线上资源有限，需轻量化部署 WB的CPU和内存占用是Kie-Server的N倍，我这边实测7.44版本，wildfly部署启动WB至少需要花10分钟+；
• 线上是纯Linux环境，WB部署了也没法使用；
• ……

以上便是drools的一些常见术语和基本运作架构介绍，后续还会讲到drools的部署使用爬坑、内部的KieService、KieBase、KieSession对象，以及决策表、决策树、决策卡等。

如果喜欢本文，请关注公众号：开猿笔记，里面会有持续更新噢！