别再纠结了！实战项目告诉你，为什么我们最终选择了Camunda而不是Flowable

从Activiti到Camunda：一个中型OA系统的流程引擎选型实战

去年我们团队接手了一个中型企业OA系统的升级项目，原系统使用的是已经停止维护的Activiti 5.x版本。随着业务复杂度提升和用户量增长，老系统在高并发场景下频繁出现性能瓶颈，历史数据迁移也成了老大难问题。经过三个月的技术评估和POC验证，我们最终选择了Camunda 7.17作为新一代流程引擎。这篇文章将分享我们在选型过程中遇到的实际问题、性能测试数据以及最终决策的关键因素。

1. 技术选型的背景与挑战

我们的OA系统日均流程实例量约5万条，高峰期并发请求可达800TPS。旧系统主要面临三大痛点：

• 历史数据迁移困境：Activiti 5.x的数据库Schema与新版引擎存在显著差异，特别是历史表结构的变化导致迁移脚本需要大量重写
• 高并发稳定性问题：在月度报表生成期间，经常出现数据库死锁（Deadlock）和长事务超时
• 扩展性不足：原系统缺乏对动态流程变更的支持，每次业务规则调整都需要重新部署流程定义

在技术调研阶段，我们重点评估了Flowable 6.8和Camunda 7.17这两个同源分支。测试环境采用相同配置：

服务器配置：8核CPU/32GB内存/SSD存储 数据库：MySQL 8.0集群 压力测试工具：JMeter 5.4.1

2. 核心功能对比实测

2.1 流程实例管理能力

在POC阶段，我们模拟了三种典型业务场景进行功能验证：

场景一：跨版本流程迁移

-- Camunda原生支持的实例迁移API UPDATE ACT_RU_EXECUTION SET PROCESS_DEF_ID_ = 'newVersion:1' WHERE PROC_INST_ID_ IN ('instance1','instance2');

对比发现：

• Camunda支持运行时实例的版本热切换
• Flowable需要手动处理任务节点映射关系

场景二：批量任务处理

// Camunda批量挂起流程实例的API示例 runtimeService.updateProcessInstanceSuspensionState() .byProcessInstanceQuery(processInstanceQuery) .suspendAsync(); // 支持异步执行

性能测试数据：

2.2 高并发处理机制

我们使用JMeter模拟了用户集中提交请假审批的场景：

测试参数：

线程组：800并发用户 Ramp-up：1分钟 循环次数：10次 断言响应时间：<3秒

关键发现：

1. 在600并发时，Flowable开始出现死锁警告：

   Deadlock found when trying to get lock; try restarting transaction

2. Camunda通过优化锁机制保持稳定，平均响应时间比Flowable快18%

重要提示：Camunda的异步批处理特性在高并发场景下表现尤为突出，建议开启skipCustomListeners参数避免监听器阻塞主线程

3. 系统集成实践

3.1 与BPMN设计器的整合

前端采用Vue3+BPMN.js的组合方案时，两个引擎的对接体验差异明显：

• Camunda：

  • 提供完整的TypeScript类型定义
  • 支持属性面板扩展的预设配置

• Flowable：

  • 需要手动适配bpmn-js的扩展点
  • 部分属性绑定需要额外开发适配层

集成效率对比：

3.2 历史数据处理方案

针对旧系统的历史数据，我们最终采用的迁移方案：

1. 数据清洗阶段：

   # 使用Pandas处理Activiti历史表数据 df = pd.read_sql('SELECT * FROM ACT_HI_TASKINST', con=engine) df['DURATION_'] = df['END_TIME_'] - df['START_TIME_']

2. 数据转换阶段：

   -- Camunda历史表结构优化 INSERT INTO ACT_HI_ACTINST (ID_, PROC_DEF_ID_, PROC_INST_ID_, ACT_ID_, ACT_NAME_) SELECT UUID(), 'processDefV2', PROC_INST_ID_, TASK_DEF_KEY_, NAME_ FROM ACT_HI_TASKINST;

3. 验证阶段：
   • 使用Camunda的历史数据查询API确保数据一致性

4. 生产环境调优建议

经过半年生产验证，我们总结出这些关键配置参数：

数据库连接池配置（application.yml）：

camunda: bpm: database: schema-update: false table-prefix: ACT_ jdbc: max-active: 50 min-idle: 10 max-wait: 30000

异步执行调优：

<!-- bpmn流程定义示例 --> <serviceTask id="externalTask" camunda:type="external" camunda:topic="creditCheck" camunda:asyncBefore="true" camunda:exclusive="false"/>

监控指标配置：

// 启用Prometheus监控 @Bean public ProcessEnginePlugin metricsPlugin() { return new MetricsProcessEnginePlugin() .setDbMetricsReporterActivate(true) .setTaskMetricsEnabled(true); }

在实际运行中，这些配置使系统在800TPS压力下保持CPU利用率低于70%，平均响应时间稳定在1.2秒以内。特别值得注意的是Camunda的历史数据自动清理机制，通过定时任务自动归档旧数据，使主表数据量始终控制在性能最优区间。