市场上比较有名的开源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。其中:Jbpm4、Activiti、Flowable、camunda四个框架同宗同源,祖先都是Jbpm4,开发者只要用过其中一个框架,基本上就会用其它三个。低代码平台、办公自动化(OA)、BPM平台、工作流系统均需要流程引擎功能,对于市场上如此多的开源流程引擎,哪个功能和性能好,该如何选型呢?

一、主流开源流程引擎介绍

1、Osworkflow

Osworkflow是一个轻量化的流程引擎,基于状态机机制,数据库表很少,Osworkflow提供的工作流构成元素有:步骤(step)、条件(conditions)、循环(loops)、分支(spilts)、合并(joins)等,但不支持会签、跳转、退回、加签等这些操作,需要自己扩展开发,有一定难度,如果流程比较简单,osworkflow是很好的选择,但该开源组件已过时,长时间没有版本升级了。

官方网站:http://www.opensymphony.com/osworkflow/

2、JBPM

JBPM由JBoss公司开发,目前最高版本JPBM7,不过从JBPM5开始已经跟之前不是同一个产品了,JBPM5的代码基础不是JBPM4,而是从Drools Flow重新开始,基于Drools Flow技术在国内市场上用的很少,所有不建议选择jBPM5以后版本,jBPM4诞生的比较早,后来JBPM4创建者Tom Baeyens离开JBoss后,加入Alfresco后很快推出了新的基于jBPM4的开源工作流系统Activiti, 另外JBPM以hibernate作为数据持久化ORM也已不是主流技术,现在时间节点选择流程引擎,JBPM不是最佳选择。

官方网站:https://www.jbpm.org/

3、Activiti

activiti由Alfresco软件开发,目前最高版本activiti 7。activiti的版本比较复杂,有activiti5、activiti6、activiti7几个主流版本,选型时让人晕头转向,有必要先了解一下activiti这几个版本的发展历史。activiti5和activiti6的核心leader是Tijs Rademakers,由于团队内部分歧,在2017年时Tijs Rademakers离开团队,创建了后来的flowable, activiti6以及activiti5代码已经交接给了 Salaboy团队, activiti6以及activiti5的代码官方已经暂停维护了, Salaboy团队目前在开发activiti7框架,activiti7内核使用的还是activiti6,并没有为引擎注入更多的新特性,只是在activiti之外的上层封装了一些应用。结论是activiti谨慎选择。

官方网站:https://www.activiti.org/

4、flowable

flowable基于activiti6衍生出来的版本,flowable目前最新版本是v6.6.0,开发团队是从activiti中分裂出来的,修复了一众activiti6的bug,并在其基础上研发了DMN支持,BPEL支持等等,相对开源版,其商业版的功能会更强大。以flowable6.4.1版本为分水岭,大力发展其商业版产品,开源版本维护不及时,部分功能已经不再开源版发布,比如表单生成器(表单引擎)、历史数据同步至其他数据源、ES等。Flowable 是一个使用 Java 编写的轻量级业务流程引擎,使用 Apache V2 license 协议开源。2016 年 10 月,Activiti 工作流引擎的主要开发者离开 Alfresco 公司并在 Activiti 分支基础上开启了 Flowable 开源项目。基于 Activiti v6 beta4 发布的第一个 Flowable release 版本为6.0。Flowable 项目中包括 BPMN(Business Process Model and Notation)引擎、CMMN(Case Management Model and Notation)引擎、DMN(Decision Model and Notation)引擎、表单引擎(Form Engine)等模块。

官方网站:https://flowable.com/open-source/

5、Camunda

Camunda基于activiti5,所以其保留了PVM,最新版本Camunda7.15,保持每年发布2个小版本的节奏,开发团队也是从activiti中分裂出来的,发展轨迹与flowable相似,同时也提供了商业版,不过对于一般企业应用,开源版本也足够了,强烈推荐camunda流程引擎,功能和性能表现稳定。

选择camunda的理由:

(1)通过压力测试验证Camunda BPMN引擎性能和稳定性更好。

(2)功能比较完善,除了BPMN,Camunda还支持企业和社区版本中的CMMN(案例管理)和DMN(决策自动化)。Camunda不仅带有引擎,还带有非常强大的工具,用于建模,任务管理,操作监控和用户管理,所有这些都是开源的。

官方网站:https://docs.camunda.org/manual/7.15/introduction/

二、flowable与Camunda对比分析

1、功能方面对比

由于Flowable与Camunda好多功能都是类似的,因此在这里重点罗列差异化的功能

(1)camunda支持流程实例的迁移,比如同一个流程有多个实例,多个流程版本,不同流程实例运行在不同的版本中,camunda支持任意版本的实例迁移到指定的流程版本中,并可以在迁移的过程中支持从哪个节点开始。

(2)camunda基于PVM技术,所以用户从Activii5迁移到camunda基本上毫无差异。flowable没有pvm了,所以迁移工作量更大(实例的迁移,流程定义的迁移、定时器的迁移都非常麻烦)。

