为什么在 Flowable 时代还要写一个轻量工作流引擎

jeeflow 系列 · 第 1 篇（认识季）

后端群里几乎每周都有人问同一个问题："审批流用什么？"

回答也总是同一个：Flowable。

但很少有人追问后半句------选型完成之后，故事才刚开始：一个 jar 数 MB、依赖一大堆、表几十张的引擎，进到你的业务系统里，是"引入了一个能力"，还是"引入了一个麻烦"？

这篇不劝退 Flowable，也不吹自研。我们把账算清楚：Flowable / Activiti / Camunda 这些成熟引擎，到底贵在哪？什么场景下，一个 98KB 的轻量引擎反而是更理性的选择？

本系列由 mldong 快速开发框架生态延续而来，第 0 篇《从 mldong 到 jeeflow：一个工作流引擎的独立进化》讲了 jeeflow 的完整来龙去脉，欢迎先看那篇。

一、成熟引擎的代价，藏在哪里

Flowable、Activiti、Camunda 都是 BPMN 2.0 标准的优秀实现，功能强大毋庸置疑。但"强大"是有标价的，这笔账通常要在上线后慢慢还：

1. 引擎本身就不轻。 Flowable 引擎 jar 数 MB，加上流程定义解析、表单、历史等模块，跑起来的内存和启动时间都不是小数目。Camunda 如果是平台版，更是一整套东西。

2. 数据表几十张起步。 Flowable 光引擎表就有 70+ 张（ACT_ 前缀），Activiti 60 张上下，Camunda 也 30 张左右。你的数据库 schema 里瞬间多出一片"别人家的表"，迁移、备份、监控都要跟着适配。

3. 学习曲线不是"陡"，是"长"。 BPMN 2.0 本身就是一个完整的规范：泳道、子流程、事件、网关、边界事件......新同学入职先啃一个月 BPMN 文档，才能动手画第一个"请假流程"。

4. 深度集成是你的活。 用户体系要映射、权限要对接、事务要配合、前端流程设计器要集成。引擎是别人的，胶水代码是你的。

5. 升级是心理阴影。 大版本升级意味着 API 变动、表结构迁移、历史数据兼容------很多团队干脆"引擎版本永不升级"。

这些都不是 Flowable 的错------它只是为一个更宏大的目标（复杂 BPM 平台）而生的 。问题在于：如果你的需求只是"业务系统里有一块审批能力"，用它就属于用火箭送外卖。

二、那什么时候才该自研？

先把结论放前面：自研不是省事，是换一种成本结构。

适合用成熟引擎的场景：

你要做的是流程平台本身（面向多租户、复杂编排、流程市场）
业务流程重度依赖 BPMN 高级特性（事件、网关、复杂补偿）
团队有专门的 BPM 工程师，养得起这个复杂度

适合轻量自研的场景（我们的判断）：

审批流是业务系统的一个模块，不是产品的全部
流程模式相对固定：发起、审批、退回、跳转、会签、抄送、委托
希望引擎与自家框架深度集成（事务、权限、用户体系、前端设计器）
希望引擎行为完全可控，出问题能快速定位
未来可能有多语言技术栈的业务团队接入（Java / Go / Python / Node）

自研的代价也要讲清楚：功能边界要自己守（不做复杂 BPM 就是不做）、测试体系要自己建、维护责任自己扛。自研引擎不是"免费"，是把成本从"学习别人的复杂度"转移到"维护自己的复杂度"。 只有当后者的复杂度显著低于前者时，才划算。

三、一张表看清选型

维度	Flowable	Activiti	Camunda	jeeflow
定位	BPM 引擎	BPM 引擎	流程平台	业务系统内嵌审批引擎
引擎体积	数 MB	数 MB	平台级	98KB
数据表	70+ 张	60 张上下	30 张上下	8 张（5 核心 + 3 管理）
流程标准	BPMN 2.0	BPMN 2.0	BPMN 2.0	LogicFlow JSON
框架依赖	需集成 Spring 等	同左	平台绑定	零依赖（仅 slf4j-api，provided）
学习曲线	陡（BPMN 规范）	陡	陡	平（JSON + 节点/边）
扩展方式	Handler / Listener	同左	平台扩展点	SPI 体系（核心 6 + 扩展 5，任意环节可替换）
语言覆盖	Java 为主	Java	Java	Java / Go / Python / Node 四语言
事务/权限集成	自己接	自己接	平台提供	引擎不感知，业务层事务模板包裹

注：表数量为各引擎常见版本的大致规模（Flowable 6.x 的 ACT_ 系列约 70 余张），供量级参考；精确数字以各引擎官方文档为准。jeeflow 数据对齐 v1.8.4（8 张表 = 5 核心 + 设计/历史/委托 3 管理）。

四、我们的选择：mldong 场景下的自研

mldong 快速开发框架（开源在 Gitee 的 Java 快速开发框架）里内置了一套自研工作流引擎，当初做这个决定时，就是照着上面的判断来的：

需求边界清晰：框架要的是"业务系统里的审批能力"，不是流程平台------发起、审批、退回、跳转、会签、抄送、委托，够用且好用；
流程定义用 LogicFlow JSON：节点 + 边 + 表达式，可视化设计器画完就是这份 JSON，没有 BPMN 的规范负担；
与框架深度集成：接口契约（code=0/msg、submitType 枚举）、用户体系、前端 vben5 流程设计器，全部对齐；
Java 双主线（boot2 / boot3）的 wf 模块完全一致，前端开箱即用。

引擎在框架里跑得很好。但后来我们发现，这套能力值得独立出去------于是有了 jeeflow：一个 98KB、零框架依赖、DDD 设计、SPI 体系可插拔的工作流引擎 SDK，并演进出了 Java / Go / Python / Node 四语言同构的"多语言联邦"。这是第 0 篇讲过的故事。

五、结语：选型没有银弹，只有匹配

Flowable 很好，但它是为"复杂 BPM"生的。如果你的系统里只是需要"审批"，请先算清楚那几十张表、数 MB 依赖和 BPMN 学习成本，是不是你想要的。 轻量自研也不是银弹，它是把复杂度换了个位置------换来的是可控、可移植、可掌控。

下一篇预告：《jeeflow：98KB 的工作流引擎长什么样》------一个零依赖引擎的核心设计：DDD 聚合根、6 大 SPI、状态机、9 种流程模式，拆开给你看。