规则引擎深度对比，LiteFlow vs Drools！
作者：互联网
前言
Drools是一款老牌的java规则引擎框架，早在十几年前，我刚工作的时候，曾在一家第三方支付企业工作。在核心的支付路由层面我记得就是用Drools来做的。
难能可贵的是，Drools这个项目在十几年后还依旧保持着开源和更新。
而LiteFlow也是一款java规则引擎，于2020年开源。经过2年的迭代，现在功能和特性也非常棒，很适合用在高复杂度的核心业务上，同时又能保持业务的灵活性。
这篇文章我们就来深入比较下这两款框架，都适合用在什么样的场景，有什么异同点，以及在相同的场景下表现力如何。
（其中Drools基于7.6.0版本，LiteFlow基于2.9.0版本）
虽然题主就是开源项目LiteFlow的作者，但是我这几天也深入了解了下Drools，尽量从很客观的角度尝试去分析。很多比对的结果都是基于实际使用后的感受。不过题主难免会带有一些主观的心理以及了解的片面性，尤其是Drools现在已经更新到了8.X，说实话并没有使用过。所以说的不正确的地方也请指正。
规则引擎的定义
首先我想明确下规则引擎的定义，因为很多小伙伴容易把规则引擎和流程引擎的概念混在一起。
规则引擎通常是嵌入在应用程序组件中的，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。
简单来说就是，规则引擎主要解决易变逻辑和业务耦合的问题，规则驱动逻辑。以前项目内写死在代码里的逻辑用规则引擎可以提出来，随时热变更。
而流程引擎实现了将多个业务参与者之间按照某种预定义的规则进行流转，通常需要涉及到角色信息。
简单来说就是，流程引擎主要解决业务在不同角色之间的流转问题，如请假流程，审批流程，往往要经过多个角色。规则驱动角色流转。
两款框架的异同点
Drools和LiteFlow都是优秀的开源框架，都能把业务中的逻辑给剥离出来。并且拥有自己表达式语法。
但是有所区别的是，Drools强调逻辑的片段规则化，你可以把核心易变部分写成一个规则文件，等同于原先写在java里的代码现在搬迁到了规则文件。规则文件里的代码全都是可以热变更的。
而LiteFlow是基于组件式的思想设计的，更强调组件的规则化，覆盖范围是整个业务。编排的最小单位是组件，规则文件用来串联组件间的流转。同时LiteFlow也支持片段式的代码规则化，因为LiteFlow也支持业务逻辑的脚本化。规则支持热变更。
所以评判一个规则引擎是否合格的主要因素有：
- 有没有灵活的规则表达式来支持
- 规则和Java之间能否非常方便的联动
- API调用是否方便，和各种场景系统的集成如何
- 侵入性耦合比较
- 规则的学习成本，是否容易上手
- 规则表达式是否有语言插件
- 规则能否和业务松耦合，存储于其他地方
- 规则的变更能否实时改变逻辑
- 是否有界面形态来支持非技术人员的使用
- 框架的性能表现
下面就从这几个方面来细细比较两款框架的表现力
规则表达式
Drools的规则表达式为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。
Drools的规则表达式贴近自然编程语言，拥有自己的扩展名文件drl，语法支持全，基本上自然编程语言有的语法drl全有。所以，完全可以把java的逻辑写在drl文件中。
来看下drl文件的大体样子
可以看到，Drools定义规则的方式是一个规则一段，有明确的when...then，表示当满足什么条件时，做什么。在触发规则时候，会自动判断该去执行哪一段rule，如果满足多个条件，是可以触发多个规则的then的。
LiteFlow编排表达式简单易懂，底层用EL表达式语言包装而成。用于组件的流转，支持异步，选择，条件，循环，嵌套等一些场景。
组件层面不仅可以是java组件，还可以用脚本语言来编写，目前支持了Groovy和QLExpress两种脚本语言。所有能用java实现的，用脚本语言都可以做到。
LiteFlow的规则文件大体长这个样子：
上述LiteFlow的编排表达式中
LiteFlow编排表达式支持THEN(同步)，WHEN(异步)，SWITCH(选择)，IF(条件)，FOR(次数循环)，WHILE(条件循环)等大表达式，每个表达式又有许多扩展关键字可供选用。