(3) camunda对于每一个CMD命令类都提供了权限校验机制,flowable没有。

(4)camunda继续每一个API都有批处理的影子,flowable几乎没有。比如批量挂起流程、激活流程等,使用camunda可以直接使用API操作,使用Flowable则只能自己去查询集合,然后循环遍历集合并操作。

(5)camunda很多API均支持批处理,在批量处理的时候可以指定是异步方式操作或者是同步方式操作。异步的话定时器会去执行。Flowable没有异步批处理的机制。比如批量异步删除所有的历史数据。

(6)camunda启动实例的时候支持从哪个节点开始,而不是仅仅只能从开始节点运转实例。Flowable仅仅只能从开始节点运转实例。

(7)camunda支持任意节点的跳转,可以跳转到连线也可以跳转到节点,并且在跳转的过程中支持是否触发目标节点的监听器。flowable没有改原生API需用户去扩展。

(8)camunda支持双异步机制,第一个异步即节点可以异步执行,第二个异步方式是:完成异步任务后,还可以继续异步去执行任务后面的连线。所以称之为双异步机制,flowable只有第一种异步方式。

(9)camunda支持多种脚本语言,这些脚本语言可以在连线上进行条件表达式的配置,开箱即用。比如python、ruby、groovy、JUEL。flowable仅仅支持JUEL、groovy。开箱即用的意思就是如果想用python直接引入jython包就可以用了,不需要额外配置。

(10)camunda支持外部任务,比如我们有时候想在一个节点中执行调用第三方的API或者完成一些特定的逻辑操作,就可以使用外部任务,外部任务有两种表,并支持第三方系统定期来抓取并锁定外部任务,然后执行业务完毕之后,完成外部任务,流程实例继续往下执行。外部任务的好处就是解决了分布式事物的问题。在flowable中我们可以使用httpTask任务,我个人更倾向于camunda外部任务,因为这个外部任务有外部系统决定什么时候完成,httpTask是不等待任务,实例走到这个节点之后,调用一个api就直接往下跑了,外部任务不会继续往下跑,有外部系统去决定啥时候往下跑。

(11)camunda支持为用户定制一些个性化的偏好查找API,比如张三每次查询任务的时候,一般固定点击某某三个查询条件过滤数据,使用camunda就可以将这三个查询条件进行持久化,下次张三来了,就可以直接根据他的偏好进行数据的过滤,类似机器学习。

(12)camunda支持历史数据的批量删除或者批量迁移到其他介质,比如批量迁移到es,flowable没有该机制。

(13)camunda支持在高并发部署流程的时候,是否使用锁机制,flowable没有该机制。

(14) camunda支持单引擎多组合、多引擎多库。flowable仅仅支持单引擎多组合。

(15) camunda支持流程实例跨流程定义跳转,flowable没有该机制。

(16) camunda支持分布式定时器,flowable没有该机制。

(17) flowable支持nosql,camunda只有nosql的解决方案。

(18)camunda支持优化流程,以及了解流程引擎的瓶颈所在和每个环节的耗时,flowable没有该机制。

(19) camunda修改了流程模板xml解析方式,相比flowable性能更好。

(20)camunda在解析流程模板xml的时候,去除了activiti5的双解析机制,相对而言耗时时间更短。flowable没有了pvm所以规避了双解析机制。

(21)camunda可以在任意节点添加任意的属性,flowable原生API没有,需要自己扩展。

(22)camunda框架没有为流程生成图片的API(所有流程图展示以及高亮均在前端动态计算),activiti5/6/flowable5/flowable6有图片生成以及高亮的API.

(23)camunda可以在节点中定义定时作业的优先级,也可以在流程中进行全局优先级的定义。当节点没有定义优先级的时候可以使用全局的优先级字段。activiti5/6/flowable5/flowable6没有改功能。

(24)camunda可以再流程中定义流程的tag标记,activiti5/6/flowable5/flowable6没有改功能。

(25)camunda/activiti5/6/flowable5/flowable6 均不支持国产数据库,比如人大金仓 和 达梦。

(26)flowable6支持LDAP,openLDAP,camunda不支持。activiti5不支持。

2、性能方面对比

笔者通过flowable和camunda多组对比测试,camunda性能比flowablet提升最小10%,最大39%,而且camunda无报错,flowable有报错,camunda在高并发场景下稳定性更好。

性能测试详细文章见:https://lowcode.blog.csdn.net/article/details/109030329

三、选型推荐

推荐大家使用camunda(流程引擎)+bpmn-js(流程设计器)组合,笔者在公司项目中经过实战验证,camunda在功能方面比flowable、activiti流程引擎强大,性能和稳定性更突出。

Logo

秉承“创新、开放、协作、共享”的开源价值观,致力于为大规模开源开放协同创新助力赋能,打造创新成果孵化和新时代开发者培养的开源创新生态!支持公有云使用、私有化部署以及软硬一体化私有部署。

更多推荐