Camunda 7 与 Camunda 8 不是升级关系：架构差异与选型边界

Camunda 8 不是 Camunda 7 的大版本升级，而是以 Zeebe 为执行核心重新设计的分布式流程编排平台。Camunda 7 是可嵌入 JVM、依赖共享关系型数据库和 Java Service API 的传统流程引擎；Camunda 8 通过远程客户端、Gateway、分区化 Broker、Raft 复制和 Job Worker 运行。

两者都使用 BPMN，但执行状态、事务边界、编程模型、数据查询、运维方式和许可证并不相同。因此，"从 Camunda 7 升级到 Camunda 8"的真实工作通常包括模型转换、JavaDelegate 重构、API 替换、事务重新设计、变量格式调整、运行实例和历史数据迁移，以及部署运维体系重建。

一、先看结论：为什么它们不是升级关系

维度	Camunda 7	Camunda 8	企业影响
执行核心	Java BPMN/PVM 引擎	Zeebe 分布式引擎	不是同一个内核
应用集成	可嵌入 JVM，也可远程 REST	作为远程资源访问	应用边界必须重构
业务代码	JavaDelegate、监听器、脚本、外部任务	Job Worker、Connector、客户端命令	代码不能原样搬迁
主状态存储	共享关系型数据库	分区事件流、Raft、RocksDB	不能复制 ACT_* 表迁移
查询模型	引擎表同步查询	导出到二级存储后查询	需要考虑数据传播
事务模型	可参加 Spring/JTA 事务	不共享业务本地 ACID 事务	必须处理幂等与补偿
集群方式	多节点共享数据库	Broker 分区和副本	扩展与故障恢复不同
典型场景	Java 内嵌流程、传统 BPM/OA	跨服务、跨语言流程编排	选型起点不同

图 1　Camunda 7 围绕 Java 引擎和共享数据库组织，Camunda 8 围绕远程客户端、分区化 Broker 和事件导出组织。

官方迁移指南明确说明 Camunda 8 不是 Camunda 7 的 drop-in replacement。替换 Maven 依赖或修改数据库连接，无法完成迁移。

二、Camunda 7：可嵌入 Java 应用的流程引擎

Camunda 7 的流程引擎可以作为应用库运行在 Java 应用中，也可以作为容器共享服务或独立 REST 服务部署。在典型 Spring 项目中，业务应用和引擎可以：

运行在同一个 JVM；
共享数据源和 Spring TransactionManager；
通过 RuntimeService、TaskService、RepositoryService 等 Java API 交互；
在 JavaDelegate、监听器和表达式中调用 Spring Bean；
将流程状态与业务数据放在同一关系型数据库事务中提交。

图 2　Camunda 7 官方 Process Engine Architecture。

关系型数据库是 Camunda 7 运行状态的权威来源：

ACT_RE_* 保存流程定义和部署资源；
ACT_RU_* 保存执行、任务、变量、作业和事件订阅；
ACT_HI_* 保存实例、任务、变量和操作历史；
ACT_ID_* 保存内置身份数据；
ACT_GE_* 保存属性和二进制资源。

多个引擎节点连接同一个数据库。扩容重点通常是数据库并发、作业获取、索引和应用节点，而不是为流程实例配置分区。

这种可嵌入性很方便，也容易产生迁移耦合：JavaDelegate 与本地事务、直接查询 ACT_* 表、ProcessEnginePlugin、JUEL、Spin、内部命令和 Java 序列化变量，在 Camunda 8 中都没有一一对应的替代物。

三、Camunda 8：以 Zeebe 为核心的分布式编排

Camunda 8 的执行核心 Zeebe 包含四类关键组件：

Client：部署流程、启动实例、发布消息、激活和完成 Job；
Gateway：提供 REST/gRPC 入口并把请求转发给 Broker；
Broker：保存并推进活动流程实例，向 Worker 分配 Job；
Exporter：导出状态变化，供查询、监控、审计和分析使用。

图 3　Camunda 8 官方 Zeebe Architecture。

应用不能把 Zeebe 当作 JAR 嵌入业务 JVM。Java、Node.js 或其他语言的客户端和 Worker 都通过网络与集群交互。

Zeebe 把数据划分为多个 Partition。每个分区由一个 Leader 处理命令，并通过 Raft 在多个 Broker 之间复制；命令写入追加事件流后推进状态机，RocksDB 保存 Broker 本地执行状态。分区提供扩展单位，副本提供容错能力。

这不是"把 MySQL 换成 RocksDB"：

Camunda 7 依靠共享数据库协调节点；
Camunda 8 依靠分区 Leader、复制日志和状态机推进；
Camunda 7 主要扩展无状态应用节点；
Camunda 8 还要规划分区、副本、Broker 资源和磁盘延迟。

四、Job Worker 改变了业务代码边界

