Activiti 5、6、7 有什么区别？老项目是否值得升级？

先给结论：Activiti 5、6、7 不是一条“版本越高、替换依赖就越先进”的简单升级线。 Activiti 5 是经典的嵌入式 Java BPMN 引擎；Activiti 6 重写了执行核心；Activiti 7 在 6.x 内核之上增加新的 Runtime API，并把路线延伸到 Spring Boot、消息驱动和 Activiti Cloud。

老项目是否值得升级，应由系统寿命、技术债、在途流程、审批扩展和团队能力共同决定。短期下线的稳定系统适合隔离与加固；仍要长期建设的核心系统，则应把“升级版本”改写为“解除内部依赖、建立适配层、可验证地迁移数据与流程”。

一、先判断：这不是一个单纯的版本问题

Activiti 5→6 的主要变化发生在引擎内部：PVM 被移除，BPMN 模型改为直接执行，Execution Tree 与异步作业重新设计。Activiti 6→7 的重点则转到引擎外部：新增 ProcessRuntime、TaskRuntime，强化 Spring Security 上下文，并出现 Runtime Bundle、Query、Audit、Connector 等服务化组件。

因此，企业首先要回答三个问题：

1. 系统是否还要运行三年以上，是否仍承担核心业务？
2. 代码是否依赖 .impl、PVM、直接 SQL、Java 序列化变量或自定义执行树操作？
3. 目标只是获得较新的嵌入式引擎，还是要建设独立发布、事件驱动的流程平台？

如果第三个问题没有明确答案，不要因为“7 大于 6”就直接选择 Activiti 7 Cloud。

二、一张表看懂 Activiti 5、6、7

对比项	Activiti 5	Activiti 6	Activiti 7
典型形态	嵌入 Java/Spring 应用	嵌入式引擎，经典 API 延续	Core 或 Cloud 组件
执行模型	BPMN 转换为 PVM	移除 PVM，直接执行 BPMN	延续 6.x 内核
常用 API	RepositoryService、RuntimeService、TaskService	公共 Service API 基本延续	新增 ProcessRuntime、TaskRuntime、Payload 风格
异步作业	Job Executor；后期加入 Async Executor	只保留重构后的 Async Executor，作业状态拆表	Core 继续异步执行；Cloud 可接消息与 Connector
安全与身份	多由业务系统自行集成	与 5.x 相近	新 API 更强调 Spring Security 调用上下文
迁移重点	—	内部 API、执行树、作业表	API 边界、认证、部署和运维体系
适合场景	存量遗留系统	低风险过渡或较新遗留内核	需要新 API 或服务化架构的系统

一句话概括：5→6 改的是“里面怎样跑”，6→7 改的是“外面怎样用和怎样部署”。

图 1：三个版本的核心变化发生在不同层次，不能仅按版本号理解。

三、三个版本分别改变了什么

1. Activiti 5：成熟、轻量，但容易被内部实现绑死

Activiti 5 的优势是轻量、关系型数据库友好、Java 扩展方便。ProcessEngine 及 RepositoryService、RuntimeService、TaskService、HistoryService 等公共 API，成为大量国内 OA 和低代码平台的基础。

风险来自长期二次开发。为实现退回、跳转、加签或自由流转，许多系统直接使用 org.activiti.engine.impl.pvm、ActivityImpl、TransitionImpl、ExecutionImpl、CommandContext，甚至直接修改 ACT_RU_* 表。这些内部类从来不是稳定契约，一旦升级，改造成本会集中爆发。

2. Activiti 6：重写执行核心，不是普通功能升级

Activiti 6 移除 PVM，直接依据 BPMN 模型推进流程，重构了 Execution Tree，并调整 ActivityBehavior、EntityManager 等内部结构。只使用公共 Service API 的系统通常改动可控；深度依赖 .impl 和 PVM 的系统则接近一次局部重写。

异步作业也被重新设计。Activiti 6 将可执行作业、定时作业、挂起作业和死信作业分别放入 ACT_RU_JOB、ACT_RU_TIMER_JOB、ACT_RU_SUSPENDED_JOB、ACT_RU_DEADLETTER_JOB。拆表改善了查询和运维，但也意味着升级数据库、作业数据和恢复机制必须一起验证。

3. Activiti 7：从引擎 API 走向 Core + Cloud

