聊聊流程编排框架LiteFlow

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

大家好，我是G探险者！

今天聊一聊流程编排框架，liteflow

LiteFlow 是一个开源的 Java 业务流程编排框架，适合把一段较长的后端业务拆成多个可复用的处理节点，再通过流程定义把这些节点按顺序、条件或并行方式组合起来执行。

它的定位不是传统 BPM、工作流审批平台，也不是规则引擎，而是更偏向于服务端业务链路编排。常见应用场景包括：

数据管道处理
MQ 消息消费编排
外部系统同步
复杂表单提交后的分阶段处理
多场景共用一批处理步骤的业务系统

如果一个系统里经常出现下面这类代码：

 
  
    
     
     if (typeA) { init(); validate(); save(); sendMq();  
     } else if (typeB) { 
     init(); transform(); callRemote();  
     } else if (typeC) { 
     init(); validate(); callRemote(); save();  
     }

 那么就很适合考虑用 LiteFlow 把这些步骤拆开管理。

在没有流程编排框架时，业务代码通常会遇到这些问题：

同一个步骤在多个场景里重复出现
分支越来越多，if/else 越来越重
处理顺序写死在代码里，修改流程要改源码
代码里混杂初始化、校验、转换、落库、发消息等多种职责
新场景接入时只能复制旧逻辑再改

LiteFlow 的核心思路是：

把业务拆成一个个小节点
每个节点只做一件事
用流程定义把节点拼起来
用统一执行器去运行流程

这样可以让业务链路更清晰，也更容易复用和扩展。

节点是 LiteFlow 的最小执行单元。通常一个节点只负责一类动作，例如：

参数初始化
数据校验
状态过滤
DTO 转实体
落库
调用外部接口
发送 MQ

在代码里，节点一般通过继承 NodeComponent 来实现：

 
  
    
     
     @LiteflowComponent("demoCmp")  
     public class DemoCmp extends NodeComponent { 
     @Override public void process() throws Exception { System.out.println("execute demoCmp"); }  
     }

 这里的 "demoCmp" 就是节点 ID，后续在流程定义里会引用它。

流程链表示多个节点的组合方式。最常见的是串行：

 
  
    
     
     chain:  
      
      name: demoFlow value: "THEN(a, b, c)"

它表示执行顺序是：

a -> b -> c

执行器负责真正触发流程：

 
  
    
     
     LiteflowResponse response = flowExecutor.execute2Resp("demoFlow", null, context); 
    
 这里的 "demoFlow" 是流程名，context 是执行时携带的数据上下文。

上下文用于在整条流程中传递公共数据。常见做法是定义一个 Java Bean：

 
  
    
     
     public class DemoContext { private String id; private String type; private String data;  
     }

 执行流程时把它传进去，节点内部再读取： 
  
    
     
     DemoContext context = this.getContextBean(DemoContext.class);

Slot 可以理解成一次流程执行过程中的运行时容器。除了上下文 Bean，LiteFlow 还允许通过 slot 在节点之间传递中间结果。

这在"上一个节点把原始数据转换成业务对象，下一个节点继续处理"的场景里很常见。

LiteFlow 不只是串行流程。它支持多种编排表达式。

 
  
    
     
     THEN(a, b, c) 
    
 表示顺序执行。 
  
    
     
     WHEN(a, b, c) 
    
 表示并行执行多个节点。 
  
    
     
     IF(x, a, b) 
    
 根据条件节点或表达式选择分支。 
  
    
     
     SWITCH(x).TO(a, b, c) 
    
 根据不同条件走不同流程。

LiteFlow 支持把串行、并行、条件嵌套组合，适合更复杂的业务链。

