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

3,911 阅读6分钟

前言: 一个完整的 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>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. 可点击buildbuild&install,将规则项目打包/安装到本地maven仓库(看作gitlab集成了Jenkins);
  8. 可点击depooy将打好的包,扔到Kie-Server上面生成规则服务;

并且它具备Maven私服作用:

  1. buildbuild&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对指定GAVkjar进行加载;
  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等概念,以及决策表、决策树、决策卡等。

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