Activiti 7 延续 6.x 的执行内核，新增 ProcessRuntime、TaskRuntime 和 Payload/Command 风格 API，并把认证用户、角色和权限带入调用上下文。经典 RuntimeService、TaskService 并未立即消失，因此可以渐进采用新 API。

Activiti Cloud 则是另一层变化：Runtime Bundle 执行流程，Query Service 消费事件形成查询模型，Audit Service 汇聚审计事件，Connector 通过消息完成外部集成。这不是“把 JAR 换成更高版本”，而是新增消息代理、身份服务、部署编排、可观测性和跨服务一致性。

图 2：Activiti 7 没有把关系型内核改造成另一类引擎，而是在 Core 外增加新的调用和部署边界。

四、5→6 与 6→7，风险为什么不同

风险维度	5→6	6→7
公共 API	多数经典 Service API 可延续	可继续使用，也可引入新 Runtime API
内部扩展	PVM、ActivityImpl 等集中失效	主要评估安全上下文与 API 适配
数据库	作业拆表、Schema 升级、兼容模式	Core 仍是关系库；Cloud 增加服务数据与事件链路
在途实例	可评估 5.x Compatibility 让老实例自然跑完	不宜把 Cloud 当作在途实例原地升级
运维边界	单体内核升级	可能变成分布式平台改造

评估风险时，先做一次代码扫描：