Camunda 8 Broker 不执行企业业务逻辑。流程到达 Service Task 后创建 Job，外部 Worker 激活 Job、执行业务操作，再报告完成或失败。这种模型支持跨语言和服务独立扩缩容，但通常采用 at-least-once 处理语义。

如果 Worker 已写入业务数据库，但完成命令超时，Job 可能再次分配。因此业务操作必须具备幂等性：

java 复制代码

@JobWorker(type = "charge-payment")
public Map<String, Object> charge(ActivatedJob job) {
    String orderId = readOrderId(job);
    paymentService.chargeOnce(job.getKey(), orderId);
    return Map.of("paymentStatus", "PAID");
}

幂等键、唯一约束、Transactional Outbox、重试和补偿不再是外围优化，而是 Camunda 8 应用设计的一部分。

五、Camunda 8 支持 RDBMS，为什么仍不是 Camunda 7

Camunda 8 的关系型数据库二级存储可以服务于 Operate、Tasklist、查询 API、历史数据和审计管理，也能降低部分企业对 Elasticsearch/OpenSearch 的运维压力。

但主执行状态仍由 Zeebe 的分区、Raft 和 RocksDB 管理。命令先改变 Broker 中的主状态，再通过 Exporter 把数据写入二级存储，因此查询仍要考虑传播延迟和最终一致性。

这与 Camunda 7 的"业务代码、流程引擎和运行表共享一个数据库事务"完全不同。RDBMS 二级存储降低了私有化门槛，却没有取消远程引擎、分区复制和 Job Worker 模型。

六、最大差异是事务边界

图 4　Camunda 7 可以共享本地数据库事务；Camunda 8 通过远程 Worker、幂等和消息模式实现可靠协作。

在嵌入式 Camunda 7 中，一个业务方法可以更新订单表、完成流程任务并创建下一条执行，随后共同提交；任一步骤抛出异常，业务状态和流程状态可以一起回滚。

Camunda 8 中，Worker 的数据库事务和 Broker 的分区提交是两个独立事务：

Worker 激活 Job；
Worker 更新业务数据库；
Worker 发送完成命令；
Broker 复制并提交命令；
流程进入下一状态。

如果第二步成功而第三步超时，Worker 可能重复执行。企业需要建立：

业务幂等键和去重表；
Transactional Outbox；
Worker 超时与重试策略；
Saga 与补偿；
业务状态和流程状态对账；
可恢复的消息关联。

团队如果仍把"数据库事务里调用 RuntimeService"作为默认模式，迁移成本会远高于 BPMN 图表面显示的差异。

七、API、表达式和变量需要怎样改造

Camunda 7 中的 RuntimeService、TaskService、HistoryService、ManagementService、Native Query、CommandInterceptor 和 DelegateExecution 不能直接搬到 Camunda 8，需要映射到客户端、编排集群 API、任务 API、查询 API或平台自建适配层。

模型层还要盘点：

camunda:class 和 camunda:delegateExpression；
JavaDelegate、执行监听器和任务监听器；
JUEL 表达式与 camunda:inputOutput；
Spin JSON/XML 和 Java Object 变量；
Script Task、表单、Connector 和自定义扩展；
直接依赖引擎内部命令或数据库查询的代码。

Camunda 8 主要使用 FEEL 和 JSON 文档数据。转换工具可以发现语法差异，却不能证明业务语义、事务和异常路径等价。

最稳妥的改造方式是在业务系统和引擎之间建立流程适配层，向上暴露启动流程、完成任务、发布消息、查询状态和获取轨迹等领域接口，避免新旧引擎 API 散落在业务页面中。

八、数据库和运行实例能否直接迁移

Camunda 7 的 ACT_* 关系表保存执行树、任务、作业和历史；Camunda 8 主状态来自分区事件流和 RocksDB 状态机。两套主键和一致性机制不同，不能直接复制数据库。

迁移对象至少包括：

BPMN/DMN 模型和扩展属性；
JavaDelegate、监听器、外部任务与 API；
运行实例、活动元素、变量和用户任务；
历史实例、节点、变量和操作日志；
用户、组、租户与授权；
业务表、附件、表单、消息和幂等状态；
Cockpit、Tasklist、报表和外部集成。

官方迁移工具可辅助模型分析、代码映射、部分等待状态实例、历史和身份数据迁移，但工具版本必须与源、目标版本匹配，并且复杂并行、多实例、补偿、事件子流程、嵌套调用活动、局部变量和自定义历史仍可能需要人工处理。

迁移前必须用真实实例运行分析工具。不能迁移的实例应先移动到受支持的等待点，或继续在 Camunda 7 中自然跑完。

九、迁移路线怎样选择

图 5　迁移不是一次数据库升级，默认应按流程或业务域逐步分流。

1. Drain Out

旧流程停止创建新实例，新版本进入 Camunda 8；存量实例继续由 Camunda 7 运行，统一门户在过渡期聚合两套待办。它风险最低、容易回退，但需要一段时间双轨运行。

