白话文解析LiteFlow的理念是什么？什么时候用该怎么用？干货满满.docx

第

白话文解析LiteFlow的理念是什么？什么时候用该怎么用？干货满满

官网：https://liteflow.cc/

Gitee：/dromara/liteFlow

Github：/dromara/liteflow

LiteFlow一个现代化的开源规则引擎框架，以下文中简称LF。

时常在社区里看到有的小伙伴在那提问：

LF在一个流程中如何暂停，等待操作员完成后，进行下一步该怎么做？

LF流程失败后，下一次能否继续上次的执行？

LF流程适不适合某个我的业务？

LF流程如何定时执行我的某个流程？

还有的同学表示即便全部看完文档，也不知道LF该用在何种业务场景。能够带来什么好处。

究其原因是错误理解了流程的概念和不知道规则引擎的概念。

我们先说流程。

LiteFlow定位是一个规则引擎，而不是流程引擎。它并不完成流程所要做的事，其实压根LF和流程一点关系也没有。

那什么是流程呢，标准的定义是，流程由流程定义，节点要做的事和角色组成。每一个角色做一件事，根据定义的流程定义串起来就叫流程。最典型的例子就是审批流：采购员提交了一张采购申请，部门领导审核，审核通过则到了财务这里，财务专员根据预算进行审核，审核通过到了总监这里，总监审核通过，再到CEO这里签字批准。整个采购单状态变成待采购。然后进行采购流程。

以上就是标准的一个流程。3大要素，流程定义，事和角色一个都不能少。通常在实际落地过程中，流程引擎负责流程的流转和角色的分派。开发人员只需要定义流程，和开发每个角色需要做的逻辑即可。

流程引擎重点强调2点：

流程的定义，下一步是什么，整体的流向，有多少分支。

角色的分派，即下一步该由谁完成。

大部分流程引擎为了灵活性，也提供了流程定义的热更新以及添加角色，修改流程节点更改绑定角色的功能。

虽然LF从EL规则上来看，似乎也是一个个小模块的流转，但是LF并不涉及角色分派这件事。

我们再来看规则引擎的概念。

规则引擎主要强调一件事，把业务中最主要的决策逻辑从程序中抽离出来，用预定义的DSL来实现。并且可以实时改变这些最主要的决策逻辑。

说的再白话点，就是决定逻辑走向的最关键的决策逻辑，不是在代码中的，可以放在外面的任意地方(文件里，数据库里，其他存储，远程获取）。并且这些决策逻辑并不是用你应用的代码语义来实现的。规则引擎提供一套语言，来书写这些决策逻辑。规则引擎也应该提供热更新这些决策代码的功能。

可以看出，规则引擎根本不涉及角色的概念，它更多的适用于一个相对比较复杂的逻辑块。把最核心的部分抽出来用规则引擎定义。

但是整个逻辑块基本要做的还是一件事情。只是部分抽出来而已。

标准的规则引擎处理的例子：

如果有人v我50块，我就去家门口的KFC吃一顿

如果有人v我200块，我就坐地铁去港式餐厅吃一顿

如果有人v我500块，我就打个车，去吃顿日式烤肉

如果有人v我2000块，我就去买身衣服，去吃顿惠林顿牛排，再整瓶酒。

如果有人v我100w，赶紧抽自己一巴掌，看自己醒了没。

有同学看到这，可能会说，那我搞个文件，存groovy代码，我应用每次执行到关键决策的时候，去读取这个文件里的groovy代码，然后解析执行。这不就是规则引擎吗，我要改变决策的时候，每次改那个文件里的groovy代码就行了。

还真是这样！这就是规则引擎！

简单来说，规则引擎就强调3个点：

决策代码不在你的应用程序里

拥有独特的DSL语义书写

实时更新，不用改变应用程序

所以，一些DSL项目也被称作为规则引擎，如Aviator，QLExpress。这些框架提供了热更的接口，稍作包装，就可以开发出一套最基本的规则引擎。

但是我更愿意把这些项目归类为表达式引擎，业界还有著名的SpEL(spring的EL)，springframworkexpressionlanguage，其实从全程就可以看出，官方定义了就是表达式语言。

LF满足决策代码可以不写在应用程序里，也拥有独特的DSL，也支持实时更新。但是LF怎么还拥有流转的功能？LF看起来怎么有点四不像啊？

那LF是什么呢

LF也是作用于一个大的逻辑块的，和角色没关系，满足规则引擎的需要的3个关键点。从这点来说，LF是规则引擎。

LiteFlow中的脚本节点已经满足了规则引擎的全部的定义了。那么LF只做脚本节点就可以了。可以热更，拥有独特的DSL，可以保存在任意地方。

但是LF也可以流转，从一个节点