【drools系列】2、drools架构介绍

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

一、drools术语

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

规则就是对扔过来的数据对象（事实），进行模式匹配、加工处理的实体。如 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，即后续处理部分）。

由上也可以看到：

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

<package>kjar</package>

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

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

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

并且它具备Maven私服作用：

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

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

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

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

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

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

上图解释：

本地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；

执行步骤：

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