当我们在对复杂的业务进行开发时，程序本身逻辑代码和业务代码互相嵌套、错综复杂，同时维护成本高，可拓展性差。
可降低复杂业务逻辑组件复杂性、降低应用程序的维护和可扩展性成本的组件！
如下图：
规则引擎实际上就是一个推理引擎，用于匹配facts（事实，我们可以理解为输入数据）和rules（规则），以推出结论。
背景：业务规则经常变化，系统需依据业务的变化，实现快速、低成本的迭代更新。因此，为了快速、低成本的更新，我们需将逻辑代码和业务代码进行解耦：
-
研发人员（不需懂业务）开发维护程序部分，同时测试通过后，后续不会经常变化改动；
-
业务人员可直接管理这些业务规则，同时不需要研发人员的参与。
名称
开源情况
运行模式
备注
单个业务引入规则引擎核心后,规则、事实数据、规则引擎的产生与运行都在一个工程中,规则引擎无法对其他服务使用
-
优点：简单、便于调试
-
缺点：只取核心，轻量的同时，也失去了分离式的业务逻辑完全隔离、以及分离式的高可用、设计器等优势。
1.1 drools规则引擎代码示例
// 定义一个Facts类型,期望 creditScore>8时风控通过 || monthlySalary>10000时风控通过
// resources/rules目录下创建 RiskRule.drl后缀文件,编写规则作为Rules
// 测试类及输出结果
如果我们期望将规则引擎执行系统与业务服务分离,为各个服务提供规则决策的能力使决策层与业务层分离,drools全家桶中是具备这样的组件去支撑的.
解决了什么问题:
-
稳定层和变化层分离,业务侧与规则引擎分离;
-
变化层支持可视化或配置化的方式，快速进行业务规则的增删改操作，甚至支持热插拔和热更新。以减少冗长的开发和测试周期；
-
drools带有规则设计器，还可解决我们 “简式建模” 的需求。
-
能够将复杂Facts实体与规则单独打jar包进行业务决策区分.
包含哪些组件以及作用:
WorkBench(规则设计器+规则存储管理+git+maven)
-
可快速创建规则项目，该项目即托管在WB内置的GIT仓库中；
-
可看到规则项目的目录结构，以及修改任意文件夹中的一个文件；
-
可看到每个规则项目的提交者有哪些，以及最近提交统计图；
-
可看到每个规则项目的GIT远程克隆地址（支持GIT、SSH和HTTP方式将项目拉到本地）；
-
可设置规则项目的远程Maven仓库和本地仓库（类似操纵pom.xml的<repository>）；
-
可点击build或build&install，将规则项目打包/安装到本地maven仓库（看作gitlab集成了Jenkins）；
-
可点击depoy将打好的包，扔到Kie-Server上面生成规则服务；
Kie-Server(规则引擎容器) + 规则引擎core(drools核心)
-
Kie-Server就相当于tomcat、jboss等容器，负责规则加载、执行以及对外接口, 所有的kjar（规则项目）都会实例化为KieContainer对象。同时Kie-Server对外提供restful接口，接受Facts对象，并将其扔给KieContainer对象进行规则处理，然后返回给调用者。
kie server集群部署图
workBench集群架构图
想要了解更多技术文章请关注公众号“职谷智享”，关注后回复关键字【秒杀】可以领取秒杀系统学习资料