Drools

1. 一款老牌的java规则引擎框架. 十几年前. (十几年后还依旧保持着开源和更新:难得)

LiteFlow

• 功能和特性也非常棒
• 很适合用在高复杂度的核心业务上。 同时又能保持业务的灵活性.

比较一下 2款框架, 都适合用在什么样的场景，有什么异同点，以及在相同的场景下表现力如何。

一、规则引擎的 作用和目的.

• 解决易变逻辑和业务耦合的问题。 规则驱动逻辑。 【随时热变更】

相比较： 流程引擎(实现了将多个业务参与者之间按照某种预定义的规则进行流转，通常需要涉及到***角色信息***)
简单来说就是，流程引擎主要解决业务在不同角色之间的流转问题，如请假流程，审批流程，往往要经过多个角色。规则驱动角色流转。

二、Drools、LiteFlow 异同点.

都是优秀的开源框架,能把业务中的逻辑给剥离出来. 拥有自己表达式语法。

1. Drools强调逻辑的片段规则化(可以 把核心易变部分写成一个规则文件)。 等同于原先写在java里的代码现在搬迁到了规则文件。规则文件里的代码全都是可以热变更的。

2. 而LiteFlow是基于组件式的思想设计的。更强调组件的规则化，覆盖范围是整个业务，编排的最小单位是组件，规则文件用来串联组件间的流转。
- 同时LiteFlow也支持片段式的代码规则化，因为LiteFlow也支持业务逻辑的脚本化。规则支持热变更。

三、评判一个规则引擎是否合格的主要因素有：

1. 有没有灵活的规则表达式来支持
2. 规则和Java之间能否非常方便的联动
3. API调用是否方便，和各种场景系统的集成如何
4. 侵入性耦合比较
5. 规则的学习成本，是否容易上手.
6. 规则表达式是否有语言插件
7. 规则能否和业务松耦合，存储于其他地方.
8. 规则的变更能否实时改变逻辑
9. 是否有界面形态来支持非技术人员的使用
10. 框架的性能表现

四、规则表达式

Drools的规则表达式为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。

五、 其他问题

• 面向的用户是谁？ 专业技术人员？ 运营人员？ 产品人员？ 风控产品、风控策略？.

规则引擎深度对比，LiteFlow vs Drools！