Activiti、Flowable、Camunda 为什么同宗同源，却走向了三条道路？

一句话回答：Activiti、Flowable、Camunda 共享 Activiti 5 时代的 Java BPMN 引擎血统，但开源项目从来不只由代码决定。维护团队、目标用户、商业模式和目标负载不同，最终让 Activiti 走向“轻量引擎与云组件探索”，Flowable 走向“面向业务自动化的多引擎开源底座”，Camunda 则从开发者友好的 BPM 平台进一步走向以 Zeebe 为核心的分布式流程编排。

它们今天的差异，不是某一次版本升级突然造成的，而是十多年连续选择的结果。理解这段历史，可以解释很多表面上令人困惑的问题：为什么三个引擎都认识 BPMN，却有完全不同的部署方式；为什么 Flowable 更常被国内 OA 和低代码平台用于二次开发；为什么 Camunda 8 不能通过替换 Maven 依赖从 Camunda 7 原地升级；为什么 Activiti 仍然发布新版本，却不再是很多新项目的默认答案。

一、先用一张表看懂三条道路

项目	共同起点之后的关键选择	今天的核心路线	更匹配的企业场景
Activiti	保留轻量 Java 引擎，同时探索 Runtime Bundle、Query、Audit、Connector 等云原生组件	Java BPMN 引擎 + Activiti Cloud 组件化思路	已有 Activiti 资产、需要可嵌入引擎、团队能够自建上层平台
Flowable	由原 Activiti 核心开发者延续引擎，扩大到 BPMN、CMMN、DMN 和事件能力	多引擎业务自动化底座，强调动态流程和 Java/Spring 集成	OA、低代码、政企审批、复杂人工作流和自研流程平台
Camunda	先把 Activiti 分支做成开发者友好的 BPM 平台，随后另起 Zeebe 架构	Camunda 8 分布式流程编排平台	微服务编排、跨语言 Worker、高吞吐流程和需要官方产品支持的企业

截至本文更新时间，Activiti 已发布 9.0.0，并继续维护 8.8.x；Flowable 当前最新大版本为 8.0.0；Camunda 当前稳定主线为 8.9。版本号看起来仍然相近，但三者讨论的已经不是同一种产品边界。

二、共同祖先是谁：从 jBPM 到 Activiti

三者的故事要从 2010 年讲起。Alfresco 在 2010 年 5 月宣布启动 Activiti 项目，并邀请曾参与 jBPM 的 Tom Baeyens、Joram Barrez 等人构建新的 BPMN 2.0 引擎。官方发布材料把它描述为一个从头设计、采用 Apache 许可证、面向 BPMN 2.0 标准的开源平台。

Activiti 早期成功的关键，是把传统重量级 BPMS 拆回一个开发者能够理解和嵌入的 Java 引擎：

• 使用 BPMN 2.0 XML 描述流程；
• 以关系型数据库保存流程定义、执行实例、任务、变量和历史；
• 通过 RepositoryService、RuntimeService、TaskService、HistoryService 等 Java API 操作引擎；
• 可以嵌入 Spring/Java 应用，也可以通过 REST 服务化；
• 依靠 Command、Execution、Job Executor 等内部机制推进流程。

这套设计深刻影响了后来十多年的 Java 工作流生态。今天开发者在 Activiti、Flowable 和 Camunda 7 中看到相似的表结构命名、服务接口、执行树、监听器、表达式和任务模型，并不是巧合，而是共同代码祖先留下的遗传特征。

图 1：三大开源工作流项目的共同起点、两次关键分叉以及 Camunda 8 的再次重构。

同宗同源并不意味着永远兼容。开源项目一旦分叉，每个分支会独立修改数据库结构、包名、内部执行语义、扩展 API 和产品边界。早期迁移可能只是改依赖和少量 API；经过十年演化后，所谓“同源”更多是理解历史的线索，而不是承诺可直接替换。

三、Camunda 为什么在 2013 年首先离开 Activiti

Camunda 是第一次重要分叉。2013 年 3 月，Camunda 官方宣布从 Activiti 项目分离并推出 Camunda BPM。公告写得很直接：团队从 Activiti 项目早期就开始贡献，但希望在自己的领导和产品愿景下全力建设 BPM 平台。

1. 分叉的核心不是代码冲突，而是产品控制权

当时 Activiti 的核心定位仍然偏向可嵌入流程引擎，而 Camunda 已经积累了一批流程咨询和企业客户。它看到的需求不仅是“引擎能否执行 BPMN”，还包括：

