万字+28张图带你探秘小而美的规则引擎框架LiteFlow

大家好，今天给大家介绍一款轻量、快速、稳定可编排的组件式规则引擎框架LiteFlow。

 

前言

在每个公司的系统中，总有一些拥有复杂业务逻辑的系统，这些系统承载着核心业务逻辑，几乎每个需求都和这些核心业务有关，这些核心业务业务逻辑冗长，涉及内部逻辑运算，缓存操作，持久化操作，外部资源调取，内部其他系统RPC调用等等。时间一长，项目几经易手，维护的成本就会越来越高。各种硬代码判断，分支条件越来越多。代码的抽象，复用率也越来越低，各个模块之间的耦合度很高。一小段逻辑的变动，会影响到其他模块，需要进行完整回归测试来验证。如要灵活改变业务流程的顺序，则要进行代码大改动进行抽象，重新写方法。实时热变更业务流程，几乎很难实现。

LiteFlow框架的作用

LiteFlow就是为解耦复杂逻辑而生，如果你要对复杂业务逻辑进行新写或者重构，用LiteFlow最合适不过。它是一个轻量，快速的组件式流程引擎框架，组件编排，帮助解耦业务代码，让每一个业务片段都是一个组件，并支持热加载规则配置，实现即时修改。

使用LiteFlow，你需要去把复杂的业务逻辑按代码片段拆分成一个个小组件，并定义一个规则流程配置。这样，所有的组件，就能按照你的规则配置去进行复杂的流转。

LiteFlow的设计原则

LiteFlow是基于工作台模式进行设计的，何谓工作台模式？

n个工人按照一定顺序围着一张工作台，按顺序各自生产零件，生产的零件最终能组装成一个机器，每个工人只需要完成自己手中零件的生产，而无需知道其他工人生产的内容。每一个工人生产所需要的资源都从工作台上拿取，如果工作台上有生产所必须的资源，则就进行生产，若是没有，就等到有这个资源。每个工人所做好的零件，也都放在工作台上。

这个模式有几个好处：

• 每个工人无需和其他工人进行沟通。工人只需要关心自己的工作内容和工作台上的资源。这样就做到了每个工人之间的解耦和无差异性。
• 即便是工人之间调换位置，工人的工作内容和关心的资源没有任何变化。这样就保证了每个工人的稳定性。
• 如果是指派某个工人去其他的工作台，工人的工作内容和需要的资源依旧没有任何变化，这样就做到了工人的可复用性。
• 因为每个工人不需要和其他工人沟通，所以可以在生产任务进行时进行实时工位更改：替换，插入，撤掉一些工人，这样生产任务也能实时地被更改。这样就保证了整个生产任务的灵活性。

这个模式映射到LiteFlow框架里，工人就是组件，工人坐的顺序就是流程配置，工作台就是上下文，资源就是参数，最终组装的这个机器就是这个业务。正因为有这些特性，所以LiteFlow能做到统一解耦的组件和灵活的装配。

二、LiteFlow的使用

1）非Spring环境下

引入pom依赖

<dependency>
   <groupId>com.yomahub</groupId>
   <artifactId>liteflow-core</artifactId>
   <version>2.6.13</version>
</dependency>

第一步构建自己的业务Node，也就是继承NodeComponent，重写process方法，业务执行的过程中，会调用process来执行节点的业务。

我这里写了三个

然后编写xml文件，直接放在resources底下

<nodes/>配置了每个业务的节点，这里配置了我们写的那几个，<chain/>标签代表了每一个业务的执行流程，配置了<when/>和<then/>标签，然后value标签设置了上面配置的<node/>的id，至于为什么这么配置，后面会解析。

然后执行这个demo

构建了一个LiteflowConfig，传入xml的路径，然后构建FlowExecutor，最后调用FlowExecutor的execute2Resp，传入需要执行的业务流程名字 chain1 ，就是xml中配置的，执行业务流程。

结果

如果业务变动，现在不需要执行B流程了，那么直接修改规则文件就行了，如图。

运行结果

这里发现B就没执行了。

2）SpringBoot环境下

引入pom依赖

<dependency>
   &