本文侧重对官方文档的解读及扩展。同时结合自身的实践分享一些自己的见解。
请结合官方文档阅读
https://docs.jboss.org/drools/release/7.10.0.Final/drools-docs/html_single/index.html
1. 背景故事
规则引擎起源于基于规则的专家系统(专家系统CLIPS：源于1984年NASA的人工智能项目。基于规则的专家系统是专家系统的一个分支)。
基于规则的专家系统（RBES）包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine（推理引擎）。它们的结构如下系统所示：
推理引擎（Inference Engine）包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。这里不详述。
1.1. 规则引擎的作用
- 将繁杂的业务逻辑从代码中抽取出来（整合成规则文件或者规则包）。有利于规则知识的复用及维护。
- 规则文件或规则包，与程序代码相对独立。易于提供给其它项目或本项目的其它模块调用
- 能够实时响应业务规则的更新。可避免由业务规则变更带来的代码变更、程序更新操作。
- 积累下来的规则可为新规则的制定提供依据和参考。
- 能够极大地提升业务逻辑的执行效率。详见下文。
说到DROOLS不得不提到RETE算法。RETE算法是目前效率较高的一个演绎法推理算法。包含DROOLS在内的许多规则引擎都是基于RETE算法进行推理计算的。
1.2. 关于RETE算法
这个可以点：
https://www.jianshu.com/p/3e9afe9e0617
2. KIE DROOLS
Drools是一套规则管理、执行解决方案。它主要包含几个部分：一个业务规则引擎（Bussiness Rule Engine）Drools Expert ，一个规则管理网站（Drools Workbench），一个Eclipse IDE的插件（用于开发），一个执行服务器（KIE EXCUTION SERVER）。
比较有趣的是：Drools Workbench 具备KIE Excution Server 注册和发现的功能；KIE Excution Server 自带Container概念。不知是否可以让你想起 SpringBoot、docker中的相关概念。
2.1. 经典架构
在实际项目中应用Drools的方式大概可分为两种类型：
1.项目嵌入drools expert（drools-core），加载规则，执行规则。
- kie excution server 加载规则、执行规则；项目通过远程调用得到执行结果。
为便于辨识，将两种经典的架构分别命名为：嵌入模式、分离模式。
2.1.1. 嵌入模式：应用本地加载规则、执行规则。
项目引入drools-core、kie-api相关等依赖项。自行创建规则文件或规则工程。工程内部基于kie-api提供的方法加载规则、编译规则、插入事实、执行规则。
规则工程可单独创建。基于maven 进行发布管理。调用方基于k-jar的GAV信息在pom中加入依赖项实现对规则工程的引用。如调用方设置了kie-scanner可实现规则版本动态更新.
demo： https://blog.csdn.net/gongxsh00/article/details/79529924
这种结构虽然简单，却也体现了引入规则引擎的初衷。我们可以将业务规则从繁杂的逻辑代码中提取出来，沉淀下来。提高执行效率，降低维护成本。
一些变化不频繁的业务规则同样可以提取成规则文件。
2.1.2. 分离模式
kie excution server 加载规则、执行规则、扫描规则更新。应用通过远程调用得到规则执行结果。
2.1.2.1.基于kie workbench维护规则工程
下图展示了基于drools workbench维护规则工程，基于kie excution server加载、执行规则的经典架构。
- 规则工程创建及部署步骤：
- drools workbench创建规则工程（或从远程git仓库拉取规则工程）编辑并保存到本地内置的Git仓库。
- drools workbench指定project执行maven命令：compile、test、install、depLoy 等。将规则包（k-jar）发布到本地的maven仓库。
- drools workbench调用kie excution server的api通知其创建特定的container用于部署指定GAV的k-Jar。
- kie excution server从maven repo获取指定GAV的k-jar，创建container加载k-jar。
可针对container设定 kie scanner。当容器部署的k-jar（如 com.ecip.demo:1.0.0）有更新时。kie scanner 将新的k-jar拉取下来并更新对应的Container。
- kie workbench支持从远程git仓库拉取规则工程，进行编辑后保存到本地git repo
- kie excution server可从多个源加载 k-jar。不限于kie workbench内置的maven仓库。
2.1.2.2.自建后台集成 kie workbench
这种架构与2.1.2.1 展示架构相似，主要解决“workbench界面过于专业化，业务人员无发维护”的痛点。同时可以使用到kie-wb丰富的功能。但实施成本较高。
2.1.2.3.不使用kie workbench
自建后台网站集成kie excution server 的rest api。实现规则的加载、更新及服务器健康状态监控。后台网站或工程师PC负责发布规则包。
这种架构相对简单，但同样存在痛点。后台网站编辑规则、发布规则包的方式实施成本较高（相当于自行实现了workbench的部分功能）；工程师PC发布更新规则包的方式，不能实时响应业务规则变化，开发人员负担较重。
- 总结
架构无优劣之分。评判架构的唯一标准是与项目是否匹配。
自认为原生架构2.1.2.1适用的场景更多。
项目自行实现规则、模型的维护、发布等功能的成本很高。
应用规则引擎，无论采用何种技术架构，业务规则建模工作都是重中之重。
2.2 DROOLS WORKBENCH
drools workbench基于uber fire开源框架创建，是规则维护管理的后台网站。
通过drools workbench可实现对规则、模型、流程等的编辑管理工作。同时,workbench提供对kie excution server操作的界面。
drools workbench 默认基于内置的Git Repo进行规则文件/工程源码版本管理。
drools workbench 使用maven指令进行规则工程的构建。默认将打包好的k-jar发布到本地仓库。
workbench提供类似服务注册发现的接口，用于kie excution server的注册发现。
REST接口
drools workbench 提供了一套REST API。为其它应用集成drools workbench提供便利。
本章节提供接口能力的总览/概述。如有其它需求，建议阅读drools.org的原生文档。这里不详述。
REST API calls to Knowledge Store allow you to manage the Knowledge Store content and manipulate the static data in the repositories of the Knowledge Store. The calls are asynchronous, that is, they continue their execution as a job after a call was performed. The job ID is returned by every call to allow (after the REST API call was performed) to request the job status and verify whether the job finished successfully. Parameters of these calls are provided in the form of JSON entities.
When using Java code to interface with the REST API, the classes used in POST operations or otherwise returned by various operations can be found in the(org.uberfire:)uberfire-rest-clientJAR. All of the classes mentioned below can be found in theorg.guvnor.rest.clientpackage in that JAR.
基于workbench rest api 可实现对job,project(规则工程),space(类似一个文件夹，保存同一类别或者相关联的规则工程)的操作。
Embedded Kie Server Controller calls
When running the Workbench with the embedded Kie Server Controller mode, a series of endpoints related to managing all aspects of Kie Server Templates, Kie Server instances and Containers are also available. See Controller REST API for more details. A Java client API is also available for interacting with these endpoints.
controller rest api 提供了对注册到workbench的kie excution server进行操作的能力。
2.3. KIE EXCUTION SERVER
KIE EXCUTION SERVER是规则加载、执行的组件。官方介绍如下：
The KIE Execution Server is a standalone, out-of-the-box component that can be used to instantiate and execute rules via interfaces available for REST, JMS or a Java client side application. Created as a web deployable WAR file, this engine can be deployed on any web container.
This server has a low footprint, with minimal memory consumption, and therefore, can be deployed easily on a cloud instance. Each instance of this server can open and instantiate multiple Kie Containers which allows you to execute multiple rule services in parallel.
You can provision execution server instances via KIE Workbench.
2.3.1 REST API
Excution Server 的API主要提供：1. 状态监控 2. container 操作 3. 规则执行 等能力。
可通过[POST] /config（操作container、scanner） 和 [POST] /containers/instances/{id}（规则执行相关）方法在Excution Sever上执行各种各样的命令（command）。
3. 其它
3.1. Drools中的关键概念
https://www.jianshu.com/p/067e94b1ffb9
3.2. Drools Jar 包介绍：
knowledge-api.jar - 提供接口和工厂。它清楚地描述用户 API 的职责，还有什么引擎 API。
knowledge-internal-api.jar - 提供内部接口和工厂。
drools-core.jar - 核心引擎，运行时组件。包含 RETE 引擎和 LEAPS 引擎。
drools-compiler.jar - 包含编译器/构建器组件，以获取规则源，并构建可执行规则库。
drools-decisiontables.jar - 决策表编译器组件，在 drools-compiler 组件中使用。支持 Excel 和 CSV 输入格式。
