一、产生的背景
生产过程中，线上的业务规定内嵌在零碎的各处代码中，每次策略的调整都须要更新线上零碎，进行从需要 -> 设计 -> 编码 -> 测试 -> 上线这种长周期的流程，满足不了业务规定的疾速变动以及低成本的更新试错迭代。
因而须要有一种解决方案将 商业决策逻辑 和利用开发者的 技术决策 分来到，在零碎运行时能去更新治理业务规定。
规定引擎(业务规定管理系统，英文名为 BRMS（即 Business Rule Management System））正是这样的解决方案。
二、理论业务场景：
一个小例子：如果咱们有个业务场景，当客户的积分位于一个区间 A 时，咱们给予他一个头衔 a，当一个客户的积分位于区间 B 时，咱们给予他一个头衔 b，当客户的积分位于区间 C 时，咱们给予他一个 头衔 c。如果咱们应用 if-else-then 来写，是能够实现的，然而这里存在一个问题：规定定义和代码耦合在一起了。如果咱们扭转规定，把区间 A，B，C 改成 D，E，F，又或是将规定减少，从 3 组变为 100 组，那么咱们改代码切实是太麻烦了。这时候规定引擎就派上用场了，咱们心愿把 规定和代码解耦，造成一个规定引擎，以适应复杂多变的业务场景，或者更加精细化的经营。
🐵理论业务场景：
BD 绩效考核 是将各个战区每月针对 bd 制订的绩效考核计划线上化，反对绩效计划设置、bd 绩效达成状况跟踪、绩效薪资计算等性能。
现状： 绩效的考核计划和激励政策呈现出多样化、复杂化的特点，不同的战区绩效考核的指标及考核计划不同，每个战区每个月的指标及考核计划变动十分大，同一个指标每月对应的规定定义不同。
计划： 为了应答战区绩效考核计划多变，本次须要实现指标规定的灵便配置。
以无效团长数为例：
无效团长定义为： 团长每月无效团达标天数 >=15 天（无效团指的是每天成团的规范：5 个下单用户，15 件下单商品）
| 指标类型 | 指标名称 | 指标规定 | 实体 | 工夫维度 |
|---|---|---|---|---|
| 原子指标 | 团用户数 | 团成交用户数 | 团 | 日 |
| 原子指标 | 团商品数 | 团成交商品数 | 团 | 日 |
| 复合指标 | 是否无效团 | 团用户数 >= 5 且团商品数 >=15 | 团 | 日 |
| 复合指标 | 无效团天数 | 是否无效团 =1，求和 sum | 团长 | 月 |
| 复合指标 | 是否无效团长 | 无效团天数 >=15 天 | 团长 | 月 |
| 复合指标 | 无效团长数 | 是否无效团长 =1，求和 sum | 组织 / 网格 | 月 |
三、规定引擎价值及实质
3.1 规定引擎价值：
最大的价值就在于通过以下的三个过程，大大的缓解了频繁的需要变动给整个业务零碎带来的劫难。
- 逼迫零碎开发人员和业务专家梳理业务，定义对立的 BOM（业务对象模型）。
- 业务专家能够疾速的制订批改规定，而后交由规定引擎自动化地来解决剖析。
- 规定引擎代替零碎开发人员，解决由规定条件关联动作变动带来的开发工作。
总结一句话：规定引擎就是将须要内部决策的业务规定加载到零碎中，依照不同的输出条件进行不同的规定匹配组合后，执行合乎规定的一个或者多个操作。
3.2 规定引擎的实质
实质是“专家决策零碎规定引擎模型”和 rete 算法，为了解决的是大量反复的 condition 匹配效率的问题，以及规定抵触标准的问题，和脚本的性能比拟不在同一个层面上。
四、Rete 算法介绍
（1）规定内容
IF：年级是三年级以上，性别是男的，年龄小于 10 岁，身体健壮，身高 170cm 以上，THEN：这个男孩是一个篮球苗子，须要造就网络构建：
[]()
匹配过程：
（1）匹配过程中事实在网络节点中的流转程序为 A -->B-->C-->D-->E-->F-->G-->H-->I---> 规定匹配通过（2）从 working-Memory 中拿出一个待匹配的 StudentFact 对象，进入根节点而后进行匹配，以下是 fact 在各个节点中的流动图
A 节点：拿 StudentFact 的年级数值进行年级匹配，如果年级符合条件，则把该 StudentFact 的援用记录到 A 节点的 alpha 内存区中，退出年级匹配。B 节点：拿 StudentFact 的性别内容进行性别匹配，如果性别符合条件，则把该 StudentFact 的援用记录到 B 节点的 alpha 内存区中，而后找到 B 节点左援用的 Beta 节点，也就是 C 节点。C 节点：C 节点找到本人的左援用也就是 A 节点，看看 A 节点的 alpha 内存区中是否寄存了 StudentFact 的援用，如果寄存，阐明年级和性别两个条件都合乎，则在 C 节点的 Beta 内存区中寄存 StudentFact 的援用，退出性别匹配。D 节点：拿 StudentFact 的年龄数值进行年龄条件匹配，如果年龄符合条件，则把该 StudentFact 的援用记录到 D 节点的 alpha 的内存区中，而后找到 D 节点的左援用的 Beta 节点，也就是 E 节点。E 节点：E 节点找到本人的左援用也就是 C 节点，看看 C 节点的 Beta 内存区中是否寄存了 StudentFact 的援用，如果寄存，阐明年级，性别，年龄三个条件合乎，则在 E 节点的 Beta 内存区中寄存 StudentFact 的援用，退出年龄匹配。F 节点：拿 StudentFact 的身材数值进行身材条件匹配，如果身材条件合乎，则把该 StudentFact 的援用记录到 D 节点的 alpha 的内存区中，而后找到 F 节点的左援用的 Beta 节点，也就是 G 节点。G 节点：G 节点找到本人的左援用也就是 E 节点，看看 E 节点的 Beta 内存区中是否寄存了 StudentFact 的援用，如果寄存，阐明年级，性别，年龄，身材四个条件合乎，则在 G 节点的 Beta 内存区中寄存 StudentFact 的援用，退出身材匹配
H 节点：拿 StudentFact 的身高数值进行身高条件匹配，如果身高条件合乎，则把该 StudentFact 的援用记录到 H 节点的 alpha 的内存区中，而后找到 H 节点的左援用的 Beta 节点，也就是 I 节点。I 节点：I 节点找到本人的左援用也就是 G 节点，看看 G 节点的 Beta 内存区中是否寄存了 StudentFact 的援用，如果寄存了，阐明年级，性别，年龄，身材，身高五个条件都合乎，则在 I 节点的 Beta 内存区中寄存 StudentFact 援用。同时阐明该 StudentFact 对象匹配了该规定，造成一个议程，退出到抵触区，执行该条件的后果局部：该学生是一个篮球苗子。五、Rete 算法优劣势剖析
5.1 Rete 算法优于传统的模式匹配算法
a．状态保留。 Rete 算法是一种启发式算法，不同规定之间往往含有雷同的模式，因而在 beta-network 中能够共享 BetaMemory 和 betanode。如果某个 betanode 被 N 条规定共享，则算法在此节点上效率会进步 N 倍。
b. 节点共享。 Rete 算法因为采纳 AlphaMemory 和 BetaMemory 来存储事实，当事实汇合变动不大时，保留在 alpha 和 beta 节点中的状态不须要太多变动，防止了大量的反复计算，进步了匹配效率。
c. 从 Rete 网络能够看出，Rete 匹配速度与规定数目无间接关系，这是因为事实只有满足本节点才会持续向下沿网络传递。
5.2 Rete 算法的毛病
Rete 算法应用了存储区存储已计算的两头后果，以 空间换取工夫，从而放慢零碎的速度。然而存储区依据规定的条件与事实的数目成指数级增长，极其状况下会耗尽系统资源。
a. 容易变动的规定尽量置后匹配，能够缩小规定的变动带来规定库的变动。
b. 约束性较为通用或较强的模式尽量置前匹配，能够防止不必要的匹配。
六、规定引擎调研
规定引擎有三个概念须要了解，如下：
事实（Fact）： 对象之间及对象属性之间的关系
规定（rule）： 是由条件和论断形成的推理语句，个别示意为 if…Then。一个规定的 if 局部称为 LHS，then 局部称为 RHS。
模式（module）： 就是指 IF 语句的条件。这里 IF 条件可能是有几个更小的条件组成的大条件。模式就是指的不能在持续宰割上来的最小的原子条件。
[]()
依据业务人员编写的规定库和工作内存空间以后的状态，通过规定引擎匹配模式，把满足的规定放入议程表，将不满足的规定从议程表中删除。
a、将初始数据（fact）输出至工作内存(Working Memory)。b、应用 Pattern Matcher 将规定库 (Rules repository) 的规定（rule）和数据（fact）比拟。c、如果执行规定存在抵触（conflict），即同时激活了多个规定，将抵触的规定放入抵触汇合。d、解决抵触，将激活的规定按程序放入 Agenda。e、执行 Agenda 中的规定。f、反复步骤 b 至 e，直到执行结束 Agenda 中的所有规定。[]()
6.1 规定引擎的外围问题
任何一个规定引擎都须要很好地解决规定的推理机制和规定条件匹配的效率问题。
a、规定引擎将逻辑与数据拆散
b、数据在域对象中，逻辑在规定中。这从根本上突破了数据和逻辑的耦合，这可能是长处，也有可能是毛病。
然而 解耦逻辑 能够更容易保护。能够将逻辑全副组织在一个或多个十分不同的规定文件中，而不是将逻辑散布在许多 域对象或控制器 中。
6.2 内部规定引擎框架调研
Java 规定引擎次要有 URule (pro) /Drools/easyRule/
| | | 介绍 | 长处 | 毛病 | 活跃性 | 综合评估 | |
|---|---|---|---|---|---|---|---|
| 通过界面配置的成熟规定引擎： | URule | 纯 Java 规定引擎（RETE 算法）为根底规 | 则定义形式：提供了向导式规定集、脚本式规定集、决策表、穿插决策表(PRO 版提供)、决策树、评分卡决策流配合基于 WEB 的设计器，可疾速实现规定的定义、保护与公布。 | 商用软件 | 高 | 五星 | https://github.com/youseries/urule |
| Drools | 决业务代码和业务规定拆散；实用于大型利用零碎 | 性能高 可整合 可保护 | 学习老本高 | 文档全 继续更新 风行 | 五星 | https://www.drools.org/ | |
| 基于 java 代码的规定引擎 | Easy Rules | 一个比较简单的开源的规定引擎，应用简略的 Java 注解形式或者 Java 代码编程形式或者应用表达式语言或者用规定形容算子定义规定，而后应用非常简单的 Java 代码加载事实，规定，而后就能够在已知的事实上实现具体的行为了。 | 简略易用一个十分轻量级的框架定义规定的形式丰盛多样基于 POJO，反对复合规定 | Github 维护者少 | | 四星 | https://github.com/j-easy/easy-rules/releases/tag/easy-rules-4.1.0 |
| 基于 JVM 脚本语言： | Aviator | 各种表达式的动静求值 two pass 编译，最终生成 JVM 字节码保障性能比个别解释型脚本快 | 高性能；轻量级；反对多种类型 | Github 维护者少 | 材料齐，例子多 | 四星 | https://code.google.com/archive/p/aviator/downloads |
| MVEL | 应用表达式语言定义规定 | 灵便，性能高，无类型限度 | 材料少 | Github 更新少 | 三星 | | |
| | RuleEngine | 一个能够应用 SQL 脚本来定义规定的中间件，如下的地址是 github 上基于 RuleEngine 的一个 web 可视化配置我的项目。 | | | | | https://github.com/rule-engine/rule-engine/releases/tag/v1.0-beta.1 |
七、规定引擎代码演示
coding 地址： git@coding.jd.com:zhangjiangtao1/demo.git
八、规定引擎调研总结
规定引擎不是银弹，规定引擎只是把业务规定从利用程序代码中分离出来，通过配置文件独立治理，实质上就是把原来的 Java 代码转化成脚本来动静解析执行而已，还是须要写代码
解耦后尽管能够在肯定水平上反对疾速调整业务规定，然而因为为了实现通用性，防止与业务场景强关联，所以规定引擎都是以 DSL（Domain Specific Language））或独立 web 页面进行保护，对开发人员和业务人员都具备肯定的学习老本，而且调整也会比拟繁琐，很多时候即便培训了业务人员也不懂。
综上：
a、如果只谋求无需硬编码，并且配置人员懂得简略编码能够应用通用的规定引擎，引入规定引擎能够简化编码，而且让逻辑易于保护；
b、如果还要谋求配置界面的可读性，配置人员无需理解代码，开发人员就必须往前走一步，做每个业务类型的配置界面，而后再做一个界面到规定 DSL 语句的转化性能。或者类型 URule 这样做一个通用的配置界面，然而通用界面也代表了就义可交互性。
九、局部内容借鉴文档：
局部内容借鉴于：
a、规定引擎 rete 算法介绍 https://www.pudn.com/news/630367772d4eb809bf75ab38.html
b、urule 介绍：https://juejin.cn/post/6844903588725178376
c、规定引擎闲聊：https://blog.csdn.net/erik_tse/article/details/119323719
d、规定引擎闲聊：https://blog.csdn.net/erik_tse/article/details/119323719
e、AviatorScript 编程指南（5.0）https://www.yuque.com/boyan-avfmj/aviatorscript/cpow90
作者：京东保险 张江涛
起源：京东云开发者社区