开源工作流引擎 Activiti、Flowable、Camunda 到底怎么选？从源码、功能和生态全面对比

如果只给一个结论：新建传统 Java 审批平台、强调 Apache 2.0、国产数据库适配和会签/加签/回退等深度定制，优先评估 Flowable；已有 Activiti 资产且团队能长期维护内核，可以继续演进，但不建议仅凭“历史知名度”用于全新项目；需要高吞吐分布式编排、跨语言 Worker、成熟运维界面和商业支持，并能接受生产许可证与更高运维成本，评估 Camunda 8。Camunda 7 社区版已经结束生命周期，不应再作为新项目基线。

真正的选型对象也不只是三个流程引擎。企业最终要建设的是“流程平台”：底层引擎之上还要有组织权限、动态选人、表单、流程版本、消息通知、审计、监控、移动端以及中国特色的审批操作。引擎决定技术上限和改造成本，平台层决定业务人员能不能真正使用。

一张表先看懂：三者适合什么企业

选型维度	Activiti	Flowable	Camunda 8
当前版本观察	9.0.0 于 2026-03-05 发布，升级到 Java 25；8.8.1 于 2026-07-14 发布维护修复	8.0.0 于 2026-02-27 发布	当前稳定线 8.9，8.9.13 于 2026-07-15 发布；8.10 尚处 Alpha
核心定位	轻量 Java BPMN 引擎及 Activiti Cloud 组件	Java BPMN/CMMN/DMN 与事件能力组合	基于 Zeebe 的分布式流程编排平台
生产许可	Apache 2.0	Apache 2.0	8.6 起生产使用需要 Camunda Self-Managed 生产许可证
典型部署	嵌入 Spring 应用或自行服务化	嵌入 Spring 应用、独立 REST 服务、关系型数据库集群	Self-Managed，生产优先 Kubernetes/Helm，也支持手工部署
二次开发	自由度高，但资料与产品化组件需要团队补齐	动态状态变更和多实例 API 较适合中国式审批扩展	API、运维和跨语言 Worker 体系完整，但底层模型与传统嵌入式引擎不同
开箱即用管理界面	开源引擎层较弱，通常自建	开源引擎与商业产品边界要分清，私有化 OSS 常需自建	Modeler、Operate、Tasklist 等体系完整，生产授权需计入预算
最适合	已有 Activiti 技术资产、重视平滑维护的团队	OA、低代码、政企审批、复杂人工作流平台	大规模服务编排、跨语言微服务、重视官方产品与支持的企业
主要风险	文档与版本线不够统一；Java 25 基线可能领先企业现状	8.0 对 Spring 7、Spring Boot 4、Jackson 3 的升级影响较大	生产许可、集群资源、运维栈与迁移成本更高

这里必须强调一个常见误区：GitHub Star、历史文章数量和“某某大厂使用过”只能说明项目影响力，不能直接回答你的系统能否在内网运行、能否适配组织权限、能否稳定实现加签回退，也不能替代许可证审查和压力测试。

先分清四个产品：Camunda 7 不等于 Camunda 8

Activiti、Flowable 和 Camunda 7 都属于开发者熟悉的 Java 嵌入式流程引擎路线：流程引擎可以和业务应用运行在同一个 JVM 中，通过 RepositoryService、RuntimeService、TaskService、HistoryService 等服务访问部署、实例、任务和历史数据，运行状态主要保存到关系型数据库。

Camunda 8 则是另一条路线。它的执行核心是 Zeebe，客户端通过 REST 或 gRPC 访问 Gateway，Broker 负责持久化和推进流程状态，业务代码以 Job Worker 方式在引擎外部执行。Broker 可按分区横向扩展，并通过复制实现容错。官方架构把核心组件概括为 Clients、Gateways、Brokers 和 Exporters。

图 1：传统嵌入式关系型数据库引擎与 Camunda 8 分布式编排架构的核心差异。

这意味着：

• 如果你希望把引擎作为一个 JAR 嵌入现有 Spring Boot 单体或模块化系统，Activiti、Flowable 的心智模型更直接。
• 如果你希望流程引擎成为独立的分布式编排基础设施，让 Java、Go、Node.js 等服务通过 Worker 协同，Camunda 8 的边界更清晰。
• 如果现有系统使用 Camunda 7，不能把升级依赖版本理解成“原地升级到 Camunda 8”。流程模型兼容、Java Delegate 改造、变量格式、历史数据和运维体系都需要单独迁移计划。

Camunda 官方已经将 camunda-bpm-platform 仓库归档，并明确 Camunda 7 Community Edition 已结束生命周期；企业版进入长期支持阶段。对于新项目，这一事实比历史上 Camunda 7 的功能成熟度更重要。

