怎么说呢，

在决定是否升级到 Camunda 8 时公司往往会先把两者看作同一个“版本升级”。但它们是根本不同的架构，下面用结构化的方式梳理差异。并把最常见的痛点直接贴在对应章节，让你一目了然。

一、Camunda 7 与 Camunda 8 并非升级关系

痛点提示：如果你们把“RuntimeService 调用”当成默认做法，迁移成本将远超预期。务必评估业务代码是否已深度耦合到流程引擎。

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

• 同 JVM 执行： 业务方法、流程任务、变量更新可以在同一个事务中提交；错误抛出即可回滚所有内容。
• 共享关系型数据库： ACT_RE_*。ACT_RU_*,ACT_HI_* 等表记录完整生命周期，查询和报表都表。
• 易于 ： 通过插件、JUEL 表达式和自定义 JavaDelegate 可实现几乎所有自定义逻辑。说起来，

痛点：高耦合导致迁移时 JavaDelegate、监听器等大量代码必须重写；若不熟悉 JPA 或 Spring Boot 的事务管理，容易出现数据不一致问题。

Camel 7 的典型场景

• BPMN/OA 流程需要与业务数据共享同一事务。其实，
• "低代码" 网站偏好嵌入式实现。以便快速迭代 UI 和表单。其实，

三、Camunda 8：以 Zeebe 为主要的分布式编排

1. Client： 部署/启动实例/发布消息。
2. Gateway： REST/gRPC 接口入口，将请求路由至 Broker。
3. Broker： 持久化事件流、分区 Leader 与 Raft 副本负责状态推进；RocksDB 存储本地执行状态。
4. Exporter： 将状态变化导出至二级存储，用于 Operate / Tasklist 等 UI 查询。

从痛点来看，• 必须为每个 Service Task 提供独立外部 Worker。• 所有外部调用都要使用 at‑least‑once semantics。需要幂等或补偿机制，否则可能出现重复执领域务。• 数据最终一致性延迟需考虑，查询性能不再像关系型数据库那样即时可得。• 运维团队需掌握 Raft 副本同步、RocksDB 存储容量规划等技术栈，而不是仅靠数据库备份。

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

`@JobWorker` 示例说明 JobWorker 如何将业务逻辑从引擎中拆离出来而且强调了幂等性的关键性。若你的服务已在内部事务中处理完成，则在 Zeebe 中必须对了设计去重策略。例如 Outbox 或唯一约束，以防止“第二次成功，但第三次失败”导致数据不一致。

从痛点来看，现有 JavaDelegate 通常依赖直接 JD娱乐 操作或 Spring TransactionManager。而在 Zeebe 中这类操作会被拆成两个独立事务，容易产生竞态条件与数据漂移。

五、RDBMS 支持只是辅助功能，不是主要区别

• Zeeebe 将主状态保存在 RocksDB + Raft 日志中；关系型数据库仅用于二级查询。这代表着查询时仍会存在传播延迟与最终一致性问题。

Camel 7 vs 8 对 RDBMS 的使用差异

痛点提示的观点是，

• AWS 或 Azure 上已有成熟的 RDS 监控方案可以直接使用 Camunda 7，但如果切换到 Camunda 8，你需要额外配置 Kafka 或 Pulsar 用于事件导出，而且还要学习 RocksDB 的磁盘管理和备份策略。

Camel 7 能让你一次性更新订单表并完成流程任务，接下来一起提交回滚；而 Camel 8 则是两段独立事务——Worker 与 Broker 分别提交。出现“重复执领域务”的风险。需要额外设计去重或补偿机制.

• Camel 7 场景：公司内部程序对 ACID 要求极高，对跨服务协作需求不大；或者已经拥有完整的 Java 内嵌插件程序，可快速上线新功能。
• Camel 8 场景：跨服务协作、多语言支持、高并发下需要水平扩容，需要可靠消息驱动还有幂等/补偿模式来保证最终一致性。如财务审批跨程序调用支付网关时就必须使用 Job Worker 并实现幂等签名。请根据实际案例评估是否必要.

  七、API、表达式和变量改造方法