2. Big Bang

模型、Worker、活动实例、身份、任务入口和运维工具在同一窗口切换。它适合实例可控、停机窗口明确且工具覆盖率较高的单个流程解决方案，不适合把全公司流程一次性切换。

3. Strangler

先建立统一流程服务层，再按业务域逐步迁移。短周期、低耦合和外部任务流程先迁；依赖本地事务、内部 API、CMMN 和定制插件的流程后迁。这通常是大型流程平台更现实的路线。

十、私有化部署差异

Camunda 7 的典型生产架构是多个 Java 引擎节点连接高可用关系型数据库。重点关注数据库备份、索引、连接池、作业锁、历史清理、JVM 和自定义插件。基础设施较熟悉，但共享数据库是性能和可用性核心。

Camunda 8 Self-Managed 需要运维整个编排栈，重点包括：

Broker、Gateway、Partition 和 Replica；
RocksDB 磁盘容量、吞吐和延迟；
Raft 仲裁、故障域和备份恢复；
二级存储、Exporter 和数据保留；
REST/gRPC 网络、证书和访问控制；
Worker 容量、超时、重试与幂等；
集群升级、Public API 和许可证。

如果团队只熟悉"一个 Spring Boot JAR 加一个 MySQL"，应先用真实负载完成 Camunda 8 Self-Managed PoC，而不是只比较 BPMN 元素覆盖率。

十一、许可证与生命周期边界

Camunda 7 Community Edition 最终版本之后不再获得社区版安全补丁和维护更新。存量系统可以继续治理，但新项目不应把 Camunda 7 CE 作为默认长期底座；关键系统应评估企业支持、自维护能力和退出路线。

Camunda 8 Self-Managed 的开发测试与生产许可边界不同。源码可见不等于企业可以免费用于生产，选型时必须把生产许可证、Broker 与二级存储资源、平台团队、备份监控、双轨迁移和咨询成本同时计入 TCO。

不能沿用 Camunda 7 CE 的 Apache 2.0 经验推断 Camunda 8 的生产使用条件。

十二、哪些场景适合继续使用 7，哪些适合选择 8

图 6　先判断核心需求是嵌入式本地事务还是跨服务分布式编排，再比较具体功能。

存量 Camunda 7 可以有计划继续运行的条件包括：

系统稳定，预计在支持期内下线；
已有企业支持或具备安全加固和自维护能力；
深度依赖嵌入式引擎和本地事务；
流程数量有限，迁移收益不足以覆盖重构成本。

Camunda 8 更适合：

新建跨服务、跨语言编排平台；
需要高可用、分区扩展和独立 Worker；
业务本来就通过远程 API 和消息集成；
团队能实施幂等、Outbox、Saga 和可观测性；
能接受 Self-Managed 运维和生产许可成本。

Camunda 8 并不是中国式 OA 的默认答案。会签、加签、退回、撤回、转办、代理、审批意见和组织选人仍属于平台能力。对于人工作业为主、依赖 Java 本地事务的低代码/OA 平台，还应同时比较 Flowable 等嵌入式路线。

云程低代码开发平台更适合在业务模块和引擎之间建立稳定流程服务层：下层按场景适配嵌入式审批引擎或远程编排引擎，上层统一表单、门户、组织、权限、待办和审计。

十三、企业 PoC 应验证什么

验证项	Camunda 7 重点	Camunda 8 重点
业务一致性	本地事务、回滚、作业边界	幂等、Outbox、重试、补偿
人工任务	候选人、权限、表单、批量操作	Task API、身份、最终一致性
系统集成	JavaDelegate、外部任务、REST	Job Worker、Connector、消息
性能	数据库锁、历史表、Job Executor	分区、Broker、Worker、磁盘
高可用	共享数据库、应用节点切换	Raft、副本、故障域、Gateway
运维	SQL、Cockpit、历史清理	Operate、二级存储、Exporter、备份
迁移	7.x 内部升级	模型、代码、实例、历史和身份
成本	数据库和企业支持	生产许可证与平台基础设施

PoC 应使用真实业务路径，覆盖并行、多实例、消息、定时器、失败重试、人工干预和外部副作用。只测试每秒启动多少空流程，无法证明架构适合企业生产。

十四、最终结论

Camunda 7 与 Camunda 8 的共同点是 BPMN，差异却贯穿执行内核、事务、编程、存储、查询、运维和许可。Camunda 7 到 8 是架构迁移，不是依赖升级。

存量 Camunda 7 应先治理、解耦和制定退出路线；新建跨服务编排平台可以优先评估 Camunda 8；传统人工审批和低代码 OA 则应从组织、事务、动态审批和二开成本出发，比较包括 Flowable 在内的嵌入式路线。

一句话总结：只有当分布式编排价值能够覆盖应用重构、最终一致性、集群运维和生产许可成本时，Camunda 8 才是正确答案。