1. 综合对比

对比项 Activiti 7 Flowable 6 Camunda bpm JBPM 7 JFLOW
功能
会签 √ √ √ √ √
回退 × √ √ - √
驳回 × √ √ √ √
自定义流转 × × √ - √
加签、减签 × √ √ - √
多实例 √ √ √ √ √
事务子流程 √ √ √ √ √
版本迁移 × × √ × ×
兼容性及二次开发
支持的流程格式 BPMN2.0、XPDL、PDL BPMN2.0、XPDL、XPDL BPMN2.0、XPDL、XPDL BPMN2.0 BPMN2.0
开源情况 开源 提供商业和开源版 提供商业和开源版 开源 开源
开发基础 jBPM4 Activiti 5 & 6 Activiti 5 版本5之后Drools Flow 自开发
直接支持的脚本 JUEL、groovy JUEL、groovy python、ruby、groovy、JUEL - -
引擎核心（跟代码兼容有关） 去除PVM 去除PVM 流程虚拟机（PVM）（迁移上有优势） Drools 自研
Spring结合 √ √ √ √ √
二次开发难度 一般 一般 一般 较难 一般
未来拓展
CMMN支持 × √ √ × ×
DMN支持 √ √（6.4之前不稳定） √ √ ×
历史数据处理（NoSql） × √ √（只提供了解决方案） - ×
支持数据库 Oracle、SQL Server、MySQL Oracle、SQL Server、MySQL、postgre Oracle、SQL Server、MySQL、postgre Mysql，postgre oracle,sqlserver,mysql
集群部署 √ √（6.5版本支持） √ √ √
云部署 √ - √ - √
其他特性
持久化框架 Mybatis JPA二次封装 Hibernate JPA -
架构 spring boot 2 spring boot 1.5 spring boot 2 Kie spring boot 2(特别版本)
事务管理 MyBatis机制/Spring事务控制 hibernate机制/Spring事务控制 hibernate机制/Spring事务控制 Bitronix，基于JTA事务管理 -
分布式事务 MyBatis机制/Spring事务控制 - 补偿机制，SAGA 模式 Bitronix，基于JTA事务管理 -
开发手册 https://activiti.gitbook.io/activiti-7-developers-guide/
部分网页打不开		 http://www.shareniu.com/flowable6.5_zh_document/bpm/index.html https://docs.camunda.org/manual/7.13/user-guide/ https://docs.jboss.org/jbpm/release/7.40.0.Final/jbpm-docs/html_single/ http://ccbpm.mydoc.io/
运行模式 独立运行和内嵌 - 独立运行和内嵌 - 独立运行和内嵌
源码活跃度 相对活跃 相对活跃 比较活跃 相对活跃 一般
源码地址 https://github.com/Activiti/Activiti https://github.com/flowable/flowable-engine https://github.com/camunda/camunda-bpm-platform https://github.com/kiegroup/jbpm https://gitee.com/opencc/JFlow
设计器 集成idea eclipse，web 自提供，eclipse 自提供，eclipse Eclipse 自提供，.net开发
集成接口 SOAP、Mule、RESTful SOAP、Mule、RESTful SOAP、Mule、RESTful 消息通讯 SOAP、Mule、RESTful
内部服务通讯 Service间通过API调用 Service间通过API调用 Service间通过API调用 基于Apache Mina异步通讯 -

