1. 从裸用 Activiti 到建设流程平台一次架构演进复盘先说背景。我过去几年带团队做过不少企业内部系统的流程模块早期项目图省事直接在业务代码里嵌 Activiti部署一个流程就塞一个流程定义所有审批逻辑都往引擎里写。前两年还好等流程数量一多、参与方一杂问题就全冒出来了流程定义散落在各个服务里、发起和审批入口五花八门、改一条流程要发版上线、跑挂一个节点连日志都找不到。到了后面光靠 Activiti 的 API 已经撑不住整个企业的流程诉求了。这篇博文就围绕一条主线怎么从“业务系统里用 Activiti”过渡到“统一的企业流程平台”。我会先复盘裸用阶段踩过的坑再讲平台化改造时的架构设计、核心模块拆分、几个关键落地细节包括 Activiti 数据库版本选型、离线插件安装这类很具体的问题最后把线上实施过程中遇到的典型故障和排查思路整理成一份速查表。如果你现在正处在“流程代码越写越多、却感觉越来越难维护”的阶段这篇文章应该能帮你看清楚问题出在哪以及从哪儿下手去做升级。2. 为什么非要从 Activiti 走向流程平台2.1 裸用 Activiti 的典型痛点先说场景。大部分团队第一次接触 Activiti都是因为业务里需要审批流。最常见的做法是在订单、报销、合同这类应用里引入 Activiti 依赖然后自己封装一层 Service谁要发起流程就调用一下谁要审批就查一下任务列表。前期只有两三条流程的时候这套玩法效率很高因为 Activiti 对 BPMN 2.0 规范的支持非常完整流程定义管理、任务分配、流程变量、历史数据它全都帮你做掉了。但随着流程数量增长几个问题会越来越明显。第一流程定义和业务系统强耦合。每条流程的 bpmn 文件放在各自工程里改了要跟着业务服务一起打包发版。哪天产品提了一句话说“合同审批的第三级审批人换成部门总监”本意是个五分钟的配置改动结果你愣是得走一次发布流程。第二执行引擎分散。好几个服务各自引入 Activiti等于跑了好几套流程引擎每个引擎维护自己的 ACT_* 表跨系统的流程协同根本做不了。第三监控和排查能力约等于零。流程实例卡在哪个节点哪个环节耗时最长有没有异常重试机制这些在裸用阶段基本靠手工翻数据库。2.2 流程平台要解决什么问题所以做流程平台本质上不是“换掉 Activiti”而是“把 Activiti 收编到平台内部”让业务系统不再各自为战。这里面的核心转变有三个。一是角色转变。原来 Activiti 是嵌在业务代码里的一个组件改造后它变成了平台层的基础引擎对外提供统一的服务能力。业务系统不再直接触碰 engine API而是走平台提供的接口。二是能力补齐。Activiti 本身解决的是流程执行问题但它不关心流程怎么设计、怎么管理、怎么监控、怎么统计。流程平台要在引擎外面补上这些能力可视化流程设计器、统一流程管理后台、流程实例监控、超时提醒、SLA 统计、组织权限同步等等。三是标准统一。所有业务流程都通过平台发起和流转流程定义统一管理任务统一处理接口统一规范。这样不管是新的审批需求还是对接外部系统都有了一套标准的接入方式而不是每个项目自己造一套轮子。3. 流程平台的整体架构设计与能力规划3.1 平台分层架构怎么定在做架构设计的时候我没有一上来就写代码而是先定了一个原则平台要跟业务系统解耦但也要让业务系统接入得足够轻。最后落地下来的分层结构大致是这样的。接入层对外提供统一的 REST API 和消息通道主要解决身份认证、参数校验、接口鉴权这些通用问题。不管是内部系统还是外部系统接入流程平台都走这一层不允许有人绕过平台直接调引擎。服务层是平台的业务核心流程定义管理、流程实例管理、任务管理、委派转办、驳回跳转、会签票签这些能力都在这一层封装对上屏蔽引擎细节。引擎层就是 Activiti负责 BPMN 解析、流程驱动、任务分配、事件触发这些标准能力。管理端是运营和配置人员的入口负责流程设计、部署、权限配置、监控告警。存储层除了 Activiti 自身的 ACT_* 表还增加了平台自己的业务表用来存流程分类、表单绑定关系、操作日志、流程与业务单据的关联关系。这个分层结构其实参考了业界做流程平台比较通用的模式。重点不在架构图本身多好看而在“边界要清晰”引擎就是引擎平台就是平台业务系统就是业务系统谁也别跨界。3.2 核心模块拆解平台化改造过程中我觉得有五个模块是必须认真做的缺一个后面都难受。流程设计器。设计器是给流程管理员用的不是给程序员用的。所以不能直接丢个 Activiti Modeler 给业务人员那样他们光画网关和事件就会懵。我们的做法是基于 bpmn-js 做了一套简化版设计器默认只暴露开始事件、用户任务、排他网关、结束事件这几种常用要素其他高级元素在高级模式下才展示。设计器最终生成标准的 BPMN 2.0 XML保存到流程定义库。流程定义管理。这个模块管的是流程的“版本、分类、状态、权限”。部署新版本的时候设置为待发布状态确认没问题再激活。已经发起的老流程继续使用旧版本新发起默认走新版本这是 Activiti 本身就支持的版本机制平台要做的就是把它合理地暴露出来。统一任务中心。每个业务系统都有一套自己的待办列表这是常态。平台要做的不是取代业务系统的待办而是提供统一的任务查询和操作接口。待办数据通过消息实时同步给业务系统业务侧只需要接收数据做展示真正的审批动作统一回写平台。实例监控与运维。这是裸用 Activiti 时最缺的能力。平台要能实时看到每个流程实例走到哪个节点、当前处理人是谁、这个节点停留多久、有没有超时告警。Activiti 的引擎事件监听器就是做这件事的抓手通过监听任务创建、任务完成、流程结束这些事件把数据加工后写入平台的监控表再配合定时任务做超时检测。组织与权限同步。企业流程离不开组织架构但 Activiti 自带的 ACT_ID_* 身份体系一般不建议直接用。原因很简单企业内部的组织架构基本上都在统一的权限系统里维护流程平台要是自己再维护一套身份数据很快就会出现“人已经离职了流程还在给他审批”这种尴尬事。我们的方案是平台只保存一份与上游同步过来的用户、部门、角色的简化副本每次同步做全量比对增量更新审批人的解析统一通过同步数据完成。3.3 方案选型为什么继续用 Activiti没有换成别的引擎这块我多说几句。改造过程中有不少同事提过要不要干脆换掉 Activiti用 Flowable、Camunda 或者自研一套。我的建议是不要轻易换引擎。原因有三点。第一Activiti 的成熟度和社区基础在 Java 技术栈里仍然很能打BPMN 2.0 的完整支持、丰富的 API、数据库表结构设计都很稳定团队里很多开发对它已经足够熟悉。第二流程平台的核心竞争力根本不在引擎本身而在引擎之上封装的产品能力、集成能力和运维能力。换一个引擎不会让你的平台更好用反而要承担巨大的迁移和兼容成本。第三Activiti 7 的版本在扩展性和云原生适配方面都有了改进够用。所以我的建议是引擎层面稳定优先不要为了“技术新”去冒风险平台的价值要靠上层能力和工程治理来体现。4. 实操关键版本、数据库、离线插件与二次封装4.1 Activiti 数据库版本选型与表结构差异Activiti 的数据库版本问题是很多团队容易忽略的重灾区。Activiti 5.x、6.x、7.x 的 ACT_* 表结构有差异尤其涉及到历史数据和流程实例的平滑过渡绝不能拍脑袋升级。我这里列一个最简单的对照表。版本主要变化升级注意点5.x经典的 ACT_RE_/RU_/HI_/ID_ 结构早期版本大量项目使用升级需脚本迁移6.x表结构微调、JSON 支持增强与 5.x 不兼容需要完整迁移流程定义和历史数据7.x模块化重构支持 Spring Boot 2.xAPI 变化明显依赖引入方式变化大我们平台最终选的是 7.x 线。原因很简单项目技术栈是 Spring Boot 2.xActiviti 7 的 starter 集成最顺畅而且模块化做得比 6.x 清晰适合在这之上做二次开发。但这里有个很关键的坑Activiti 的自动建表机制在生产环境要关掉。在 application.yml 里配置spring: activiti: database-schema-update: false db-history-used: true history-level: audit生产环境强烈建议显式关闭 schema 自动更新由 DBA 审核脚本后手动执行。历史级别按需选择如果流程不需要精细化追溯用 audit 就够了full 级别会记录所有变量变化数据量增长非常快。4.2 关于 Activiti 数据库表的核心理解聊数据库版本有个问题绕不开Activiti 启动后自动生成的那几十张表都是干什么的如果这一层搞不清楚后面排查问题会非常被动。我通常把 Activiti 的表分成四类。资源与定义类主要是 ACT_RE_ 前缀比如 ACT_RE_PROCDEF 存流程定义信息ACT_RE_DEPLOYMENT 存部署记录。运行时数据类主要是 ACT_RU_ 前缀像 ACT_RU_EXECUTION 存执行实例信息ACT_RU_TASK 存当前待办任务ACT_RU_VARIABLE 存流程变量这类表是流程引擎运行时的核心数据会随着流程结束被清理。历史数据类主要是 ACT_HI_ 前缀流程实例历史、任务历史、活动历史、变量历史都在这里数据只会增加不会减少是需要重点做数据治理的部分。通用数据类主要是 ACT_GE_ 前缀像 ACT_GE_BYTEARRAY 存 BPMN 文件的二进制内容ACT_GE_PROPERTY 存引擎版本和 ID 生成相关的属性。理解这四类表的生命周期差异很重要运行时表要关注性能避免大量积压历史表要关注容量定期归档和清理。很多团队流程跑一段时间数据库就变慢了十有八九是历史表膨胀导致的。4.3 IDEA Activiti 插件离线安装的实践再说一个开发期很实际的问题IDEA 里 Activiti 插件离线安装。很多企业内部开发环境是不能访问公网插件市场的但画 BPMN 文件又确实需要可视化工具。这里分享一个可靠的离线安装路径。第一步找一台能上网的机器到 IDEA 插件市场下载对应版本插件包。以 Activiti BPMN visualizer 为例在插件市场页面选择与你 IDEA 版本兼容的版本号下载 .zip 格式插件包。第二步把插件包拷贝到内网开发机。第三步打开 IDEA 的 Settings进入 Plugins点击齿轮图标选择 Install Plugin from Disk选中插件包后重启 IDEA。需要特别留意的是插件版本跟 IDEA 版本有严格的兼容性装完后右下角提示插件不兼容多半是版本选错了。另外离线安装虽然省去了网络问题但插件自身的依赖不会自动补全所以尽量选择功能完整、无额外运行时依赖的插件。如果你只是需要一个轻量的查看器用 IntelliJ 自带的 Diagram 也能临时顶一顶但编辑 BPMN 还是用专门的 Activiti 插件效率高。4.4 对 Activiti 引擎做二次封装平台层对 Activiti 的封装我建议把握一个度不是所有的引擎 API 都要暴露出去而是只暴露业务真正关心的那几种能力。统一的流程发起接口、统一的审批操作接口、统一的流程查询接口这三类是最基本的。举个例子我们封装发起流程的接口时参数里包含流程定义 Key、业务单据 ID、发起人、审批变量。平台内部做这几件事根据定义 Key 获取最新版本定义、创建流程实例并绑定业务 Key、记录业务系统与流程实例的关联关系、初始化流程变量。审批操作同样如此。对外只提供一个 complete 接口内部根据当前任务节点类型做不同处理普通用户任务直接 complete会签任务处理票签逻辑网关节点自动流转。这样对业务系统来说所有审批都只有“提交”一个动作复杂度全被平台吸收了。封装的时候还要特别注意事务边界。Activiti 的操作跟业务系统的事务不在一个事务上下文里如果平台只管调引擎不考虑业务数据的一致性就会出现“业务单子成功了但流程没发起”或者反过来“流程走了一半业务数据没存上”的情况。我们的方案是提供事务模板接口业务系统在同一个事务里先写业务数据、再调用流程接口平台内部通过同步事务状态来保证数据一致。5. 实施过程中的坑与排查实录5.1 常见问题速查表这部分我整理了一份速查表都是从实际项目里总结出来的比看文档印象深得多。现象可能原因排查方法流程实例没有按预期流转排他网关条件未覆盖所有分支检查 BPMN 条件表达式与流程变量类型待办任务突然消失任务被其他节点串签/会签处理查看历史任务表追踪任务生命周期引擎启动报表不存在错误关闭了自动建表但没有初始化脚本手动执行对应版本的 create 脚本历史表数据增长很快history-level 设置过高调整级别增加定期归档任务发起流程时接口超时流程实例数过多导致引擎性能下降检查运行时表数据量、索引命中情况同一个流程实例重复发起业务系统未做幂等处理增加唯一业务 Key 与事务控制5.2 几个印象深刻的线上案例我挑两个亲历过的问题展开讲讲。第一个是流程不会自动流转的问题。现象是某条合同审批流在第一个审批节点通过之后第二个节点一直没有生成待办。我查了流程实例运行表发现执行实例确实停留在第一个网关前。后来逐行看 BPMN XML发现问题出在排他网关的条件表达式上。流程变量是一个 Integer但 BPMN 条件里写的是字符串比较类型不匹配导致条件永远为 false网关没有出口可选流程自然就卡住了。解决方式很简单统一条件表达式的类型转换规则。但这之后我在代码审查里加了一条硬性要求流程条件里的变量类型必须在流程启动时强制确认不允许隐式转换。第二个是历史数据膨胀引发的性能问题。上线三个月后有业务系统反馈流程发起接口越来越慢。查了一圈发现不是引擎本身的问题而是 ACT_HI_VARINST 表已经积压了一千多万行联合查询性能急剧下降。后来我们做了一套完整的归档方案每天定时把三个月前的历史数据迁移到归档库业务查询走归档库在线库只保留热数据。这个例子想说明的是用 Activiti 做流程平台数据库数据治理一定要前置设计不要等到线上出问题了才回头补。5.3 事务一致性和性能调优的两个经验再讲两个容易被忽视的细节。事务一致性是流程平台必须正视的问题。Activiti 内部操作有自己的事务管理如果业务系统在同一个流程操作里还要更新自己的业务表就涉及到跨数据源事务不能简单依赖 Spring 默认的本地事务。我推荐的做法是尽量保证“一个操作只写一个数据源”要么先写业务数据、成功后通过异步消息触发流程要么先发起流程、在流程回调里写业务数据。如果必须要同步强一致再考虑引入分布式事务方案但尽量避免因为复杂度太高。性能调优方面Activiti 7 的默认配置在大部分场景下是够用的但如果流程实例并发量很高有几个参数值得去调。异步执行器的核心线程数、最大线程数和队列容量决定了引擎处理异步事件的能力历史数据清理任务建议放到业务低峰期执行避免占用数据库资源。另外所有高频查询接口都要注意运行时表和历史表的索引索引缺失在数据量不大的时候没什么感觉数据量一上来就是灾难。6. 平台上线后的运维治理与演进方向6.1 监控指标与告警体系流程平台上线的第一天就要把监控体系铺起来。我的经验是分三个维度来做。第一个维度是引擎健康度。Activiti 引擎自身能不能正常工作包括引擎启动时间、异步执行器队列积压量、流程引擎数据库连接池使用率。第二个维度是流程运行指标。按流程定义维度聚合统计发起量、完成量、平均耗时、超时率。这些指标能从数据上反映哪条流程需要优化比如某条流程的平均耗时明显偏高那大概率是审批环节配置不合理或者有节点处理人缺失。第三个维度是业务异常监控。包括任务创建失败、流程实例异常结束、事件监听处理失败。告警规则不用一开始就设得很复杂先把最核心的几条配上流程实例异常终止、异步任务积压超过阈值、任务停留超过 SLA、数据库连接池耗尽。告警渠道最好能接入企业统一告警中心不要自己单独搞一套。6.2 从流程平台到流程体系的演进平台稳定运行一段时间之后可以开始思考更高一层的事情。我比较看好的方向有两个。一个是流程分析与优化。平台积累了大量的流程运行数据可以从数据里去发现流程瓶颈。比如报销流程平均要走五级审批但数据显示超过一半的审批节点耗时不到一分钟说明这些节点只是走个形式完全可以精简掉。这就是数据驱动流程优化的典型场景。另一个是流程资产化。当流程平台覆盖了企业核心业务流程之后流程本身就成了企业的数字化资产。新业务系统上线时不用再从零开始设计流程而是从平台已有的流程资产库里选择、组合、复用。这个阶段平台的价值就不只是“跑流程”了而是上升到了企业运营基础设施的层面。7. 最后的一些心里话我个人在实际项目中最大的一个体会是流程平台不是一个一次性的技术项目它更像是一个随着企业业务演化而持续生长的底座。建好一套流程架构很容易难的是让团队真正愿意把流程都沉淀到平台上来这背后涉及组织协同、权限梳理、历史系统迁移比技术本身难得多。另外还想提醒一点无论你做得多完善永远会给后续的迭代留出空间。Activiti 的版本会持续更新平台的接入规范也会不断调整一开始就把架构做死了后面反而寸步难行。保留核心抽象灵活性让新流程接入的成本尽可能低才是这套架构能长期走下去的关键。如果这篇文章里的经验能让你在规划企业流程架构升级时少走几个弯路那就值了。 企业流程架构演进：从裸用Activiti到统一流程平台
1. 从裸用 Activiti 到建设流程平台一次架构演进复盘先说背景。我过去几年带团队做过不少企业内部系统的流程模块早期项目图省事直接在业务代码里嵌 Activiti部署一个流程就塞一个流程定义所有审批逻辑都往引擎里写。前两年还好等流程数量一多、参与方一杂问题就全冒出来了流程定义散落在各个服务里、发起和审批入口五花八门、改一条流程要发版上线、跑挂一个节点连日志都找不到。到了后面光靠 Activiti 的 API 已经撑不住整个企业的流程诉求了。这篇博文就围绕一条主线怎么从“业务系统里用 Activiti”过渡到“统一的企业流程平台”。我会先复盘裸用阶段踩过的坑再讲平台化改造时的架构设计、核心模块拆分、几个关键落地细节包括 Activiti 数据库版本选型、离线插件安装这类很具体的问题最后把线上实施过程中遇到的典型故障和排查思路整理成一份速查表。如果你现在正处在“流程代码越写越多、却感觉越来越难维护”的阶段这篇文章应该能帮你看清楚问题出在哪以及从哪儿下手去做升级。2. 为什么非要从 Activiti 走向流程平台2.1 裸用 Activiti 的典型痛点先说场景。大部分团队第一次接触 Activiti都是因为业务里需要审批流。最常见的做法是在订单、报销、合同这类应用里引入 Activiti 依赖然后自己封装一层 Service谁要发起流程就调用一下谁要审批就查一下任务列表。前期只有两三条流程的时候这套玩法效率很高因为 Activiti 对 BPMN 2.0 规范的支持非常完整流程定义管理、任务分配、流程变量、历史数据它全都帮你做掉了。但随着流程数量增长几个问题会越来越明显。第一流程定义和业务系统强耦合。每条流程的 bpmn 文件放在各自工程里改了要跟着业务服务一起打包发版。哪天产品提了一句话说“合同审批的第三级审批人换成部门总监”本意是个五分钟的配置改动结果你愣是得走一次发布流程。第二执行引擎分散。好几个服务各自引入 Activiti等于跑了好几套流程引擎每个引擎维护自己的 ACT_* 表跨系统的流程协同根本做不了。第三监控和排查能力约等于零。流程实例卡在哪个节点哪个环节耗时最长有没有异常重试机制这些在裸用阶段基本靠手工翻数据库。2.2 流程平台要解决什么问题所以做流程平台本质上不是“换掉 Activiti”而是“把 Activiti 收编到平台内部”让业务系统不再各自为战。这里面的核心转变有三个。一是角色转变。原来 Activiti 是嵌在业务代码里的一个组件改造后它变成了平台层的基础引擎对外提供统一的服务能力。业务系统不再直接触碰 engine API而是走平台提供的接口。二是能力补齐。Activiti 本身解决的是流程执行问题但它不关心流程怎么设计、怎么管理、怎么监控、怎么统计。流程平台要在引擎外面补上这些能力可视化流程设计器、统一流程管理后台、流程实例监控、超时提醒、SLA 统计、组织权限同步等等。三是标准统一。所有业务流程都通过平台发起和流转流程定义统一管理任务统一处理接口统一规范。这样不管是新的审批需求还是对接外部系统都有了一套标准的接入方式而不是每个项目自己造一套轮子。3. 流程平台的整体架构设计与能力规划3.1 平台分层架构怎么定在做架构设计的时候我没有一上来就写代码而是先定了一个原则平台要跟业务系统解耦但也要让业务系统接入得足够轻。最后落地下来的分层结构大致是这样的。接入层对外提供统一的 REST API 和消息通道主要解决身份认证、参数校验、接口鉴权这些通用问题。不管是内部系统还是外部系统接入流程平台都走这一层不允许有人绕过平台直接调引擎。服务层是平台的业务核心流程定义管理、流程实例管理、任务管理、委派转办、驳回跳转、会签票签这些能力都在这一层封装对上屏蔽引擎细节。引擎层就是 Activiti负责 BPMN 解析、流程驱动、任务分配、事件触发这些标准能力。管理端是运营和配置人员的入口负责流程设计、部署、权限配置、监控告警。存储层除了 Activiti 自身的 ACT_* 表还增加了平台自己的业务表用来存流程分类、表单绑定关系、操作日志、流程与业务单据的关联关系。这个分层结构其实参考了业界做流程平台比较通用的模式。重点不在架构图本身多好看而在“边界要清晰”引擎就是引擎平台就是平台业务系统就是业务系统谁也别跨界。3.2 核心模块拆解平台化改造过程中我觉得有五个模块是必须认真做的缺一个后面都难受。流程设计器。设计器是给流程管理员用的不是给程序员用的。所以不能直接丢个 Activiti Modeler 给业务人员那样他们光画网关和事件就会懵。我们的做法是基于 bpmn-js 做了一套简化版设计器默认只暴露开始事件、用户任务、排他网关、结束事件这几种常用要素其他高级元素在高级模式下才展示。设计器最终生成标准的 BPMN 2.0 XML保存到流程定义库。流程定义管理。这个模块管的是流程的“版本、分类、状态、权限”。部署新版本的时候设置为待发布状态确认没问题再激活。已经发起的老流程继续使用旧版本新发起默认走新版本这是 Activiti 本身就支持的版本机制平台要做的就是把它合理地暴露出来。统一任务中心。每个业务系统都有一套自己的待办列表这是常态。平台要做的不是取代业务系统的待办而是提供统一的任务查询和操作接口。待办数据通过消息实时同步给业务系统业务侧只需要接收数据做展示真正的审批动作统一回写平台。实例监控与运维。这是裸用 Activiti 时最缺的能力。平台要能实时看到每个流程实例走到哪个节点、当前处理人是谁、这个节点停留多久、有没有超时告警。Activiti 的引擎事件监听器就是做这件事的抓手通过监听任务创建、任务完成、流程结束这些事件把数据加工后写入平台的监控表再配合定时任务做超时检测。组织与权限同步。企业流程离不开组织架构但 Activiti 自带的 ACT_ID_* 身份体系一般不建议直接用。原因很简单企业内部的组织架构基本上都在统一的权限系统里维护流程平台要是自己再维护一套身份数据很快就会出现“人已经离职了流程还在给他审批”这种尴尬事。我们的方案是平台只保存一份与上游同步过来的用户、部门、角色的简化副本每次同步做全量比对增量更新审批人的解析统一通过同步数据完成。3.3 方案选型为什么继续用 Activiti没有换成别的引擎这块我多说几句。改造过程中有不少同事提过要不要干脆换掉 Activiti用 Flowable、Camunda 或者自研一套。我的建议是不要轻易换引擎。原因有三点。第一Activiti 的成熟度和社区基础在 Java 技术栈里仍然很能打BPMN 2.0 的完整支持、丰富的 API、数据库表结构设计都很稳定团队里很多开发对它已经足够熟悉。第二流程平台的核心竞争力根本不在引擎本身而在引擎之上封装的产品能力、集成能力和运维能力。换一个引擎不会让你的平台更好用反而要承担巨大的迁移和兼容成本。第三Activiti 7 的版本在扩展性和云原生适配方面都有了改进够用。所以我的建议是引擎层面稳定优先不要为了“技术新”去冒风险平台的价值要靠上层能力和工程治理来体现。4. 实操关键版本、数据库、离线插件与二次封装4.1 Activiti 数据库版本选型与表结构差异Activiti 的数据库版本问题是很多团队容易忽略的重灾区。Activiti 5.x、6.x、7.x 的 ACT_* 表结构有差异尤其涉及到历史数据和流程实例的平滑过渡绝不能拍脑袋升级。我这里列一个最简单的对照表。版本主要变化升级注意点5.x经典的 ACT_RE_/RU_/HI_/ID_ 结构早期版本大量项目使用升级需脚本迁移6.x表结构微调、JSON 支持增强与 5.x 不兼容需要完整迁移流程定义和历史数据7.x模块化重构支持 Spring Boot 2.xAPI 变化明显依赖引入方式变化大我们平台最终选的是 7.x 线。原因很简单项目技术栈是 Spring Boot 2.xActiviti 7 的 starter 集成最顺畅而且模块化做得比 6.x 清晰适合在这之上做二次开发。但这里有个很关键的坑Activiti 的自动建表机制在生产环境要关掉。在 application.yml 里配置spring: activiti: database-schema-update: false db-history-used: true history-level: audit生产环境强烈建议显式关闭 schema 自动更新由 DBA 审核脚本后手动执行。历史级别按需选择如果流程不需要精细化追溯用 audit 就够了full 级别会记录所有变量变化数据量增长非常快。4.2 关于 Activiti 数据库表的核心理解聊数据库版本有个问题绕不开Activiti 启动后自动生成的那几十张表都是干什么的如果这一层搞不清楚后面排查问题会非常被动。我通常把 Activiti 的表分成四类。资源与定义类主要是 ACT_RE_ 前缀比如 ACT_RE_PROCDEF 存流程定义信息ACT_RE_DEPLOYMENT 存部署记录。运行时数据类主要是 ACT_RU_ 前缀像 ACT_RU_EXECUTION 存执行实例信息ACT_RU_TASK 存当前待办任务ACT_RU_VARIABLE 存流程变量这类表是流程引擎运行时的核心数据会随着流程结束被清理。历史数据类主要是 ACT_HI_ 前缀流程实例历史、任务历史、活动历史、变量历史都在这里数据只会增加不会减少是需要重点做数据治理的部分。通用数据类主要是 ACT_GE_ 前缀像 ACT_GE_BYTEARRAY 存 BPMN 文件的二进制内容ACT_GE_PROPERTY 存引擎版本和 ID 生成相关的属性。理解这四类表的生命周期差异很重要运行时表要关注性能避免大量积压历史表要关注容量定期归档和清理。很多团队流程跑一段时间数据库就变慢了十有八九是历史表膨胀导致的。4.3 IDEA Activiti 插件离线安装的实践再说一个开发期很实际的问题IDEA 里 Activiti 插件离线安装。很多企业内部开发环境是不能访问公网插件市场的但画 BPMN 文件又确实需要可视化工具。这里分享一个可靠的离线安装路径。第一步找一台能上网的机器到 IDEA 插件市场下载对应版本插件包。以 Activiti BPMN visualizer 为例在插件市场页面选择与你 IDEA 版本兼容的版本号下载 .zip 格式插件包。第二步把插件包拷贝到内网开发机。第三步打开 IDEA 的 Settings进入 Plugins点击齿轮图标选择 Install Plugin from Disk选中插件包后重启 IDEA。需要特别留意的是插件版本跟 IDEA 版本有严格的兼容性装完后右下角提示插件不兼容多半是版本选错了。另外离线安装虽然省去了网络问题但插件自身的依赖不会自动补全所以尽量选择功能完整、无额外运行时依赖的插件。如果你只是需要一个轻量的查看器用 IntelliJ 自带的 Diagram 也能临时顶一顶但编辑 BPMN 还是用专门的 Activiti 插件效率高。4.4 对 Activiti 引擎做二次封装平台层对 Activiti 的封装我建议把握一个度不是所有的引擎 API 都要暴露出去而是只暴露业务真正关心的那几种能力。统一的流程发起接口、统一的审批操作接口、统一的流程查询接口这三类是最基本的。举个例子我们封装发起流程的接口时参数里包含流程定义 Key、业务单据 ID、发起人、审批变量。平台内部做这几件事根据定义 Key 获取最新版本定义、创建流程实例并绑定业务 Key、记录业务系统与流程实例的关联关系、初始化流程变量。审批操作同样如此。对外只提供一个 complete 接口内部根据当前任务节点类型做不同处理普通用户任务直接 complete会签任务处理票签逻辑网关节点自动流转。这样对业务系统来说所有审批都只有“提交”一个动作复杂度全被平台吸收了。封装的时候还要特别注意事务边界。Activiti 的操作跟业务系统的事务不在一个事务上下文里如果平台只管调引擎不考虑业务数据的一致性就会出现“业务单子成功了但流程没发起”或者反过来“流程走了一半业务数据没存上”的情况。我们的方案是提供事务模板接口业务系统在同一个事务里先写业务数据、再调用流程接口平台内部通过同步事务状态来保证数据一致。5. 实施过程中的坑与排查实录5.1 常见问题速查表这部分我整理了一份速查表都是从实际项目里总结出来的比看文档印象深得多。现象可能原因排查方法流程实例没有按预期流转排他网关条件未覆盖所有分支检查 BPMN 条件表达式与流程变量类型待办任务突然消失任务被其他节点串签/会签处理查看历史任务表追踪任务生命周期引擎启动报表不存在错误关闭了自动建表但没有初始化脚本手动执行对应版本的 create 脚本历史表数据增长很快history-level 设置过高调整级别增加定期归档任务发起流程时接口超时流程实例数过多导致引擎性能下降检查运行时表数据量、索引命中情况同一个流程实例重复发起业务系统未做幂等处理增加唯一业务 Key 与事务控制5.2 几个印象深刻的线上案例我挑两个亲历过的问题展开讲讲。第一个是流程不会自动流转的问题。现象是某条合同审批流在第一个审批节点通过之后第二个节点一直没有生成待办。我查了流程实例运行表发现执行实例确实停留在第一个网关前。后来逐行看 BPMN XML发现问题出在排他网关的条件表达式上。流程变量是一个 Integer但 BPMN 条件里写的是字符串比较类型不匹配导致条件永远为 false网关没有出口可选流程自然就卡住了。解决方式很简单统一条件表达式的类型转换规则。但这之后我在代码审查里加了一条硬性要求流程条件里的变量类型必须在流程启动时强制确认不允许隐式转换。第二个是历史数据膨胀引发的性能问题。上线三个月后有业务系统反馈流程发起接口越来越慢。查了一圈发现不是引擎本身的问题而是 ACT_HI_VARINST 表已经积压了一千多万行联合查询性能急剧下降。后来我们做了一套完整的归档方案每天定时把三个月前的历史数据迁移到归档库业务查询走归档库在线库只保留热数据。这个例子想说明的是用 Activiti 做流程平台数据库数据治理一定要前置设计不要等到线上出问题了才回头补。5.3 事务一致性和性能调优的两个经验再讲两个容易被忽视的细节。事务一致性是流程平台必须正视的问题。Activiti 内部操作有自己的事务管理如果业务系统在同一个流程操作里还要更新自己的业务表就涉及到跨数据源事务不能简单依赖 Spring 默认的本地事务。我推荐的做法是尽量保证“一个操作只写一个数据源”要么先写业务数据、成功后通过异步消息触发流程要么先发起流程、在流程回调里写业务数据。如果必须要同步强一致再考虑引入分布式事务方案但尽量避免因为复杂度太高。性能调优方面Activiti 7 的默认配置在大部分场景下是够用的但如果流程实例并发量很高有几个参数值得去调。异步执行器的核心线程数、最大线程数和队列容量决定了引擎处理异步事件的能力历史数据清理任务建议放到业务低峰期执行避免占用数据库资源。另外所有高频查询接口都要注意运行时表和历史表的索引索引缺失在数据量不大的时候没什么感觉数据量一上来就是灾难。6. 平台上线后的运维治理与演进方向6.1 监控指标与告警体系流程平台上线的第一天就要把监控体系铺起来。我的经验是分三个维度来做。第一个维度是引擎健康度。Activiti 引擎自身能不能正常工作包括引擎启动时间、异步执行器队列积压量、流程引擎数据库连接池使用率。第二个维度是流程运行指标。按流程定义维度聚合统计发起量、完成量、平均耗时、超时率。这些指标能从数据上反映哪条流程需要优化比如某条流程的平均耗时明显偏高那大概率是审批环节配置不合理或者有节点处理人缺失。第三个维度是业务异常监控。包括任务创建失败、流程实例异常结束、事件监听处理失败。告警规则不用一开始就设得很复杂先把最核心的几条配上流程实例异常终止、异步任务积压超过阈值、任务停留超过 SLA、数据库连接池耗尽。告警渠道最好能接入企业统一告警中心不要自己单独搞一套。6.2 从流程平台到流程体系的演进平台稳定运行一段时间之后可以开始思考更高一层的事情。我比较看好的方向有两个。一个是流程分析与优化。平台积累了大量的流程运行数据可以从数据里去发现流程瓶颈。比如报销流程平均要走五级审批但数据显示超过一半的审批节点耗时不到一分钟说明这些节点只是走个形式完全可以精简掉。这就是数据驱动流程优化的典型场景。另一个是流程资产化。当流程平台覆盖了企业核心业务流程之后流程本身就成了企业的数字化资产。新业务系统上线时不用再从零开始设计流程而是从平台已有的流程资产库里选择、组合、复用。这个阶段平台的价值就不只是“跑流程”了而是上升到了企业运营基础设施的层面。7. 最后的一些心里话我个人在实际项目中最大的一个体会是流程平台不是一个一次性的技术项目它更像是一个随着企业业务演化而持续生长的底座。建好一套流程架构很容易难的是让团队真正愿意把流程都沉淀到平台上来这背后涉及组织协同、权限梳理、历史系统迁移比技术本身难得多。另外还想提醒一点无论你做得多完善永远会给后续的迭代留出空间。Activiti 的版本会持续更新平台的接入规范也会不断调整一开始就把架构做死了后面反而寸步难行。保留核心抽象灵活性让新流程接入的成本尽可能低才是这套架构能长期走下去的关键。如果这篇文章里的经验能让你在规划企业流程架构升级时少走几个弯路那就值了。