从最新源码和发布节奏看，三个项目处于什么状态

Activiti：代码仍在更新，但需要识别版本线与文档落差

Activiti 官方仓库仍然活跃，采用 Apache 2.0 许可证。9.0.0 的主要变化之一是将 Java 基线升级到 Java 25；与此同时，8.8.1 仍在维护，包含 Oracle、PostgreSQL 和任务查询相关修复。对企业选型来说，这说明项目并非“停止更新”，但也带来两个问题。

第一，Java 25 对很多政企内网环境并不现实。企业可能仍以 Java 17 或 Java 21 为统一基线，基础镜像、APM、国产中间件和安全扫描工具未必已经完成验证。选择 Activiti 9 之前，要先检查完整依赖树和运行环境，不要只验证 Demo 能启动。

第二，Activiti Cloud 的公开开发文档主要围绕 Runtime Bundle、Query、Audit、Connector、Notification 等组件展开，很多页面仍标注为 Activiti 7 时代内容。Runtime Bundle 采用不可变流程定义、同步 REST 与异步消息 API，并依赖数据库、消息代理和 SSO/IDM。这套思路有参考价值，但企业需要自己验证当前源码、Starter、Helm Chart 与文档是否一致。

因此，Activiti 更适合以下情况：

• 已有大量 Activiti 5/6/7 流程模型和扩展代码，希望控制迁移范围。
• 团队熟悉 Command、Agenda、Execution、Task 等内部机制，能自行修补和维护。
• 只需要轻量引擎，不期待开源项目直接提供完整的流程门户和运维工作台。
• 能建立自己的版本冻结、漏洞修复、回归测试和文档体系。

对于完全从零开始的企业平台，Activiti 不是不能选，而是必须回答：“它相对 Flowable 能给我们带来什么不可替代的收益？”如果答案只是团队听说得更早，就不够充分。

Flowable：最接近中国式审批平台的二次开发底座

Flowable 8.0.0 继续采用 Apache 2.0 许可证，核心覆盖 BPMN 流程、CMMN 案例、DMN 规则和 Event Registry。它可以嵌入 Java 应用，也可以作为服务运行，并提供 Java API 和 REST API。

Flowable 对国内 OA 和低代码平台最有吸引力的地方，不是“流程图能画出来”，而是运行时状态变更 API 较丰富。Flowable 8 的 ChangeActivityStateBuilder 提供：

• 将一个 Execution 移动到指定活动；
• 将多个并行 Execution 汇聚到一个活动；
• 将一个 Execution 拆分到多个活动；
• 按当前活动 ID 移动到目标活动。

RuntimeService 还提供多实例 Execution 的动态增删能力。这些 API 不能直接等同于“加签”“退回”，但它们为实现中国式审批语义提供了相对清晰的底层积木。

Flowable 8 的升级也不能轻视。官方发布说明明确列出了 Spring Framework 7、Spring Boot 4 和 Jackson 3 的升级，并移除 JUnit 3/4 支持。对于准备从 Flowable 6 或 7 升级的项目，应重点回归：

• Spring Boot 自动配置与事务边界；
• Jackson 2 到 Jackson 3 的 JSON 变量兼容；
• 脚本和表达式中对 JsonNode 方法的调用；
• 历史表数据量、索引和清理策略；
• 自定义 SQL、数据库方言和国产数据库兼容层；
• 自定义行为、监听器和引擎内部类引用。

如果企业希望完全基于开源版本建设平台，还要分清“Flowable 开源引擎”和“Flowable 商业低代码产品”。流程设计协作、统一任务中心、内容管理、细粒度权限、分析看板等完整体验，不应在选型表里默认算作开源引擎的开箱功能。

Camunda 8：架构、产品和商业支持更完整，但不是免费生产方案

截至资料更新时间，Camunda 当前稳定主线为 8.9，8.9.13 是 2026 年 7 月的补丁版本。Camunda 8 的优势主要体现在：

• Zeebe Broker 的分区、复制和水平扩展；
• REST/gRPC API 与跨语言 Job Worker；
• Operate 的流程实例监控、故障处理、迁移和修改；
• Tasklist、Modeler、Identity、Connectors、Optimize 等产品组合；
• Kubernetes、Helm 和主流云平台参考架构；
• 官方支持、培训和升级路线。

