先给结论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 等服务化组件。因此企业首先要回答三个问题系统是否还要运行三年以上是否仍承担核心业务代码是否依赖 .impl、PVM、直接 SQL、Java 序列化变量或自定义执行树操作目标只是获得较新的嵌入式引擎还是要建设独立发布、事件驱动的流程平台如果第三个问题没有明确答案不要因为“7 大于 6”就直接选择 Activiti 7 Cloud。二、一张表看懂 Activiti 5、6、7对比项Activiti 5Activiti 6Activiti 7典型形态嵌入 Java/Spring 应用嵌入式引擎经典 API 延续Core 或 Cloud 组件执行模型BPMN 转换为 PVM移除 PVM直接执行 BPMN延续 6.x 内核常用 APIRepositoryService、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 CloudActiviti 7 延续 6.x 的执行内核新增 ProcessRuntime、TaskRuntime 和 Payload/Command 风格 API并把认证用户、角色和权限带入调用上下文。经典 RuntimeService、TaskService 并未立即消失因此可以渐进采用新 API。Activiti Cloud 则是另一层变化Runtime Bundle 执行流程Query Service 消费事件形成查询模型Audit Service 汇聚审计事件Connector 通过消息完成外部集成。这不是“把 JAR 换成更高版本”而是新增消息代理、身份服务、部署编排、可观测性和跨服务一致性。图 2Activiti 7 没有把关系型内核改造成另一类引擎而是在 Core 外增加新的调用和部署边界。四、5→6 与 6→7风险为什么不同风险维度5→66→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( 和 databaseSchemaUpdatetrue。结果数量只是线索。只读报表查询 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_BYTEARRAYBPMN、资源和二进制变量业务表单据状态、流程实例 ID、任务 ID、审批记录和业务副作用。特别关注 Java 序列化变量。JDK、类包名或 serialVersionUID 变化都可能使历史对象无法反序列化。长期方案应优先使用 JSON、字符串、数字和稳定的数据契约。不要让生产应用用 databaseSchemaUpdatetrue 自动改库。更稳妥的方式是按官方顺序执行增量 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 定制先重构状态操作和测试体系再谈目标版本八、一套可执行的升级步骤建立资产清单JDK、Spring、数据库、引擎版本、插件、自定义命令、监听器、序列化变量、SQL、流程数量和最长运行周期。建立风险分级公共 API 为低风险内部 API 和自定义行为为中高风险直接改运行时表和执行树为最高风险。冻结流程版本保留 BPMN XML、部署资源、表单版本、Java 类和依赖制品确保历史实例可重放。建立回归矩阵覆盖普通审批、并行网关、多实例、边界事件、定时器、子流程以及会签、加签、退回、撤回。用生产副本演练执行完整增量脚本记录耗时、锁等待、表行数、失败作业和不可反序列化变量。双轨切换新流程先进入新引擎或新版本老实例自然结束无法共存时才安排停机迁移。分层回滚代码、数据库、部署资源和业务状态必须拥有同一时间点的回退基线。升级前最好先做一个小型 PoC选择一个包含人工任务、并行分支、定时器、会签和业务回调的真实流程分别验证部署、启动、办结、异常重试、历史查询和回退。PoC 的价值不是跑通“请假流程”而是暴露真实扩展与数据边界。九、上线验收与回滚清单上线验收不能只看应用启动成功。至少确认Schema 版本、表结构、索引和数据量符合预期在途实例、待办、候选人、变量和业务单据一一对应定时器、异步作业、死信恢复和集群抢占行为正常新旧流程定义能够按预定边界共存会签、加签、退回、撤回的审计链完整历史查询、报表和数据权限没有越权或缺失监控能够发现作业积压、异常重试和流程停滞回滚演练包含数据库、应用、消息和业务副作用。切换后应设置观察期限制批量部署和高风险审批操作。一旦触发关键指标阈值应按预案停止新实例进入而不是边运行边修库。十、最终建议如果只记住五句话Activiti 5→6 是执行内核重构6→7 是 API 与部署边界升级。只使用公共 Service API 的系统迁移相对可控依赖 PVM、.impl 和直接 SQL 的系统风险最高。表名相同不等于数据兼容必须使用官方增量脚本并验证在途实例、作业和历史数据。Activiti 7 Cloud 是平台架构选择不是 Activiti 6 的普通 JAR 升级。真正的升级目标不是获得更高版本号而是建立稳定接口、可回归数据和下一次可替换的能力。对于准备下线的系统稳定延寿可能是正确答案对于长期核心系统先解除内部实现耦合再选择目标引擎对于希望建设流程平台的企业则应把组织权限、表单、审批策略、审计、监控和业务补偿纳入整体设计。
先给结论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 等服务化组件。因此企业首先要回答三个问题系统是否还要运行三年以上是否仍承担核心业务代码是否依赖 .impl、PVM、直接 SQL、Java 序列化变量或自定义执行树操作目标只是获得较新的嵌入式引擎还是要建设独立发布、事件驱动的流程平台如果第三个问题没有明确答案不要因为“7 大于 6”就直接选择 Activiti 7 Cloud。二、一张表看懂 Activiti 5、6、7对比项Activiti 5Activiti 6Activiti 7典型形态嵌入 Java/Spring 应用嵌入式引擎经典 API 延续Core 或 Cloud 组件执行模型BPMN 转换为 PVM移除 PVM直接执行 BPMN延续 6.x 内核常用 APIRepositoryService、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 CloudActiviti 7 延续 6.x 的执行内核新增 ProcessRuntime、TaskRuntime 和 Payload/Command 风格 API并把认证用户、角色和权限带入调用上下文。经典 RuntimeService、TaskService 并未立即消失因此可以渐进采用新 API。Activiti Cloud 则是另一层变化Runtime Bundle 执行流程Query Service 消费事件形成查询模型Audit Service 汇聚审计事件Connector 通过消息完成外部集成。这不是“把 JAR 换成更高版本”而是新增消息代理、身份服务、部署编排、可观测性和跨服务一致性。图 2Activiti 7 没有把关系型内核改造成另一类引擎而是在 Core 外增加新的调用和部署边界。四、5→6 与 6→7风险为什么不同风险维度5→66→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( 和 databaseSchemaUpdatetrue。结果数量只是线索。只读报表查询 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_BYTEARRAYBPMN、资源和二进制变量业务表单据状态、流程实例 ID、任务 ID、审批记录和业务副作用。特别关注 Java 序列化变量。JDK、类包名或 serialVersionUID 变化都可能使历史对象无法反序列化。长期方案应优先使用 JSON、字符串、数字和稳定的数据契约。不要让生产应用用 databaseSchemaUpdatetrue 自动改库。更稳妥的方式是按官方顺序执行增量 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 定制先重构状态操作和测试体系再谈目标版本八、一套可执行的升级步骤建立资产清单JDK、Spring、数据库、引擎版本、插件、自定义命令、监听器、序列化变量、SQL、流程数量和最长运行周期。建立风险分级公共 API 为低风险内部 API 和自定义行为为中高风险直接改运行时表和执行树为最高风险。冻结流程版本保留 BPMN XML、部署资源、表单版本、Java 类和依赖制品确保历史实例可重放。建立回归矩阵覆盖普通审批、并行网关、多实例、边界事件、定时器、子流程以及会签、加签、退回、撤回。用生产副本演练执行完整增量脚本记录耗时、锁等待、表行数、失败作业和不可反序列化变量。双轨切换新流程先进入新引擎或新版本老实例自然结束无法共存时才安排停机迁移。分层回滚代码、数据库、部署资源和业务状态必须拥有同一时间点的回退基线。升级前最好先做一个小型 PoC选择一个包含人工任务、并行分支、定时器、会签和业务回调的真实流程分别验证部署、启动、办结、异常重试、历史查询和回退。PoC 的价值不是跑通“请假流程”而是暴露真实扩展与数据边界。九、上线验收与回滚清单上线验收不能只看应用启动成功。至少确认Schema 版本、表结构、索引和数据量符合预期在途实例、待办、候选人、变量和业务单据一一对应定时器、异步作业、死信恢复和集群抢占行为正常新旧流程定义能够按预定边界共存会签、加签、退回、撤回的审计链完整历史查询、报表和数据权限没有越权或缺失监控能够发现作业积压、异常重试和流程停滞回滚演练包含数据库、应用、消息和业务副作用。切换后应设置观察期限制批量部署和高风险审批操作。一旦触发关键指标阈值应按预案停止新实例进入而不是边运行边修库。十、最终建议如果只记住五句话Activiti 5→6 是执行内核重构6→7 是 API 与部署边界升级。只使用公共 Service API 的系统迁移相对可控依赖 PVM、.impl 和直接 SQL 的系统风险最高。表名相同不等于数据兼容必须使用官方增量脚本并验证在途实例、作业和历史数据。Activiti 7 Cloud 是平台架构选择不是 Activiti 6 的普通 JAR 升级。真正的升级目标不是获得更高版本号而是建立稳定接口、可回归数据和下一次可替换的能力。对于准备下线的系统稳定延寿可能是正确答案对于长期核心系统先解除内部实现耦合再选择目标引擎对于希望建设流程平台的企业则应把组织权限、表单、审批策略、审计、监控和业务补偿纳入整体设计。