• 开发者如何在 Java EE、Spring 和容器中集成引擎；
• 业务与技术人员如何设计和协作维护 BPMN；
• 运维人员如何观察流程实例、变量、失败任务和历史轨迹；
• 企业如何获得稳定版本、迁移工具和商业支持。

因此，Camunda 7 在引擎之外持续建设 Modeler、Cockpit、Tasklist、REST API 和运行容器集成。2013 年发布的 Camunda BPM 7.0 已经把“流程设计、执行、运维和任务管理”作为一套平台，而不是只有一个 Maven 依赖。

2. Camunda 7 如何在共同代码上继续演化

Camunda 后续对 Activiti 时代的执行核心做了大量重构，包括 Activity Instance 模型、流程实例修改、实例迁移、异步连续、历史与持久化处理。Camunda 官方在回顾分叉后的引擎演化时，特别强调了 BPMN 执行语义和持久化层，因为高并发下的死锁、执行树理解和实例迁移都依赖这些底层能力。

这条路线形成了 Camunda 7 的鲜明风格：以开发者为中心，用标准 BPMN 表达业务流程，用平台工具覆盖开发和运维生命周期。

但 Camunda 7 仍然是一套以关系型数据库和 Java 引擎为核心的架构。当微服务、事件驱动和云原生成为主流后，Camunda 判断仅在原引擎上继续优化无法获得想要的水平扩展能力，于是做了第二次更激进的选择。

四、Camunda 为什么又从 Camunda 7 走向 Zeebe 和 Camunda 8

Zeebe 不是 Activiti 引擎的普通升级版，而是重新设计的分布式工作流引擎。Camunda 在 2019 年宣布 Zeebe GA，目标是解决大规模微服务编排中的水平扩展、故障恢复和可观测性问题；2022 年，Zeebe 成为 Camunda 8 的执行核心。

1. 架构目标改变，技术底座就必须改变

传统嵌入式引擎的典型模型是多个应用节点共享关系型数据库。它非常适合 Java 业务系统中的事务型人工作流，但当目标变成每秒处理大量命令、编排跨语言微服务并通过增加节点扩容时，共享数据库很容易成为竞争中心。

Camunda 8 采用另一套模型：

1. 客户端通过 REST 或 gRPC 访问 Gateway；
2. Gateway 将命令路由到 Zeebe Broker；
3. Broker 按 Partition 保存和处理流程实例；
4. 每个分区通过 Raft 复制到多个 Broker；
5. 业务逻辑由引擎外部的 Job Worker 执行；
6. Exporter 把状态变化输出到查询、运维或分析存储。

这意味着 Java Delegate、同 JVM 事务、直接访问引擎数据库等 Camunda 7 常见模式，不再是 Camunda 8 的核心编程方式。官方迁移资料也明确指出，Camunda 8 不是 Camunda 7 的直接替代依赖，迁移需要重新设计代码集成、部署和运维方式。

2. Camunda 选择的是产品化和分布式基础设施道路

Camunda 8 把 Modeler、Operate、Tasklist、Identity、Connectors、Optimize 与 Orchestration Cluster 组合成完整平台。它同时提供 SaaS 与 Self-Managed，但 Self-Managed 生产使用需要核算许可证和更复杂的基础设施成本。

Camunda 7 Community Edition 已在 2025 年 10 月结束生命周期，最终特性版本为 7.24，代码仓库随后归档；企业版支持周期延长到 2030 年。这一生命周期安排进一步说明：Camunda 的资源与未来路线已经明确集中到 Camunda 8。

五、Flowable 为什么在 2016 年成为第二个重要分支

Flowable 的分叉发生在 2016 年 10 月。与 Camunda 不同，Flowable 的发起者正是长期负责 Activiti 核心引擎的开发者。Flowable 官方在分叉公告中表示，团队从 Activiti 项目初期一直负责核心开发，但最终认为只有建立新的分支，才能继续推进自己的技术想法。

第一版 Flowable 5.22.0 直接基于 Activiti 5.21.0。为了降低迁移成本，当时甚至没有立即修改所有 Java 包名和配置文件名，只更换了 Maven groupId 和 artifactId。这也是为什么许多老 Flowable BPMN 文件、扩展属性和代码中仍能看到 activiti 痕迹。

1. Flowable 没有抛弃传统引擎，而是扩大了业务自动化边界

Flowable 选择保留 Java/Spring、关系型数据库和可嵌入引擎的基本模型，同时向更广的业务自动化能力演进：

