规则引擎技术选型-qlExpress
目录
1.背景&痛点
1)业务规则变化快,比如 价格的系数调整,询价业务规则不断调整并且后期可能出现更多询价场景.
2)开发>50%的精力和时间在业务规则的开发上.
3)业务人员理解规则须有很强的业务知识,新规则需要开发配合,业务规则需求提出后上线的实际运行过程对业务人员不透明.导致开发和业务的沟通成本大,最好支持业务人员可视化配置规则.
4)规则的实现往往需要很多的if...else代码的嵌套,对后期开发理解和维护成本均不友好.目前对规则也有抽象,但是程度还不够且不支持业务人员可视化配置,没有实现规则表达式.
目标:快速低成本更新业务,流程自动化.
2.目前主流规则引擎框架
规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。
规则本质上是一个函数，如y=f(x1,x2,..,xn)
规则引擎由三部分
-
- 事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。
- LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。
- RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。
两个重要模块：
-
- 规则管理：可以理解为逻辑上管理规则，主要涉及规则、事实对象和规则集三个实体。涉及到规则变更时，最好对规则加个版本，可通过规则版本控制，可以平滑灰度地方式改变规则，也便于更有信心在测试规则正确性。
- 规则执行：通过规则库数据，通过规则引擎的规则解析、规则编译将可执行代码缓存起来，避免每次和DB交互，然后每次规则的变更也通过ZK或者DCC实时通知给规则执行器。规则执行器的实现方式，可以多种多样，不依赖于规则库的存储方式，可以根据需求，选用Drools、Aviator等第三方引擎，甚至可以基于ANTLR定制。
应用场景:
-
- 流程分支非常复杂，规则变量庞大，常规编码（if-else）难以实现
- 有不确定性的需求，变更频率较高
- 需要快速做出响应和决策
- 规则变更期望脱离于开发人员，脱离coding
主流的框架:
Drools、easyRule、QlExpress、Aviator、Vincio
3.优缺点比较
3.目前业务特点选型
由阿里的电商业务规则、表达式（布尔组合）、特殊数学公式计算（高精度）、语法分析、脚本二次定制等强需求而设计的一门动态脚本引擎解析工具
QLExpress
4.风险&缺点&优点
qlExpress缺点:
1.目前社区不算活跃,文档比较少,有时需要看源码
2.学习需要一定的成本
qlExpress优点:
-
- 1、线程安全，引擎运算过程中的产生的临时变量都是threadlocal类型。
- 2、高效执行，比较耗时的脚本编译过程可以缓存在本地机器，运行时的临时变量创建采用了缓冲池的技术，和groovy性能相当。
- 3、弱类型脚本语言，和groovy，javascript语法类似，虽然比强类型脚本语言要慢一些，但是使业务的灵活度大大增强。
- 4、安全控制,可以通过设置相关运行参数，预防死循环、高危系统api调用等情况。
- 5、代码精简，依赖最小，250k的jar包适合所有java的运行环境，在android系统的低端pos机也得到广泛运用。
- 6、支持高精度计算
5.运行原理图
6.参考
再见了 ! if-else ！拥抱规则引擎 https://www.jianshu.com/p/9b67ab434795
规则引擎解决方案浅析 https://www.cnblogs.com/Alandre/p/11491221.html
开源作者博客https://blog.csdn.net/express_wind?t=1
github开源地址https://github.com/alibaba/QLExpress