作者:豫州牧\
链接: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最新版)
感觉不错,别忘了顺手点赞+转发哦!