共计 3242 个字符，预计需要花费 9 分钟才能阅读完成。
作者：豫州牧 \
链接：https://juejin.cn/post/7296771770098745344
1、前言
在日常的开发过程中，常常会遇到一些串行或者并行的业务流程问题，而业务之间不用存在相关性。
在这样的场景下，应用策略和模板模式的联合能够很好的解决这个问题，然而应用编码的形式会使得文件太多, 在业务的局部环节能够这样操作，在我的项目角度就无奈一眼洞穿其中的环节和逻辑。在本文中，将引入规定引擎从全局角度来解决这个问题，这就是明天要介绍的配角 liteflow。
2、liteflow 规定引擎
liteflow 是一个笨重而且弱小的规定引擎，可能实现开箱即用，能够在短时间内就能够实现简单的规定编排，下图是 liteflow 的整体架构。liteflow 反对较多的规定文件格式，比方 xml/json/yaml，对于规定文件的存储形式能够有 sql/zk/nacos/apollo 等。
liteflow 的应用是从获取上下文开始的，通过数据上下文来解析对应的规定文件，通过 liteflow 执行器来执行对应的链路，每个链路上都有须要执行的业务 node（即节点组件，能够反对多种语言脚本，groovy/js/python/lua 等）, 各个业务 node 之间是独立的。
liteflow 对应的官网网址和依赖如下所示：
# liteflow 规定引擎官网网址
https://liteflow.yomahub.com
# springboot 集成 liteflow
<dependency>
<groupId>com.yomahub</groupId>
<artifactId>liteflow-spring-boot-starter</artifactId>
<version>2.10.6</version>
</dependency>liteflow 能够反对如下所示的简单流程
此外，liteflow 能够反对热部署，能够实时替换或者减少节点，即批改规定文件后能够实时失效。
3、liteflow 的应用办法
3.1 组件
liteflow 的组件在规定文件中即对应的节点，组件对应的品种有很多，具体的如下所示：
- 一般组件
一般组件须要集成的是 NodeComponent, 能够用在 when 和 then 逻辑中，具体的业务须要在 process 中去执行。同时在 node 节点中，能够笼罩 iaAccess 办法，示意是否进入该节点执行业务逻辑，isContinueOnError 判断在出错的状况下是否继续执行下一个组件，默认为 false。isEnd 办法示意是否终止流程，默认为 true。
- 抉择组件
抉择组件是通过业务逻辑来判断接下来的动作要执行哪一个节点，相似于 Java 中的 switch , 在代码中则须要继承 NodeSwitchComponent 实现 processWitch 办法来解决业务。
# flow 规定表达式 抉择组件
SWITCH(a).to(b, c);
# processWitch 表达式须要返回的是 b 或者 c 字符串来执行相应的业务逻辑
# flow 规定表达式 条件组件
IF(x, a, b);- 条件组件
条件组件称之为 if 组件，返回的后果是 true 或者 false, 代码须要集成 NodeIfComponent 重写 processIf 办法，返回对应的业务节点，这个和抉择组件相似。
在官网文档中，还有次数循环组件，条件循环组件，循环迭代组件，和退出循环组件，作者认为其利用场景比较复杂，能够应用简略的一般组件来代替，毕竟是轻量级的规定引擎，次要作用就是为了编排流程程序，简单的场景就降级应用工作流了，所以这里只介绍以上三种组件。
3.2 EL 规定文件
规定文件的编写和组件的应用是对应的，这里应用 xml 的模式来编写。
# 文件编排，then 代表串行执行 when 示意并行执行
# 串行编排示例
THEN(a, b, c, d);
# 并行编排示例
WHEN(a, b, c);
# 串行和并行嵌套联合
THEN(a, WHEN(b, c, d), e);
# 抉择编排示例
SWITCH(a).to(b, c, d);
# 条件编排示例
THEN(IF(x, a),b );3.3 数据上下文
在 liteflow 中，数据上下文的概念十分重要，上下文对象起到参数传递的作用，因为不同业务须要的输入输出参数是不同的，所以上下文十分的重要。
# 执行流程时，须要传递 el 文件，初始化参数以及上下文对象，这里的上下文能够设置多个
LiteflowResponse response = flowExecutor.execute2Resp("chain1", 流程初始参数, CustomContext.class);因为上下文传入的是一个 class 类型参数，流程参数是能够传入参数的，个别状况下是在第一个节点中，将传入参数设置到上下文对象中。
Spring Boot 根底就不介绍了，举荐看这个实战我的项目：
https://github.com/javastacks/spring-boot-best-practice
3.4 参数配置
在 liteflow 中，须要配置的内容有规定文件地址，节点重试（执行报错时能够进行重试，相似于 spring-retry）, 流程并行执行线程池参数配置，流程的申请 ID 配置。
liteflow:
# 规定文件 失败重试次数 打印执行日志 监控日志
ruleSource : liteflow/*.el.xml
retry-count: 0
print-execution-log: true
monitor:
enable-log: true
period: 300000
request-id-generator-class: com.platform.orderserver.config.AppRequestIdGenerator
# 上下文的最大数量槽
slot-size : 10240
# 线程数，默认为 64
main-executor-works: 64
# 异步线程最长等待时间 秒
when-max-wait-seconds: 15
# when 节点全局异步线程池最大线程数
when-max-workers: 16
# when 节点全局异步线程池队列数
when-queue-limit: 5120
# 在启动的时候就解析规定
parse-on-start: true
enable: true4、业务实际
之前介绍了 liteflow 的一些概念，在这里联合一些业务场景来进行演示:
# 次要应用电商场景的利用，订单实现后，进行积分的发放，音讯发送，同时并行发送短信和邮件。<?xml version="1.0" encoding="UTF-8"?>
<flow>
<chain name="test_flow">
THEN(prepareTrade, grantScore, sendMq, WHEN(sendEmail, sendPhone)
);
</chain>
</flow>在订单实现之后异步执行，传递参数并执行相应的规定流程。
在正式解决业务流程之前，须要先进行数据的预处理，将流程入参转转换成上下文对象，不便参数的传递和设置。
在具体的业务解决环节，以积分发放为例，能够获取上下文对象进行业务操作，同时也能够重写 isAccess 办法，来判断是否解决该节点。
如上图所示，具体的业务流程都能够形象成一个 node 节点，寄存在 test_flow.el.xml 中进行执行，其它的代码都和积分发放相似，这里就不再赘述，能够参见代码。
5、总结
liteflow 中的绝大部分是在启动时实现的，包含规定解析、注册组件以及组装信息，其执行性能很高，同时也能够打印每个业务环节的耗时以及统计信息。
在本文中，介绍了 liteflow 的基本概念，以及具体的应用办法，具体的代码曾经上传到 github：https://github.com/thedestiny/springboot-auth/
更多文章举荐：
1.Spring Boot 3.x 教程，太全了！
2.2,000+ 道 Java 面试题及答案整顿 (2024 最新版)
3. 收费获取 IDEA 激活码的 7 种形式（2024 最新版）
感觉不错，别忘了顺手点赞 + 转发哦！
