流程引擎、工作流、规则引擎、编排系统、表达式引擎……天呐，我到底该用哪个？

你是不是也有这些困惑

看项目文档，各种名词扑面而来：

• 流程引擎（Flowable、Camunda）
• 工作流（Activiti）
• 规则引擎（Drools）
• 编排系统（LiteFlow）
• 表达式引擎（QLExpress、Aviator）
• DAG调度（Airflow、DolphinScheduler）
• 任务编排（Temporal、Conductor）
• BPMN、Saga、Event-Driven...

每个框架都说自己能解决问题，每个概念看起来都差不多。

新手一脸懵逼，老手也经常搞混。

干了20年，我也被这些东西搞晕过。今天不讲那些虚的，直接告诉你怎么选。

答案很简单：别管这些名词，问自己四个问题就够了。

忘掉那些名词，只问四个问题

看了一堆框架介绍还是不知道选哪个？正常，因为你在纠结概念。

别纠结了，概念都是虚的。问自己四个问题，立刻就清楚了。

问题1：你是要干活，还是改状态？

这是最关键的一个问题。搞清楚这个，一大半框架就排除了。

改状态是什么意思？

请假审批：
员工提交 → 主管看了说"行" → HR看了说"行" → 完成

整个过程：
- 没有计算
- 没有数据转换
- 没有调用外部系统
- 就是状态从 pending 变成 approved

这就是纯改状态。

干活是什么意思？

订单处理：
下单 → 扣库存 → 调支付接口 → 调物流接口 → 发货

整个过程：
- 要计算金额
- 要调用外部API
- 要处理数据
- 要执行业务逻辑

这就是干活。

判断标准：

• 改状态：就是让人点"同意"或"拒绝"，除了改个字段，啥也没干
• 干活：要计算、要调API、要处理数据

对应框架：

• 改状态 → BPMN系（Flowable、Camunda）
• 干活 → 继续往下判断

问题2：主要是人处理，还是机器执行？

人处理：

审批流程：
- 主管要看文档
- 主管要做判断
- 主管要点按钮
- 然后等下一个人

特点：大部分时间在等人

机器执行：

数据处理：
- 读数据库
- 清洗数据
- 转换格式
- 写入目标表

特点：机器自己跑，不用人管

对应框架：

• 人为主 → BPMN系（Flowable、Camunda）
• 机器为主 → 继续往下判断

问题3：是本地方法，还是跨系统调用？

本地方法：

营销规则：
- 判断用户是不是VIP
- 计算折扣
- 返回结果

都在一个应用里，不用调外部接口

跨系统调用：

订单流程：
- 调库存系统（HTTP）
- 调支付系统（HTTP）
- 调物流系统（HTTP）

要跨多个服务

对应框架：

• 本地 → 表达式系、脚本系（QLExpress、LiteFlow）
• 跨系统 → DAG系、服务编排系（Airflow、Temporal）

问题4：自己玩，还是要搞生态？

自己玩：

你的团队自己维护：
- 规则你们自己写
- 代码你们自己改
- 不需要外部开发者

搞生态：

做平台，让别人扩展：
- 客户可以上传插件
- 第三方可以写脚本
- 需要沙箱隔离

对应技术：

• 自己玩 → 表达式 + 代码（QLExpress、Aviator）
• 搞生态 → Groovy脚本、插件机制

那些让人头疼的框架，到底是干什么的

四个问题问完，你大概知道方向了。现在看看具体框架都是什么情况。

不用全看，只看和你匹配的那一类就行。

BPMN系：Flowable、Camunda、Activiti

适合场景：

• 纯人工审批流程
• 需要流程图可视化
• 需要历史记录追溯
• 大公司、强合规要求

典型例子：

• 请假审批
• 报销审批
• 合同审批
• 采购流程

核心特点：

• 本质就是改状态
• 大部分时间在等人
• 业务价值为0（只是流程管理）
• 技术难度不高（就是状态机）

什么时候用：

• 大公司（100+人），有几十个审批流程要管理
• 金融、政府等强合规行业
• 需要标准化流程管理

什么时候别用：

• 小公司（别用，钉钉审批就够了）
• 没有复杂审批需求（自己写100行代码搞定）
• 为了"企业级"而用（过度设计）

DAG系：Airflow、DolphinScheduler、Prefect

适合场景：

• 数据处理任务
• 离线批处理
• 定时调度
• 任务有依赖关系

典型例子：

• 数据ETL
• 报表生成
• 数据清洗
• 机器学习Pipeline

核心特点：

• 纯机器执行
• 长时间运行（小时、天级）
• 任务之间有依赖（A完成才能B）
• 需要调度和监控

什么时候用：

• 数据团队做离线处理
• 有复杂的任务依赖关系
• 需要定时调度（每天、每周）

什么时候别用：

• 实时性要求高的（秒级响应）
• 简单的定时任务（用Cron就够了）
• 没有依赖关系的任务

表达式/脚本系：QLExpress、Aviator、LiteFlow、Groovy

适合场景：

• 规则计算
• 业务流程编排
• 本地方法调用
• 需要动态配置

典型例子：

• 营销活动规则（满减、折扣）
• 风控规则（黑名单、评分）
• 订单流程（本地编排）
• 积分计算

QLExpress / Aviator（表达式）：

• 优点：性能好、类Java语法、团队容易上手
• 缺点：功能受限、只能简单计算
• 适合：自己团队玩、简单规则