• BPMN 负责结构化流程；
• CMMN 负责非结构化、事件驱动的案例管理；
• DMN 负责业务规则和决策表；
• Event Registry 负责业务事件抽象与消息系统集成；
• 动态状态变更、流程实例迁移和多实例 API 支持运行中调整。

Flowable 官方总结从 Activiti 分叉后的变化时，列出了原生 CMMN、事件流集成、新一代 BPMN 执行、动态流程注入、异步执行器、数据抽象和数据库结构优化等方向。无论是否接受厂商对自身优势的全部评价，这份清单至少清楚表达了 Flowable 的产品哲学：继续深耕可嵌入 Java 引擎，同时让流程能够处理更多人、规则、事件和非结构化业务。

2. 为什么 Flowable 更容易进入国内 OA 和低代码平台

国内审批系统通常不是纯粹的服务编排，而是组织、表单、权限、人员和流程状态的组合。它们需要：

• 多人会签、按比例通过和一票否决；
• 前加签、后加签、减签、转办和委派；
• 退回上一节点、退回指定节点和撤回；
• 动态选人、部门负责人、岗位和代理规则；
• 与业务表单保持事务一致；
• 在国产数据库、内网和 Java 技术栈中长期运行。

Flowable 的嵌入式部署、Apache 2.0 许可证、动态状态变更与多实例能力，给这类平台提供了相对直接的二次开发底座。当然，引擎 API 仍然不等于完整 OA 功能；权限校验、操作审计、并发控制、变量处理和外部副作用补偿仍必须由平台实现。

六、Activiti 为什么没有沿着另外两个分支继续走

Camunda 和 Flowable 分叉以后，Activiti 并没有停止。它继续维护核心 Java 引擎，并在 Activiti 7 阶段提出 Activiti Cloud。

Activiti Cloud 将能力拆分为多个组件：

• Runtime Bundle：运行不可变流程定义并提供流程与任务运行时；
• Query Service：消费事件并建立面向查询的数据模型；
• Audit Service：汇聚多个运行时的审计事件；
• Cloud Connector：通过消息执行系统集成；
• Notification Service：提供订阅和状态推送。

这些组件使用 Spring Boot、Spring Cloud Stream、消息代理、容器和 Kubernetes，体现了 Activiti 对云原生、事件驱动和读写分离的探索。它与 Camunda 8 的相似之处是都试图突破单体嵌入式引擎边界；区别在于，Activiti Cloud 仍以 Runtime Bundle 中的传统流程引擎为核心，而 Camunda 8 重新设计了 Zeebe 的分区日志、复制和 Worker 模型。

1. Activiti 今天仍在更新，但路线表达不够集中

2026 年 3 月发布的 Activiti 9.0.0 将 Java 基线升级到 Java 25；2026 年 7 月发布的 8.8.1 则继续修复 Oracle、PostgreSQL 和任务查询问题。这说明 Activiti 仍有代码维护。

但企业评估时也会看到现实挑战：

• Activiti Cloud 的公开文档主要形成于 Activiti 7 阶段；
• 核心引擎、Cloud 组件、示例和部署资料分布在多个仓库；
• 最新 Java 基线可能领先于很多企业的 Java 17/21 运行环境；
• 完整的建模、门户、任务中心和运维体验通常需要自行建设。

所以 Activiti 今天更像一个需要团队主动整合的技术资产。对于已有 Activiti 系统，这是可控和熟悉的延续；对于新项目，则必须拿它与 Flowable 的扩展能力、Camunda 8 的产品体系进行更严格的 PoC。

七、三条道路的架构差异是怎样形成的

图 2：共同的 Java BPMN 引擎基因，在不同目标负载和产品边界下演化成三类架构。

从源码和部署形态看，三条道路可以概括为：

1. Activiti：轻量核心与云组件并存

Activiti 保留经典 Java 引擎服务和关系型数据库模型，同时通过 Runtime Bundle、Query、Audit、Connector 探索组件化。它的优势是历史资产多、嵌入简单、Apache 2.0 许可宽松；挑战是企业需要自行判断核心引擎与云组件的成熟度和组合方式。

2. Flowable：一个共享服务体系下的多引擎

Flowable 把 BPMN、CMMN、DMN、事件注册表以及身份、任务、变量、作业等共享服务组织在一起。它仍然可以嵌入 Spring 应用并使用关系型数据库，又能够通过 REST、事件和外部 Worker 扩展。这种“增强传统引擎而不是推翻传统引擎”的路线，降低了 Java 企业应用的采用门槛。