Camunda 8.8 起将 Broker、Gateway、Operate、Tasklist 和 Identity/Admin 收敛为 Orchestration Cluster。8.9 又把关系型数据库作为二级存储的一等选项，支持 PostgreSQL、Oracle、MariaDB、MySQL、SQL Server 和 Aurora PostgreSQL 等；但 Zeebe 的主执行存储仍是 Raft + RocksDB。它缓解了必须运维 Elasticsearch/OpenSearch 的问题，却没有把 Camunda 8 变成传统关系型数据库嵌入式引擎。

许可证是私有化选型的硬门槛。Camunda 8.6 起，Zeebe、Operate、Tasklist、Identity、Optimize 等 Self-Managed 组件虽然可以查看源代码并用于开发测试，但生产使用需要有效的生产许可证。Web Modeler 在无企业许可证时也有非生产和并发用户限制。采购、法务和技术团队应在 PoC 开始时就确认许可，不要等上线前才发现预算模型不成立。

源码层面应该看什么，而不是只看 API 数量

企业评审源码时，建议建立四张清单。

1. 扩展点清单

检查引擎是否提供稳定的监听器、命令拦截器、变量类型、身份解析、任务分配、历史事件、作业执行器和解析器扩展点。还要区分“公开 API”与“内部实现类”：基于内部类实现回退很快，但每次升级都可能付出高额兼容成本。

2. 状态一致性清单

流程操作不是简单更新当前节点字段。并行网关、包容网关、子流程、边界事件、补偿事件和多实例任务会同时存在多个 Token。任何跳转或回退都要回答：

• 需要取消哪些 Execution 和 Job？
• 是否会遗留定时器、消息订阅或边界事件？
• 并行汇聚网关还能否满足到达条件？
• 历史轨迹如何表达“正常流转”和“人工干预”？
• 外部系统已经执行的动作是否需要补偿？

3. 数据与升级清单

需要核对数据库建表脚本、索引、字段长度、字符集、批量历史清理和滚动升级能力。引擎能支持 MySQL 或 Oracle，不代表企业封装的平台已经支持达梦、人大金仓或 OceanBase。数据库适配必须通过真实流程、并发任务、长变量和历史查询压测验证。

4. 社区与维护清单

不要只统计 Star。应观察最近稳定版、补丁频率、安全公告、Issue 响应、文档更新时间、升级指南、测试覆盖和维护者集中度。企业还要评估：如果上游项目半年不发布补丁，内部团队是否有能力维护自己的分支？

企业私有化部署，成本差异到底在哪里

图 2：从许可证、架构形态、业务类型和团队能力出发的工作流引擎选型流程。

Activiti 与 Flowable：部署简单不等于平台运维简单

嵌入式引擎可以与业务应用共享数据源和事务，部署单元少，适合内网、单体或模块化系统。但企业仍要自行建设：

• 数据库高可用、备份恢复和历史数据归档；
• 异步 Job Executor 的容量、重试、死信与告警；
• 流程定义灰度发布和实例迁移；
• 多租户隔离、组织权限和数据权限；
• 流程操作审计、管理后台和可观测性；
• 设计器、表单、门户、待办中心和移动端。

当实例规模上升时，多个引擎节点共享数据库，吞吐瓶颈往往转移到数据库锁、索引、历史表和异步任务获取策略上。因此，PoC 应使用真实流程结构和数据量，而不是只跑一条串行请假流程。

Camunda 8：更强的分布式能力对应更高的基础设施要求

Camunda 官方把 Kubernetes + Helm 作为 Self-Managed 生产部署的推荐方式，并建议通过多可用区、私网、Ingress/Load Balancer、持久卷和外部数据库等方式构建高可用架构。Orchestration Cluster 中包含有状态的 Broker，分区数、复制因子、磁盘性能、快照、备份和二级存储都需要容量规划。

Camunda 8.9 支持手工安装和 RDBMS 二级存储，为不希望引入完整 Kubernetes/Elastic 技术栈的企业提供了更多选择。但从运维责任看，Self-Managed 仍意味着企业自行负责部署、扩缩容、安全、升级和整套组件维护。

因此，私有化部署成本至少要核算：

1. 商业许可证和技术支持；
2. Kubernetes/VM、数据库、搜索存储和持久卷资源；
3. 身份认证、证书、密钥和网络隔离；
4. 监控、日志、备份、恢复演练和灾备；
5. 版本升级、兼容测试和数据迁移；
6. 业务 Worker 的部署、重试、幂等与补偿。

如果企业每天只有几万条人工作流任务，却为“未来高并发”部署一套复杂分布式编排集群，可能是在用运维成本购买暂时用不到的能力。反过来，如果核心场景是每秒大量服务编排、跨语言 Worker 和长时间运行的事件驱动流程，仅靠共享数据库扩容也可能很快触顶。

