关于java:Spring-Boot-liteflow-规则引擎太香了

作者：豫州牧 \
链接：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: true

4、业务实际

之前介绍了 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 最新版）

感觉不错，别忘了顺手点赞 + 转发哦！