3. Camunda 8：以分布式日志为核心的流程编排集群

Camunda 8 的 Broker 不执行企业业务代码，而是保存流程状态、处理命令并分配 Job。每个流程实例归属一个 Partition，Raft 负责复制和领导者切换，Worker 可以使用不同语言独立部署。它牺牲了传统嵌入式事务的直接性，换取分区扩展、故障隔离和跨语言编排能力。

八、为什么“同源”没有阻止 API、数据库和生态分化

开源分叉之后，真正拉开距离的是每天发生的小决定。

1. 治理权决定什么问题优先解决

维护团队决定 Roadmap、合并标准、发布节奏和兼容策略。Camunda 会优先解决产品客户的大规模编排和运维问题；Flowable 会优先增强业务自动化、多引擎和动态流程；Activiti 的路线则受到其项目治理、内容服务背景和云组件规划影响。

2. 目标用户决定产品边界

面向引擎开发者，只需要稳定 API 和数据库；面向企业流程团队，则需要建模、任务中心、权限和监控；面向跨语言微服务，则需要网络协议、Worker SDK、分区和弹性。三种用户期待的是三种不同产品。

3. 商业模式决定哪些能力进入开源核心

Flowable 开源引擎与商业产品之间存在边界；Camunda 8 的源代码可见范围、Apache 组件和生产许可证需要分别理解；Activiti 核心使用 Apache 2.0，但企业级上层能力主要依赖自行建设。企业不能只看 GitHub 仓库是否公开，还要逐组件检查许可证、生产用途和支持条款。

4. 向后兼容决定重构速度

维护大量旧流程、数据库和扩展会限制底层重构。Flowable 选择尽量延续 Java 引擎兼容性并逐步演进；Camunda 通过 Zeebe 开辟新架构，接受迁移不是原地升级；Activiti 同时维护不同版本线，也需要在新 Java 基线和旧企业环境之间权衡。

图 3：代码只是起点，治理、用户、商业和技术目标共同决定项目最终道路。

九、从源码仓库看，三者今天分别在建设什么

1. 看 Activiti：重点检查版本线和组件一致性

源码评审不应只打开 activiti-engine。还要核对 Spring Boot Starter、API 模块、Cloud Runtime Bundle、Query、Audit、Connector、Helm Chart 与示例项目的版本关系。企业最需要确认的是：

• Java 25 是否符合基础设施基线；
• 8.8.x 与 9.x 的维护和升级策略；
• Cloud 文档与最新代码是否一致；
• 自定义命令、监听器和数据库适配能否长期维护。

2. 看 Flowable：重点检查共享服务和扩展 API

Flowable 仓库包含 BPMN、CMMN、DMN、Event Registry、Job、Task、Variable 等大量模块。不要被模块数量吓住，应沿着真实业务链路检查：

1. BPMN 模型如何解析为运行时对象；
2. Command 和事务如何修改 Execution；
3. 多实例与 ChangeActivityStateBuilder 如何处理运行中变更；
4. Async Executor 如何获取、锁定、重试和转移作业；
5. 历史表、索引和清理如何影响查询。

Flowable 8.0.0 已升级到 Spring Framework 7、Spring Boot 4 和 Jackson 3。这不是路线改变，而是 Java 生态基线升级；但对企业而言，同样需要完整的兼容测试。

3. 看 Camunda：必须把 Camunda 7 与 Camunda 8 分开

Camunda 7 的源码阅读重点仍是 Java Process Engine、Command、Execution、Job Executor 和关系型数据库。Camunda 8 则要阅读 Gateway、Broker、Partition、Raft、Stream Processor、RocksDB 状态以及 Exporter。

如果把 Camunda 7 的经验直接套到 Camunda 8，会产生错误判断。例如：

• 业务逻辑不再默认运行在引擎 JVM 内；
• 不应通过数据库表直接查询和修改运行状态；
• 扩容单位不只是应用节点，还包括 Partition、Broker 和 Gateway；
• 重试、幂等与补偿主要落在 Worker 和业务服务边界；
• 运维查询存储与主执行存储是两套责任。

十、三条道路对私有化部署意味着什么