Groovy（脚本）：

• 优点：功能完整、可以调复杂API
• 缺点：性能差、调试难、类型不安全
• 适合：要搞插件生态、客户自定义逻辑

LiteFlow（编排）：

• 优点：可视化编排、组件复用
• 缺点：学习成本、维护成本
• 适合：流程确实复杂、经常变化

什么时候用：

• 规则经常变（不想每次改代码发版）
• 流程需要配置化
• 有一定复杂度（10+个分支）

什么时候别用：

• 简单的if-else（直接写代码）
• 流程固定不变（没必要配置化）
• 为了"灵活"而牺牲性能

服务编排系：Temporal、Cadence、Conductor

适合场景：

• 微服务编排
• 分布式事务
• 长时间运行的业务流程
• 需要补偿机制

典型例子：

• 订单流程（支付 → 发货 → 签收）
• 旅游预订（机票 + 酒店 + 门票）
• 跨系统流程
• Saga模式

核心特点：

• 支持长时间运行（天级）
• 支持失败重试
• 支持补偿逻辑
• 状态持久化

什么时候用：

• 微服务架构，需要编排多个服务
• 需要分布式事务
• 流程可能运行很久（几小时、几天）

什么时候别用：

• 单体应用（没有跨服务需求）
• 简单的API调用（直接用HTTP就行）
• 实时性要求极高的（毫秒级）

懒得看？直接照这个选

如果你嫌上面内容太多，直接看这个决策树。

跟着问题一步步走，到底了就知道该用什么。

开始
  ↓
主要是人审批吗？
  ↓ 是
  用 Flowable/Camunda（大公司）或钉钉审批（小公司）
  
  ↓ 否
是长时间运行的任务吗（>10分钟）？
  ↓ 是
  用 Airflow/DolphinScheduler
  
  ↓ 否
需要跨系统调用吗？
  ↓ 是
  用 Temporal/Conductor（微服务）或 Airflow（数据处理）
  
  ↓ 否
逻辑很复杂吗（>10个分支）？
  ↓ 是
  用 LiteFlow（编排）或 QLExpress（规则）
  
  ↓ 否
需要频繁修改规则吗？
  ↓ 是
  用 QLExpress/Aviator
  
  ↓ 否
直接写代码！

具体场景怎么选

理论说完了，看几个实际例子。看看你的场景和哪个像。

场景1：请假审批

特征：

• 纯人工审批
• 状态流转
• 需要历史记录

选型：

• 小公司：钉钉/企业微信审批
• 大公司：Flowable/Camunda
• 自己开发：状态机 + 数据库

场景2：电商订单流程

特征：

• 要调支付、库存、物流接口
• 有失败重试和补偿
• 短事务（分钟级）

选型：

• 复杂场景：Temporal/Cadence
• 简单场景：LiteFlow + 消息队列
• 最简单：直接写代码 + 状态机

场景3：数据ETL

特征：

• 纯机器执行
• 长时间运行
• 任务有依赖

选型：

• 标准方案：Airflow/DolphinScheduler
• 简单场景：XXL-Job

场景4：营销活动规则

特征：

• 规则计算
• 经常变化
• 本地方法

选型：

• 简单规则：QLExpress/Aviator
• 复杂规则：Drools
• 有编排需求：LiteFlow

很多人踩过的坑

说几个常见的错误，别重复踩坑。

误区1：追求"企业级架构"

错误做法：
20人的创业公司，上了Flowable、Camunda、Airflow一整套

正确做法：
能用100行代码解决就别上框架

误区2：为了灵活性而牺牲性能

错误做法：
所有逻辑都用Groovy脚本，方便修改

正确做法：
核心逻辑用Java写，只把经常变的部分配置化

误区3：过度抽象

错误做法：
3个简单流程，非要搞个"流程引擎"

正确做法：
3个流程就3个方法，直接写代码

误区4：混淆概念

错误理解：
"我需要流程编排，所以要用Flowable"

正确理解：
先搞清楚你要干活还是改状态
是人审批还是机器执行

几句大实话

最后说几句掏心窝的话。

1. 先用最简单的方案

遇到问题：
第一反应不是"上框架"
而是"能不能写100行代码搞定"

90%的情况，100行代码就够了

2. 遇到瓶颈再优化

流程很乱了 → 重构代码
改动很频繁 → 考虑配置化
管理不过来 → 考虑框架

别提前优化

3. 根据团队规模选择

小团队（<20人）：
- 能不用框架就不用
- 钉钉审批、Cron、直接写代码

中等团队（20-100人）：
- 流程<10个：自己写
- 流程>10个：考虑轻量级框架

大团队（>100人）：
- 需要标准化管理
- 可以考虑成熟框架

4. 看业务特点

强合规（金融、政府）：
- 必须用标准化工具
- Flowable是选择之一

数据密集：
- Airflow是标准方案

微服务架构：
- Temporal值得考虑

简单CRUD：
- 别折腾，写代码

说到底，就这么点事

看完还觉得复杂？那就记住这四个问题：

1. 干活还是改状态？
2. 人为主还是机器为主？
3. 本地方法还是跨系统？
4. 自己玩还是搞生态？

四个问题问完，基本就知道该用什么了。

那些"企业级"、"先进架构"、"灵活扩展"的词，都是包装。

看透本质，别被忽悠。

能用100行代码解决的，就别上框架。

技术是为业务服务的，不是为了炫技。

务实点，别整那些虚的。

就这样。