一个最小可用的 LiteFlow 例子通常包含以下几个部分。

 
  
    
     
      
         
         
           com.yomahub 
          
         
           liteflow-spring-boot-starter 
          
         
           2.12.4.1

 
  
    
     
     @LiteflowComponent("validateCmp")  
     public class ValidateCmp extends NodeComponent { 
     @Override public void process() { System.out.println("validate"); }  
     }

 
  
    
     
     @LiteflowComponent("saveCmp")  
     public class SaveCmp extends NodeComponent { 
     @Override public void process() { System.out.println("save"); }  
     }

 
  
    
     
     flow:  
     chain: 
     - name: submitFlow value: "THEN(validateCmp, saveCmp)" 
     
  
    
     
     liteflow:  
     rule-source: liteFlow.yml

 
  
    
     
     LiteflowResponse response = flowExecutor.execute2Resp("submitFlow", null, context);  
     if (!response.isSuccess()) { 
     throw new RuntimeException("flow execute failed");  
     }

相比把流程顺序直接写在代码里，LiteFlow 可以把链路显式表达出来。阅读者可以很快知道某个场景到底会经过哪些步骤。

同一个节点可以被多条流程复用。例如：

validateCmp 可以给新增流程使用
也可以给 MQ 消费流程使用

新增场景时，通常只需要新增流程定义，或者在原流程上拼接几个新节点，而不是复制整段业务代码。

把"初始化、校验、转换、输出"拆成独立节点后，单个类更短，责任更明确。

凡是"输入数据 -> 处理步骤 -> 输出结果"这类链路，都很适合用 LiteFlow 组织。

LiteFlow 的流程定义通常写在配置中，而节点逻辑写在 Java 代码中。链路排查时需要同时看两边。

流程名、节点名、上下文类型名如果写错，问题往往不会在编译期暴露，而是在运行时体现。

很多项目会使用 slot 传递中间结果。如果管理不好，节点之间容易出现类型不一致的问题。

如果本来只有两步简单逻辑，却拆成十几个节点，反而会提高理解成本。

问题可能出在：

流程定义
节点注册
节点执行顺序
上下文传递
中间数据结构

所以调试通常比普通单方法代码更复杂。

适合：

多种业务场景共享一批步骤
不同来源的数据要走不同处理链
流程经常增删节点
需要把校验、转换、输出解耦
需要让业务链路表达得更清楚

不太适合：

极简单的 CRUD
只有一两步处理的直线逻辑
强依赖超长事务的复杂编排
需要完整业务流程可视化建模的平台型产品

LiteFlow 和 BPMN、Activiti、Flowable 这类工作流引擎不是一个层级的东西。

它们大致区别如下：

偏后端代码编排
轻量
面向开发人员
强调节点组合
更适合服务内部链路

偏业务流程引擎
支持审批流、流程图、流程实例管理
更强调流程持久化和可视化
更适合人参与的长流程

简单说，LiteFlow 更像"程序员用的业务装配器"。

如果决定在项目里使用 LiteFlow，建议遵守以下约束：

不要在一个节点里同时做校验、转换、落库、发 MQ。

例如统一使用：

xxxSlotInitCmp
xxxValidatorCmp
xxxConvertCmp
xxxDBOutputCmp
xxxMqOutputCmp

尽量明确每条链路的输入输出数据结构，减少节点间"隐式约定"。

改流程定义时，要同步检查：

节点名称是否一致
流程名是否一致
路由逻辑是否一致

如果业务只有两三步，直接写服务代码往往更简单。

在当前项目中，LiteFlow 的用法非常典型：

通过 topic/subTopic 决定走哪条业务链
通过 liteFlow.yml 定义节点和流程
通过 NodeComponent 实现每个步骤
通过 FlowExecutor 执行整条链

这里它承担的角色不是规则计算，而是"数据处理流程编排"：

API 输入和 MQ 输入统一走编排入口
不同业务主题走不同链路
链路中的步骤大多是初始化、校验、转换、落库、发消息

这说明当前工程使用 LiteFlow 的方向是合理的，属于它比较擅长的场景。

LiteFlow 是一个适合后端业务链路拆分与编排的开源框架。它的核心价值在于：

把流程拆开
把步骤复用起来
让链路更清楚
让扩展更容易

它非常适合数据管道、MQ 消费、外部系统同步这类"多场景共享处理步骤"的系统。但如果业务本身很简单，直接编码通常更合适。

是否采用 LiteFlow，不应只看它是否开源或是否流行，而应看当前业务是否真的存在流程编排、步骤复用、场景扩展这些需求。

聊聊流程编排框架LiteFlow

相关推荐