维度	Activiti	Flowable	Camunda 8
最小部署	可嵌入单个 Java 应用	可嵌入 Java 应用或独立 REST 服务	Orchestration Cluster 及相关平台组件
核心持久化	关系型数据库	关系型数据库为主	Partition 日志、Raft、RocksDB；另有二级存储
业务代码位置	引擎内 Delegate/Listener 或外部集成	引擎内 Delegate/Listener、事件或外部 Worker	引擎外部 Job Worker
横向扩展方式	多节点共享数据库，Cloud 组件可独立扩展	多节点共享数据库，异步执行器协同	Broker 分区与复制，Gateway 和 Worker 独立扩展
生产许可	Apache 2.0	Apache 2.0	Self-Managed 生产许可证需单独核算
企业主要投入	自建平台、文档整合和版本维护	中国式审批、上层产品与数据库适配	集群运维、许可证、Worker 治理和迁移

这张表也解释了为什么“哪个性能最好”是一个不完整问题。嵌入式引擎可以用更少组件完成中等规模 OA 审批；分布式引擎可以处理更高吞吐和跨语言编排，但会增加网络、存储、集群和授权成本。架构必须与负载匹配。

十一、中国式工作流为什么通常要在引擎之上再做一层

Activiti、Flowable、Camunda 都执行 BPMN，但 BPMN 标准没有完整定义中国 OA 里的加签、减签、退回、撤回、转办、代理和审批意见。不同平台对同一个词甚至有不同语义。

例如“退回”至少需要回答：

• 退回上一实际办理节点，还是流程图中的上一节点？
• 并行会签中已经完成的其他分支是否撤销？
• 重新提交后走原路径，还是重新计算条件？
• 已发送的消息和已经调用的外部系统如何补偿？
• 历史轨迹如何区分正常流转与管理员干预？
  

这类能力应该由独立流程服务层封装，而不是让业务模块直接修改引擎表。云程低代码开发平台采用的也是这种思路：以 BPMN.js 和工作流引擎承接标准执行，在上层组合电子表单、组织角色、流程门户、待办中心、监控分析，并通过受控流程命令实现会签、加签、回退、跳转、撤销和委托。这样既能利用开源引擎，也能把中国特色的审批语义固化为可配置、可审计的平台能力。

选择底层引擎时，应重点判断它能否支撑这层适配，而不是期待引擎直接变成完整 OA。

十二、企业应该如何从项目历史反推技术选型

项目历史不是八卦，它是预测未来维护成本的证据。

1. 如果企业已有 Activiti

先盘点流程定义、数据库规模、内部命令、自定义行为和上层平台能力。如果系统稳定且业务增长可控，继续维护通常比为了品牌更换引擎更经济。若准备大规模重构，则把 Flowable 作为相近路线、Camunda 8 作为架构重建路线分别评估。

2. 如果企业新建 OA 或低代码审批平台

优先用真实的会签、加签、回退、撤销、并行网关和子流程用例评估 Flowable。它的路线与 Java 企业应用和复杂人工作流更接近，但仍要自行建设表单、组织、门户、权限、消息和审计。

3. 如果企业建设跨系统流程编排基础设施

评估 Camunda 8 的 Partition 数量、复制因子、Worker SDK、Operate、备份恢复、二级存储和生产许可证。不要只比较 BPMN 元素数量，要验证故障恢复、积压处理、幂等和跨语言运维。

4. 如果企业最看重完全开放和内部可控

不仅要看许可证名称，还要确认团队能否长期维护分支。真正的自主可控包括构建、漏洞修复、数据库适配、升级测试、文档和人才，而不是把源代码下载到内网就结束。

十三、如果只记住六句话

1. 三者同宗同源，是因为 Camunda 7 和 Flowable 都从 Activiti 时代代码分叉；Camunda 8 则已经是 Zeebe 架构。
2. Camunda 2013 年分叉的核心，是希望掌握开发者 BPM 平台的产品方向；后来又为分布式编排重建执行核心。
3. Flowable 2016 年由原 Activiti 核心开发者创建，选择继续深耕 Java 引擎并扩展 BPMN、CMMN、DMN 和事件能力。
4. Activiti 没有消失，它保留轻量引擎并探索 Activiti Cloud，但企业需要更主动地整合版本、组件和文档。
5. 开源项目的方向由治理、目标用户、商业模式和兼容包袱共同决定，代码血缘只能解释起点。
6. 企业选型应看未来五年的流程类型和维护模型：OA 审批、复杂业务自动化与大规模服务编排需要不同底座。

三条道路没有绝对高下。Flowable 不是“更新的 Activiti”，Camunda 8 也不是“更强的 Activiti”。它们是在不同约束下对流程自动化做出的不同回答。真正成熟的企业架构，不会因为历史同源就假设可以随意替换，也不会因为架构新就忽略许可证、团队和业务复杂度。