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

一、drools术语

Q1：什么是事实？

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

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

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

1
2
3
4
5
6
public class User{
	private int age;
	//是否成年
	private boolean isAdult; 
	//Setter、Getter忽略
}

UserHandle.drl：

1
2
3
4
5
6
7
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：

1
<package>kjar</package>

同时它的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的<repository>）；
  7. 可点击build或build&install，将规则项目打包/安装到本地maven仓库（看作gitlab集成了Jenkins）；
  8. 可点击depooy将打好的包，扔到Kie-Server上面生成规则服务；

并且它具备Maven私服作用：

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

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

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

最后，它还具备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等概念，以及决策表、决策树、决策卡等。

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

在这里插入图片描述
在这里插入图片描述