会签、加签、回退、跳转、撤销，哪个引擎开箱即用

严格来说，这些词大多是中国 OA 语境的业务能力，不是 BPMN 2.0 标准中的完整产品功能。BPMN 提供多实例、网关、事件、补偿等执行语义，但“谁能加签、可以退回到哪里、撤回后意见如何保留”属于平台规则。

业务操作	引擎层可复用能力	平台层必须补齐的规则
会签	BPMN 多实例、顺序/并行执行、完成条件	通过比例、一票否决、同意权重、重复人员、动态人员变化
加签	动态创建多实例 Execution、流程实例修改或自定义命令	前加签/后加签、加签人权限、原任务是否保留、消息与审计
减签	删除尚未完成的多实例 Execution	禁止删除已审批人员、最低人数、并发冲突、意见保留
回退	状态变更、取消当前 Token、激活历史节点	可退节点计算、并行分支处理、变量回滚、重新提交路径
跳转	流程实例修改或动态状态变更	目标节点白名单、执行人重算、事件与定时器清理
撤销/撤回	取消下游活动并重新激活提交节点	时间窗口、下游是否已办理、外部副作用补偿、幂等
转办/委派	Assignee、Owner、DelegationState、任务 API	转办与委派语义区分、代理范围、组织权限、日志

Flowable 的动态状态变更和多实例 API 给平台开发提供了较直接的实现基础。Activiti 与传统 Camunda 7 也能通过命令模式和内部执行树完成类似扩展，但应避免把内部表更新当成正式方案。Camunda 8 提供流程实例修改和迁移能力，适合运维修复与版本迁移；将其直接包装成无限制的业务回退仍然危险，因为活跃元素类型、并发状态和映射都存在约束。

图 3：会签、加签、回退等能力需要由 BPMN 引擎、流程服务层和低代码应用层共同完成。

一个可上线的实现至少包含以下保护：

• 操作前校验任务版本或乐观锁，避免用户重复点击；
• 把“业务操作类型”与引擎底层命令分开建模；
• 保存操作人、原节点、目标节点、原因、意见和附件；
• 对消息通知、业务回写和外部接口采用 Outbox 或可靠事件；
• 为并行、多实例、子流程和边界事件建立回归用例；
• 高风险跳转只对管理员开放，并提供预演结果；
• 撤销外部副作用时使用补偿动作，而不是幻想数据库回滚能撤回已发送短信或已完成付款。

界面能力也要纳入选型：运维人员如何修复流程

Camunda 8 的一个明显优势是 Operate 提供流程实例观察、故障处理、修改和迁移界面。下面是官方文档中的流程实例迁移界面示例：上方同时展示源流程和目标流程，下方配置节点映射。这个设计值得任何自研工作流平台参考，因为高风险操作必须让管理员看清影响范围，而不是只提供一个“跳转”按钮。

图 4：Camunda 8 Operate 流程实例迁移界面示例。图片来源：Camunda 官方 8.8 文档；当前版本能力判断以 8.9 文档为准。

Activiti、Flowable 也能在 API 层完成很多管理动作，但如果企业选择纯开源引擎，就要把界面建设成本纳入预算。至少要有流程定义管理、实例轨迹、变量查看、任务干预、异步作业、异常告警、操作审计和实例迁移工具。

什么时候应该选择 Activiti

以下条件同时满足时，Activiti 仍是合理选择：

• 企业已经有稳定运行的 Activiti 系统和大量自定义扩展；
• 迁移到其他引擎的业务回归成本远高于继续维护；
• 团队愿意维护内部发行版，而不是频繁追随上游最新版本；
• 平台本身已经具备设计器、表单、权限、门户和监控能力；
• 能接受公开文档与最新代码之间需要自行核对。

对于新项目，建议先用同一组流程对 Activiti 与 Flowable 做源码级 PoC，重点比较升级基线、动态状态变更、历史查询、数据库适配和团队熟悉度。若没有明确优势，Flowable 通常是更稳妥的二次开发起点。

什么时候应该选择 Flowable

以下场景优先评估 Flowable：

• 以请假、报销、采购、合同、用印、项目立项等人工作流为主；
• 需要会签、加签、减签、退回、撤回、转办和代理；
• 希望使用 Apache 2.0，在内网长期私有化运行；
• 需要 BPMN、DMN、CMMN 或事件能力组合；
• 技术栈以 Java/Spring 和关系型数据库为主；
• 企业愿意自行建设或采购上层流程平台。

对保守型企业，Flowable 8 不一定要在第一天就采用。可以同时评估仍受维护的 7.x 或既有稳定版本，但必须基于安全补丁、JDK 生命周期和未来升级路线做决定，不能长期冻结而没有维护计划。