特别说明：

  1. 源码活跃度：从分支数，提交数，参与者，最近提交时间等判断。
  2. Drools Flow (process/workflow)：该工作流引擎是Drools下的一个项目，JBPM的规则引擎正是Drools，由于activiti开发自JBPM4，所以activiti，flowable以及Camunda都有Drools的影子。
  3. 空白处或者小短杆表示的代表的暂时未查证的内容。

  4. 另外要说明的是，表格中支持的功能需要有不少部分需要认真探讨，比如Camunda宣称支持各种功能，以及Nosql存储，但实际上，其支持的回退，撤回都是通过一个跳转实现的，要打折扣，NoSql也只是提供了解决方案，要自己实现噢，后面一篇文章会再提及。

    2. 性能比较

    关于工作流性能比较的文章比较少（少得可怜），因为没有直接的数据能够对比工作流之间的性能，所以独立出一章介绍，基本情况：

    2.1. 概述

    以下内容来自：
    http://www.bpm-guide.de/2016/06/12/scientific-performance-benchmark-of-open-source-bpmn-engines/ 《Scientific performance benchmark of open source BPMN engines》
    据说是16年的一份科学性能报告，可惜性能报告中，除了Camunda外，其他两种被对比的WFMS产品名称并没有写出来，所以这个报告只能作为参考：
    “In general, we may conclude that Camunda performed better and more stable for all metrics when compared with WfMS A and WfMS B.”
    “WfMS A and Camunda share many architectural similarities because Camunda was originally a fork of WfMS A.”暗指WfMS A是activiti。
    为了得到更多的性能数据，接下来从各个官网寻找材料。
    bpm.jpg

    2.2. Camunda

    官网：https://camunda.com/products/performance/
    该地址没有描述具体的性能，但是列举了一些措施，表示做了性能考虑：

  5. 紧凑型表：减少必要的存储数据，在最好的例子中，修改一个活动只需要更新一条数据。

  6. 避免死锁：采用乐观锁；用户思考期间不持有锁；批量刷新数据。
  7. 控制保存点：在一个事务中保存多个活动。
  8. 智能缓存：使用一级缓存，减少查询。
  9. 并行：并行任务在数据库中表现为不同行，实现真正并行。
  10. 集群：多节点共用数据库。
  11. 最小资源占用：流程引擎无状态，每个节点只需要分配少于10M的缓存，所以支持大批量任务在节点上运行。

  12. 分库：历史库和运行库是分开的，原则上，历史数据可以转移到任何大数据产品上。

    2.3. Flowable

    官网：https://flowable.com/open-source/docs/bpmn/ch18-Advanced/#async-executor
    这里没有特别介绍提升性能的设计，但一些角落有提到，对性能是否提升未知：

  13. 额外写了UUID id生成器，解决并发的bug，但其实不一定能提升性能。

  14. 数据库的批量插入。
  15. async executor：异步执行器，能解决背压，但是对性能的提升程度未知。

    2.4. JBPM7

    官网：https://jbpm.org/learn/jbpmPerformance.html
    这里也没有介绍性能的具体情况。但提供了检测性能的方法，指明了不跟任何工作流作对比，言辞谨慎。官网给的例子仍然可以作为参考数据，翻译如下：
  • 客户端：jmeter
  • 版本：社区版 7.8
  • 硬件：
    • Macos 10.14.4
    • Cpu i7 2.3GHZ
    • Memory 16GB
    • Db Postgre
  • 测试内容：三个简单的流程，我做了简单的表格继承他的测试结果；（利用执行1000个实例用时得出TPS） | 单位：TPS | 单线程 | 四线程 | 八线程 | | —- | —- | —- | —- | | 简单脚本任务 | 91 | 240 | 361 | | 简单用户任务 | 16 | 52 | 72 | | 用户任务+并行脚本任务 | 11 | 45 | 70 |

2.5. Activiti 7

https://activiti.gitbook.io/activiti-7-developers-guide/
有提到一些提升查询性能的地方，但是不明确。

2.6. JFlow

未提及性能

3. 总结

大致总结以下调研的总体感受。Activiti7相对于5和6没有太多功能上的变化，主要致力于一些辅助功能，对接一些基础技术。比如云原生，ELK，spring cloud。分布式的应用或许会对性能有一定的提升。
Flowable的NoSql方案和消息队列比较特别，同时对DMN和CMMN的研究也比较多，是个不错的选择。
JBPM近年来新的文档少一些，应用和二次开发可能会比较吃力。JFlow功能比较齐全，而且中文化的设计器对开发人也和业务人也都比较友好，但是他的材料基本限于官网，后期不会保障。
Camunda BPM支持的功能比较多，对DMN和CMMN的支持也是推出最早的，性能上看起来也做了比较多的应对，虽然商业版的推出减少了开源版的维护，但仍然是几个竞品中综合看起来比较符合当前需求的，PVM的保留也会使得迁移比较顺滑，具体使用情况还需要进一步尝试，比较推荐。（如果不是旧产品迁移其实需要更多选择，框架改革的优化是可以考虑在内的，根据需求选择）

参考

语雀：工作流选型
https://www.yuque.com/u404260/lo1738/vyy111