乐趣区

关于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 最新版)

感觉不错,别忘了顺手点赞 + 转发哦!

退出移动版