Drools支持了编程式接入 ， 但是在springboot中需要自己写很多配置类来去集成 。
LiteFlow不仅支持了编程式接入 ， 在springboot环境下更是提供了自动装配的starer接入方式 ， 连定义LiteFlowExecutor都不需要 ， 直接从上下文中就可以拿到自动装配后的对象进行调用 。
结论
LiteFlow api更加简单 ， 同Springboot集成度更加高 。
侵入性耦合比较Drools需要在java代码里需要用到规则的地方用KSession对象去匹配规则进行调用 。规则和java是分离的 。在调用层面耦合了KSession调用对象 。
LiteFlow的规则和java也是分离的 ， 但是LiteFlow多了组件这一概念 ， 所以在组件层面是需要继承的 ， 但是同时也提供声明式组件的选择 ， 使用声明式的方式耦合相对要减少一些 。在调用层面也需要去调用LiteFlowExecutor对象 。
结论
在耦合度上面 ， 由于LiteFlow提供编排特性 ， API耦合度相对稍高一些 。Drools耦合少一些 。
规则的学习成本Drools的规则学习成本挺高的 。由于是自研的规则语法 ， 需要一个很全面的熟悉过程 。而且文档全英文 。
LiteFlow的编排规则极其简单 ， 如果你不使用脚本组件的话 ， 基本上10分钟即可上手 。就算使用了groovy脚本 ， 由于groovy非常类似于java ， 学习成本也非常少 。况且有大量的学习资料可以参阅 。
LiteFlow的文档中英文齐全 ， 还有良好的中文社区可以答疑解惑 。
结论
在规则学习成本上 ， Drools的规则学习曲线比LiteFlow高出不止一丁点 。
是否有语言插件Drools在Eclipse和IDEA上均有插件来做语法的高亮 ， 预检查和提示 。
LiteFlow在IDEA上有插件来做高亮 ， 预检查和提示 。Eclipse上没有 。
结论
考虑到使用eclipse的人几乎很少了 ， 基本上2款规则引擎在语言插件上都做到了 。
规则的存储Drools的规则理论上支持你的规则存于任何地方 ， 但这一切都需要你手动去额外完成 。自己去存 ， 自己去取 。
Drools还有款workbeanch的插件 ， 可以将规则存于workbeanch中 。只有这个是不需要自己存取的 。
LiteFlow除了本地规则以外 ， 原生支持将规则存储于任何标准SQL的数据库 ， 还原生支持了Nacos ， Etcd ， zookeeper等注册中心 。只需要配置一下即可 。除此之外 ， 还提供了扩展接口 ， 方便你自己扩展成任意的存储点 。
结论
LiteFlow的规则存储支持比Drools丰富的多 。
规则的变更能否实时改变逻辑Drools热刷新规则的方式现在看起来有点傻 ， 它的规则是通过生成jar的方式 。然后系统远程动态读取jar包来完成规则刷新的 。
而且一定得通过workbench的方式进行规则的热变更 。
LiteFlow在这个层面做的高级很多 。如果你是用Nacos ， Etcd ， zookeeper等方式存储 ， 不用做任何事 ， 改变即自动刷新 。如果你是SQL数据库存储 ， 或者本地存储 。在改变规则之后 ， 需要调用LiteFlow框架提供的一个API进行热变更 。2种方式均可热更新 。并且在高并发情况下是平滑的 。
结论
LiteFlow在热更新设计层面比Drools先进很多 。
是否有界面形态来支持Drools有workbench ， workbench是一个独立的插件包 ， 提供了web界面编写规则以及fact对象 。并提供了检查和部署的能力 。但因为Drools主要关心逻辑片段 ， 并不需要提供编排层面的拖拽UI功能 ， 只是提供了在界面上编写规则的能力 。
经验总结扩展阅读
- 跟爱人缺乏深度沟通，所以矛盾不断的星座男
- Mysql单表访问方法，索引合并，多表连接原理，基于规则的优化，子查询优化
- 真心话大冒险六条规则（真心话大冒险一至六规则图)
- tensorflow-gpu版本安装及深度神经网络训练与cpu版本对比
- MYSQL-->InnoDB引擎底层原理
- 麻将玩法说明（南城麻将玩法规则)
- 使用开源计算引擎提升Excel格式文件处理效率
- 有深度有涵养的句子 静心养心修心十句话
- 学生票打折规则
- 会玩飞行棋怎么进房间（飞行棋的玩法和规则)