重点搜索：org.activiti.engine.impl、org.activiti.engine.impl.pvm、ActivityImpl、TransitionImpl、ExecutionImpl、CommandContext、DbSqlSession、ExecutionEntity、TaskEntity、ACT_RU_、ACT_HI_、runtimeService.signal( 和 databaseSchemaUpdate=true。

结果数量只是线索。只读报表查询 ACT_HI_* 与直接修改 ACT_RU_* 的风险完全不同，必须逐项标记“读或写、线上或离线、是否有公共 API 替代、是否有自动化测试”。

五、数据库和在途流程能不能直接升级

表名前缀相同，不代表可以直接覆盖升级；BPMN XML 能重新部署，也不代表在途实例能按相同语义继续运行。

Activiti 5→6 可使用官方增量脚本，并可评估 Activiti 5 Compatibility：老定义与老实例继续由兼容引擎执行，新部署的定义使用 6.x 执行，待旧实例自然结束后退出兼容模式。它适合长周期流程，但需要核实实际发行物、Compatibility Handler、监听器类加载以及新旧定义并存时的行为。

生产升级至少要处理五类数据：

• ACT_RE_*：流程定义、部署资源与版本；
• ACT_RU_*：执行树、任务、变量、身份关联和异步作业；
• ACT_HI_*：历史实例、历史任务、活动与变量；
• ACT_GE_BYTEARRAY：BPMN、资源和二进制变量；
• 业务表：单据状态、流程实例 ID、任务 ID、审批记录和业务副作用。

特别关注 Java 序列化变量。JDK、类包名或 serialVersionUID 变化，都可能使历史对象无法反序列化。长期方案应优先使用 JSON、字符串、数字和稳定的数据契约。

不要让生产应用用 databaseSchemaUpdate=true 自动改库。更稳妥的方式是：按官方顺序执行增量 DDL，先在脱敏生产副本演练，核对表结构和数据量，再验证启动、作业恢复、在途实例推进、历史查询与回退。

六、中国式审批扩展是升级的高风险区

开源引擎能执行 BPMN，但会签、加签、退回、跳转、撤回往往是平台层能力。旧系统如果通过修改 Execution、临时改连线或补写历史表实现这些动作，升级风险通常高于普通流程。

• 会签：核对并行/串行、多实例计数、人员快照、完成条件和减签；
• 加签：明确前加签、后加签、返回路径、多层嵌套与被加签人权限；
• 退回与跳转：不能再依赖 ActivityImpl、TransitionImpl 临时改线，应使用受控状态迁移并保留审计；
• 撤回与撤销：流程状态回退不等于业务副作用回退，必须设计消息、库存、财务和外部接口的补偿。

在云程低代码开发平台这类长期演进的产品中，业务模块应依赖统一的流程能力接口，而不是直接依赖 RuntimeService 或某个 ExecutionEntity。引擎升级时，只替换适配器、状态迁移实现和回归用例，表单、门户、组织权限与业务应用不必整体重写。

七、三条路线：延寿、过渡升级还是平台迁移

图 3：先判断系统寿命和耦合程度，再决定是否升级；版本号不是决策起点。

1. 路线一：保持现状并延寿

适合一两年内下线、需求冻结、风险可控的 Activiti 5 系统。重点是隔离公网、修补依赖漏洞、补充数据库与作业监控、固定运行环境、演练备份恢复。不要为追求版本数字发起高风险迁移。

2. 路线二：把 Activiti 6 作为过渡

适合必须低风险延寿，且希望先清理 PVM 和内部 API 的系统。先建立适配层和测试，再按官方脚本升级数据库，必要时让老实例通过 Compatibility 自然跑完。需要注意：在 2026 年，Activiti 6 通常是风险过渡点，不宜自动视为长期终点。

3. 路线三：面向长期平台重新选型

适合还要持续建设的 OA、低代码和流程中台。先把流程定义、表单、组织、审批策略、业务副作用与引擎解耦，再评估 Activiti 新路线、Flowable 或其他受维护引擎。只有确实需要独立发布、事件驱动和服务隔离时，才投入 Cloud 组件。

项目现状	推荐策略
Activiti 5，短期下线	隔离、加固、监控、冻结需求
Activiti 5，长期运行但预算有限	先移除内部 API，再以 6.x 兼容机制过渡
Activiti 5/6，持续建设	建立适配层，分批迁移到受维护的现代引擎
Activiti 6，公共 API 使用规范	可渐进评估 Core 和新 Runtime API
需要服务化、独立发布	用新流程试点 Cloud，不强搬全部存量实例
深度 PVM、直接 SQL 定制	先重构状态操作和测试体系，再谈目标版本

八、一套可执行的升级步骤

1. 建立资产清单：JDK、Spring、数据库、引擎版本、插件、自定义命令、监听器、序列化变量、SQL、流程数量和最长运行周期。
2. 建立风险分级：公共 API 为低风险，内部 API 和自定义行为为中高风险，直接改运行时表和执行树为最高风险。
3. 冻结流程版本：保留 BPMN XML、部署资源、表单版本、Java 类和依赖制品，确保历史实例可重放。
4. 建立回归矩阵：覆盖普通审批、并行网关、多实例、边界事件、定时器、子流程，以及会签、加签、退回、撤回。
5. 用生产副本演练：执行完整增量脚本，记录耗时、锁等待、表行数、失败作业和不可反序列化变量。
6. 双轨切换：新流程先进入新引擎或新版本，老实例自然结束；无法共存时才安排停机迁移。
7. 分层回滚：代码、数据库、部署资源和业务状态必须拥有同一时间点的回退基线。

升级前最好先做一个小型 PoC：选择一个包含人工任务、并行分支、定时器、会签和业务回调的真实流程，分别验证部署、启动、办结、异常重试、历史查询和回退。PoC 的价值不是跑通“请假流程”，而是暴露真实扩展与数据边界。

九、上线验收与回滚清单

上线验收不能只看应用启动成功。至少确认：

• Schema 版本、表结构、索引和数据量符合预期；
• 在途实例、待办、候选人、变量和业务单据一一对应；
• 定时器、异步作业、死信恢复和集群抢占行为正常；
• 新旧流程定义能够按预定边界共存；
• 会签、加签、退回、撤回的审计链完整；
• 历史查询、报表和数据权限没有越权或缺失；
• 监控能够发现作业积压、异常重试和流程停滞；
• 回滚演练包含数据库、应用、消息和业务副作用。

切换后应设置观察期，限制批量部署和高风险审批操作。一旦触发关键指标阈值，应按预案停止新实例进入，而不是边运行边修库。

十、最终建议

如果只记住五句话：

1. Activiti 5→6 是执行内核重构，6→7 是 API 与部署边界升级。
2. 只使用公共 Service API 的系统迁移相对可控；依赖 PVM、.impl 和直接 SQL 的系统风险最高。
3. 表名相同不等于数据兼容，必须使用官方增量脚本并验证在途实例、作业和历史数据。
4. Activiti 7 Cloud 是平台架构选择，不是 Activiti 6 的普通 JAR 升级。
5. 真正的升级目标不是获得更高版本号，而是建立稳定接口、可回归数据和下一次可替换的能力。

对于准备下线的系统，稳定延寿可能是正确答案；对于长期核心系统，先解除内部实现耦合，再选择目标引擎；对于希望建设流程平台的企业，则应把组织权限、表单、审批策略、审计、监控和业务补偿纳入整体设计。