什么时候应该选择 Camunda 8

以下场景更适合 Camunda 8：

• 流程主要编排微服务、消息、设备或跨系统任务；
• 需要跨语言 Worker，而不是把所有逻辑写进 Java Delegate；
• 实例量和吞吐需要通过分区横向扩展；
• 企业需要较成熟的 Modeler、Operate、Tasklist 和官方支持；
• 已经具备 Kubernetes、SRE、可观测性和灾备能力；
• 可以接受生产许可证和相应采购流程。

如果只是为了画 BPMN 图和做 OA 审批，Camunda 8 可能过重；如果企业的流程已经成为跨域服务编排骨干，它的架构投入则可能物有所值。

低代码平台为什么不能只“集成一个引擎”

在真实项目中，业务用户关心的不是 RuntimeService 还是 Zeebe Partition，而是能否拖拽设计审批、绑定表单、按部门岗位选人、查看待办、移动审批和审计追溯。

云程低代码开发平台的工作流模块体现了这类工程化思路：以 BPMN.js 设计器和流程引擎为基础，在上层组合电子表单、组织与角色、流程门户、待办中心、流程监控和分析，并通过独立的流程操作服务承接加签、减签、跳转、退回、撤销、委托等业务动作。这样做的价值不在于“替代开源引擎”，而是把开源引擎没有定义的中国式审批语义固化为可配置、可审计、可复用的平台能力。

对企业而言，理想架构是把引擎隔离在适配层之后：

• 流程模型使用尽可能标准的 BPMN；
• 业务系统只调用统一的流程服务 API；
• 组织、表单、消息、附件和审计不直接依赖引擎内部表；
• 引擎特有的动态跳转、迁移和多实例操作封装为受控命令；
• 通过契约测试保证未来更换版本或引擎时，业务语义不漂移。

这比让每个业务模块直接调用引擎 API 更有利于长期演进。

一套可执行的企业选型 PoC

不要用“请假三节点”完成选型。建议准备同一套测试题，在三种候选方案上分别实现。

流程功能题

1. 串行审批、并行会签、按比例会签和一票否决；
2. 运行中加签、减签、转办、委派；
3. 退回上一步、退回指定节点、撤回；
4. 并行网关后回退、子流程回退和边界定时器；
5. 流程版本升级与存量实例迁移；
6. 超时提醒、自动审批、消息重试和补偿。

私有化部署题

1. 单机开发环境安装时间；
2. 生产高可用所需组件和最小资源；
3. 数据库、国产操作系统、JDK 和中间件兼容；
4. 全量备份、单实例恢复和异地灾备；
5. 无公网环境下的镜像、依赖和许可证管理；
6. 从当前版本升级到下一主版本的演练。

运维与安全题

1. OIDC/SSO、租户与组织权限；
2. 流程变量中的敏感数据脱敏与加密；
3. 管理员跳转、删除、迁移操作的审计；
4. Job、Incident、死信和积压告警；
5. 历史数据保留、删除和合规查询；
6. 引擎节点、数据库或消息中间件故障恢复。

评分建议

评分项	建议权重
业务流程适配与中国式审批扩展	25%
私有化部署、可用性与可运维性	20%
源码质量、扩展点与升级成本	15%
性能、容量与故障恢复	15%
许可证、采购与五年总成本	15%
社区、文档、人才和厂商支持	10%

权重应由企业自己调整。例如政务内网可以提高许可证、国产化和审计权重；互联网服务编排可以提高吞吐、跨语言和弹性权重。

如果只记住五句话

1. Camunda 7 和 Camunda 8 是两代不同架构，新项目不要再以已 EOL 的 Camunda 7 社区版为基线。
2. Flowable 更适合作为 Java OA、低代码和中国式人工作流平台的开源二次开发底座，但上层产品能力仍要建设。
3. Activiti 仍在发布版本，已有系统可以继续维护；新项目要重点评估 Java 基线、文档一致性和内部维护能力。
4. Camunda 8 适合分布式服务编排和需要成熟运维产品的企业，但私有化生产许可证与基础设施成本必须前置核算。
5. 会签、加签、回退、跳转、撤销不是换一个引擎就自动拥有的能力，它们是引擎 API、流程规则、权限审计和业务补偿共同构成的平台工程。

最终选择不应是“哪个引擎功能最多”，而应是“哪个方案在五年内最符合企业的流程类型、技术栈、许可证边界和维护能力”。先做真实 PoC，再决定技术路线，通常比围绕品牌争论更可靠。