规则引擎深度对比,LiteFlow vs Drools!

前言Drools是一款老牌的java规则引擎框架 , 早在十几年前 , 我刚工作的时候 , 曾在一家第三方支付企业工作 。在核心的支付路由层面我记得就是用Drools来做的 。
难能可贵的是 , Drools这个项目在十几年后还依旧保持着开源和更新 。

https://github.com/kiegroup/drools
而LiteFlow也是一款java规则引擎 , 于2020年开源 。经过2年的迭代 , 现在功能和特性也非常棒 , 很适合用在高复杂度的核心业务上 , 同时又能保持业务的灵活性 。
https://gitee.com/dromara/liteFlow
这篇文章我们就来深入比较下这两款框架 , 都适合用在什么样的场景 , 有什么异同点 , 以及在相同的场景下表现力如何 。
(其中Drools基于7.6.0版本 , LiteFlow基于2.9.0版本)
虽然题主就是开源项目LiteFlow的作者 , 但是我这几天也深入了解了下Drools , 尽量从很客观的角度尝试去分析 。很多比对的结果都是基于实际使用后的感受 。不过题主难免会带有一些主观的心理以及了解的片面性 , 尤其是Drools现在已经更新到了8.X , 说实话并没有使用过 。所以说的不正确的地方也请指正 。
规则引擎的定义首先我想明确下规则引擎的定义 , 因为很多小伙伴容易把规则引擎和流程引擎的概念混在一起 。
规则引擎通常是嵌入在应用程序组件中的 , 实现了将业务决策从应用程序代码中分离出来 , 并使用预定义的语义模块编写业务决策 。接受数据输入 , 解释业务规则 , 并根据业务规则做出业务决策 。
简单来说就是 , 规则引擎主要解决易变逻辑和业务耦合的问题 , 规则驱动逻辑 。以前项目内写死在代码里的逻辑用规则引擎可以提出来 , 随时热变更 。
而流程引擎实现了将多个业务参与者之间按照某种预定义的规则进行流转 , 通常需要涉及到角色信息 。
简单来说就是 , 流程引擎主要解决业务在不同角色之间的流转问题 , 如请假流程 , 审批流程 , 往往要经过多个角色 。规则驱动角色流转 。
两款框架的异同点Drools和LiteFlow都是优秀的开源框架 , 都能把业务中的逻辑给剥离出来 。并且拥有自己表达式语法 。
但是有所区别的是 , Drools强调逻辑的片段规则化 , 你可以把核心易变部分写成一个规则文件 , 等同于原先写在java里的代码现在搬迁到了规则文件 。规则文件里的代码全都是可以热变更的 。
而LiteFlow是基于组件式的思想设计的 , 更强调组件的规则化 , 覆盖范围是整个业务 。编排的最小单位是组件 , 规则文件用来串联组件间的流转 。同时LiteFlow也支持片段式的代码规则化 , 因为LiteFlow也支持业务逻辑的脚本化 。规则支持热变更 。
所以评判一个规则引擎是否合格的主要因素有:
  1. 有没有灵活的规则表达式来支持
  2. 规则和Java之间能否非常方便的联动
  3. API调用是否方便 , 和各种场景系统的集成如何
  4. 侵入性耦合比较
  5. 规则的学习成本 , 是否容易上手
  6. 规则表达式是否有语言插件
  7. 规则能否和业务松耦合 , 存储于其他地方
  8. 规则的变更能否实时改变逻辑
  9. 是否有界面形态来支持非技术人员的使用

    经验总结扩展阅读