工作流选型专项，Camunda or flowable or？

• 2020 年 8 月 10 日
• 筆記
• ，activiti, ，Camunda, ，flowable, 工作流

1. 名词解释

1.1. BPM

Business Process Management，业务流程管理，“通过建模、自动化、管理和优化流程，打破跨部门跨系统业务过程依赖，提高业务效率和效果”。

1.2. BPMN

Business Process Modeling Notation，业务流程建模与标注，包括这些图元如何组合成一个业务流程图（Business Process Diagram）；讨论BPMN的各种的用途，包括以何种精度来影响一个流程图中的模型；BPMN作为一个标准的价值，以及BPMN未来发展的远景。

1.3. BPEL

Business Process Execution Language，意为业务过程执行语言，是一种基于XML的，用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。

1.4. XPDL

XML Process Definition Language,是由Workflow Management Coalition（简写为：WfMC）所提出的一个标准化规格，使用XML文件让不同的工作流程软件能够交换商业流程定义。XPDL被设计为图形上和语义上都满足交换用的商业流程定义，是描述BPMN图的最佳文件格式。BPEL也可以描述商业流程。但是XPDL不仅包含流程执行的描述，还包括了元素的图形信息，更适于商业流程建模。

1.5. JPDL

JBoss jBPM Process Definition Language，是构建于jBPM框架上的流程语言之一。在jPDL中提供了任务（tasks）、待处理状态 （wait states）、计时器（timers）、自动处理（automated actions）等术语，并通过图型化的流程定义，很直观地描述业务流程。

1.6. PVM

Process Virtual Machine，流程虚拟机，他的设计初衷是通过实现接口和定制插件等方式兼容多种流程定义语言和流程活动场景，为所有的业务流程定义提供一套通用API平台。那么，无论是需要对jBPM 原有流程定义语言进行扩展，或者重新实现一套专用的流程定义语言，都可以通过实现 PVM 指定的接口规范完成。

1.7. DMN

Decision Model and Notation，DMN的目的是提供一个模型决策结构，从而使组织的策略可以用图形清晰的地描绘出来，通过业务分析准确的定义，使其自动化（可选地）。

1.8. CMMN

Case Management Model and Notation，CMMN是一种图形化的符号，用于捕获工作方法，这些工作方法基于处理需要各种活动的情况，这些活动可能以不可预测的顺序执行，以响应不断变化的情况。通过使用以事件为中心的方法和案例文件的概念，CMMN扩展了可以用BPMN建模的边界，包括结构化程度较低的工作和由知识工人驱动的工作。结合使用BPMN和CMMN，用户可以涵盖更广泛的工作方法。

2. 众多工作流

2.1. JBPM（Java Business Process Management）

由JBoss公司开发，目前最高版本JPBM7，不过从JBPM5开始已经跟之前不是同一个产品了，JBPM5的代码基础不是JBPM4，而是从Drools Flow重新开始。下面要涉及的很多产品都是以JBPM4的代码为起点进行开发的。

2.2. Activiti

Alfresco软件开发，基于JBPM4，后并入OMG，目前最高版本activiti 7。Activiti5版本的时候，核心团队发生了比较大的变动（离职），activiti6的开发团队在新版本中去除了PVM，纳入了DMN，重构XML解析，BUG较多，目前主要团队致力于activiti7,5&6已经官宣不维护。

2.3. Osworkflow

完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。由opensymphony组织维护，其不遵守XPDL等业务规范，完全使用XML编排业务。面向开发人员。

2.4. Shark

靠山是Enhydra。是一个可扩展的工作流引擎框架，它包括一个完全基于 WFMC 规范的标准实现，它使用XPDL（没有任何自己新的扩展）作为自身的工作流流程定义格式。其持久层和设计器都是自己公司研发的，持久层实现采用的标准是轻量级的Enhydra DODS O/R mapping 工具，设计器可以用Enhydra JaWE 图形XPDL编辑器。

2.5. Apache ODE

轻型的、可嵌入的组件，利用组件组装成一个完整的BPM系统。关键模块包括ODE BPEL编译器、ODE BPEL运行时、ODE数据访问对象（DAOs）、ODE集成层（ILs）和用户工具。虽然挂在Apache下面，但已经年久失修。

2.6. Flowable

基于activiti6，最新的开源版本是flowable6，开发团队是从activiti中分裂出来的，修复了一众activiti6的bug，并在其基础上研发了DMN支持，BPEL支持等等。相对开源版，其商业版的功能会更强大。

2.7. Camunda

基于activiti5，所以其保留了PVM，最新版本Camunda7，开发团队也是从activiti中分裂出来的，发展轨迹与flowable相似，同时也提供了商业版。

2.8. JFlow

前身ccFlow，国产的工作流引擎，由济南驰骋公司开发维护，主打中国式的业务流程，由于是国产的软件，中文化程度比较深，业务开发也对用户比较友好。国产的开源工作流引擎还是挺多的，JFlow是其中功能比较完善的一个，同时对比activiti，流程上更加中国化，支持自定义流程跳转，加签等。其他国产工作流就不列举了。

还有很多工作流，比如ProcessMaker，SWF，oracle，Bonita，openwebflow，snaker

等，不过做BPM的话，相对于上面列举的产品还是有些缺陷，比如流程过于简单，资料过少等。

3. 关于工作流标准

BPMN是听得比较多的工作流标准，但工作流的规范其实不止一种，还有XPDL，BPML等。甚至他们的出现时间比BPMN更早，只是因为一些技术和非技术原因，BPMN2.0被普遍使用了，而非BMPN2.0规范的厂商也逐渐转移了。

以下的内容是关于规范标准之争中，BPMN2.0如何从众多规范中战胜并被普遍使用的。

3.1. BPMN1.X

在BPMN1.X里，BPMN是Business Process Modeling Notation的缩写，即业务流程建模符号，而在BPMN2.0里，BPMN变成了Business Process Model And Notation的缩写，即业务流程模型和符号，一个单词的增加却标示着BPMN本身发生了巨大的变化。

查看如下图1 timeline:

图1

其中BPMN1.0在2004年5月由BPMI组织正式发布。这个阶段WSFL和BPEL-WS都已经被发布。这三种规范中，BPMN1.0仅仅作为业务流程建模的一系列符号标准，对业务比较友好。厂商们认为统一的建模标准能够使他们围绕核心建模工具提供其他更多的价值，更加愿意接受BPMN。

但BPMN1.x只是一些建模符号，不支持元模型，不支持存储和交换，也不支持执行。2008年，BPMN1.1发布，但仍然存在这些对开发人员并不友好的缺点，XPDL、BPEL和BPDM围绕着BPMN1.x的存储、交换和执行，产生了新的竞争。

XPDL作为WfMC提出的流程定义语言规范，本身就是一个元模型，可以存储，并且具备执行语义，因此理论上来讲，将BPMN转换为XPDL就可以解决存储、交换和执行的问题。XPDL2.0于2005年10月发布，在规范里，WfMC直接将XPDL的目标定义为BPMN的XML序列化格式。2008年4月23日发布的XPDL2.1规范，直接支持BPMN1.1到XPDL2.1的转换。XPDL是面向图的，BPMN也是面向图的，因此BPMN到XPDL的转换有着天然的优势。如今有超过80个的不同公司的产品使用XPDL来交换流程定义，同时也有一些厂商在自己提供的BPMN工具中使用了XPDL作为交换和存储格式。

BPEL-WS规范在2003年4月提交给了OASIS（Organizationfor the Advancement of Structured Information Standards，结构化信息标准促进组织）并更名为WSBPEL（Web Services Business Process Execution Language）规范， 2007年4月发布WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相继加入了OASIS组织。除去政治因素，BPEL的流行还在于Web正成为分布式系统架构的平台以及SOA的雄起，SOA强调服务的分解和解耦，而BPEL则对这些WEB服务进行编制，两者密不可分。但BPMN到BPEL的转换存在着先天上的缺陷，原因是BPMN是基于图的，而BPEL是基于块的，BPEL是一个结构化（块[Block]）和非结构化（控制链和事件）的混合体。这个缺陷导致有些BPMN建模的流程无法映射到BPEL，两者的双向工程更是存在问题。这个缺陷成为人们反复诟病的对象。许多支持BPEL的产品为了解决这一问题，不得不在用户建模时做出种种限制，让用户绘制不出无法转换的模型。

而BPDM（业务流程定义元模型，Business Process Definition Metamodel）则是OMG组织自己提出来解决BPMN存储和交换问题的规范。于2007年7月形成初稿，2008年7月被OMG最终采用。BPDM是一个标准的概念定义，用来表达业务流程模型。元模型定义了用来交换的概念，关系和场景，可以使得不同的建模工具所建模出来的流程模型进行交换。BPDM超越了BPMN和BPEL所定义的业务流程建模的要素，它定义了编排和编制。

3.2. BPMN2.0

随后，BPMN2.0发布了。看图2 timeline

图2

BPMN2.0 beta1版本于2009年8月发布，BPMN2.0 beta2版本于2010年5月发布，BPMN2.0正式版本于2011年1月3日发布。BPMN2.0正式将自己更名为Business Process Model And Notation（业务流程模型和符号），相比BPMN1.x，最重要的变化在于其定义了流程的元模型和执行语义，即它自己解决了存储、交换和执行的问题，BPMN由单纯的业务建模重新回归了它的本源，即作为一个对业务人员友好的标准流程执行语言的图形化前端。BPMN2.0一出手，竞争就结束了，XPDL、BPEL和BPDM各自准备回家钓鱼。

BPMN2.0是最被广泛使用的标准，也是当前热门产品使用的标准，详情请看整理的表1：

表1

这个表格可以对一些工作流产品有一个初步印象。

4. 分表对比

4.1. 对比须知

为了方便查看汇总表格，有必要再深入展示几个开篇提到的概念：

PVM

PVM是在JBPM4的时候被纳入的，activiti5沿用，activiti团队在activiti6就已经移除了，ActivitiImpl, ProcessDefinitionImpl, ExecutionImpl, TransitionImpl 都不可用了。所有的流程定义有关的信息都可以通过BpmnModel来获得，通过org.activiti.engine.impl.util.ProcessDefinitionUtil来拿到BpmnModel。

工作流中，由于flowable是基于activiti6开发的，所以代码中也没有PVM，Camunda基于activiti5开发的，所以PVM还在，更改这个核心引擎没有绝对的好坏之分，但是由于我们的代码是基于activiti5开发的，所以对我们的代码移植是有影响的。

DMN

BPMN是OMG公司发布的工作流规范，而DMN同样是OMG公司发布规范，该规范主要用于定义业务决策的模型和图形，1.0版本发布于2015年，目前最新的是1.1版本，发布于2016年。

  BPMN主要用于规范业务流程，业务决策的逻辑由PMML等规范来定义，例如在某些业务流程中，需要由多个决策来决定流程走向，而每个决策都要根据自身的规则来决定，并且每个决策之间可能存在关联，此时在BPMN与PMML之间出现了空白，DMN规范出现前，决策者无法参与到业务中。为了填补模型上的空白，新增了DMN规范，定义决策的规范以及图形，DMN规范相当于业务流程模型与决策逻辑模型之间的桥梁。

图3图解：

图3

虽然DMN只作为工作流与决策逻辑的桥梁，但实际上，规范中也包含决策逻辑部分，同时也兼容PMML规范所定义的表达式语言。换言之，实现DMN规范的框架，同时也会具有业务规则的处理能力。

CMMN

CMMN具有与BPMN不同的基本范例。 CMMN没有顺序的流程。相反，它以某种状态对案例建模。根据状态，视情况而定，有些事情可能会处理，而有些事情可能不会。控制主要由人来执行。 CMMN是声明性的，该模型说明了要应用的内容，但没有说明如何实现它。相反，BPMN强制性地规定了流程中某些步骤必须进行的工作。对于大多数人而言，声明性建模更为复杂且较不直观。结果，CMMN模型更加难以理解。您不能简单地用手指追踪路径！

CMMN对可能的活动和活动限制进行建模。它对活动何时发生，何时必须发生以及何时不应该发生进行建模。 CMMN同样限制了流程中人员可以使用的操作范围。事例模型必须事先经过仔细考虑。重要的是要提出这一点，以应对人们经常误解的事实，即人们在案件管理方面可以做他们想做的任何事情。

CMMN和BPMN都描述了业务流程中的活动。这些标准之间的主要区别是：

1、BPMN采用绑定方法。 它提供了活动的确切顺序。提供自由度比较困难。比如加个节点、任意跳转就很麻烦。

2、CMMN采用非约束性方法，然后增加了限制。建立排序比较困难。

换句话说，原则上您可以用任何一种表示法表达大多数问题。但是，根据问题的类型，建模将在BPMN或CMMN中更好地工作，并且这些标准之一更可能产生整洁有效的模型。

使用CMMN的指标包括：

1、无需序列：如果序列无关紧要，并且可以按任何顺序执行任务，则这将在BPMN中产生过多的连接-临时建模。也许使用临时子流程可以避免混乱。

2、活动取决于条件：定义条件是CMMN的强项。可以定义许多任务，但是它们只能在某些情况下起作用。例如，这种情况可能是订单超过一定数量或客户具有VIP身份；其他已完成的任务也会影响条件。可选因素和数据相关因素的这种组合不能在BPMN中反映出来。

3、专用计划阶段：由于能够处理任意任务，CMMN可以适应一个计划阶段，在该阶段中，一个工人计划一个案例并启用任务。 其他工人将不得不遵守计划。 BPMN不能做任何事情。

包括BPMN标准，这三个标准都是由OMG提出的。多数机构认为DMN和CMMN是工作流发展趋势。

4.2. 对比表格

经过第二个章节的比较，我从支持的标准和社区活跃度表现比较好的工作流中筛选出几个选项进行进一步对比，如表2：

表2

特别说明：

1. 源码活跃度：从分支数，提交数，参与者，最近提交时间等判断

2. Drools Flow (process/workflow)：该工作流引擎是Drools下的一个项目，JBPM的规则引擎正是Drools，由于activiti开发自JBPM4，所以activiti，flowable以及Camunda都有Drools的影子。

3. 空白处或者小短杆表示的代表的暂时未查证的内容

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

5. 性能

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

5.1. 概述

以下内容来自：

//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。

为了得到更多的性能数据，接下来从各个官网寻找材料。

5.2. Camunda

//camunda.com/products/performance/

该地址没有描述具体的性能，但是列举了一些措施，表示做了性能考虑：

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

2. 避免死锁：采用乐观锁；用户思考期间不持有锁；批量刷新数据

3. 控制保存点：在一个事务中保存多个活动

4. 智能缓存：使用一级缓存，减少查询

5. 并行：并行任务在数据库中表现为不同行，实现真正并行

6. 集群：多节点共用数据库

7. 最小资源占用：流程引擎无状态，每个节点只需要分配少于10M的缓存，所以支持大批量任务在节点上运行

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

5.3. Flowable

//flowable.com/open-source/docs/bpmn/ch18-Advanced/#async-executor

这里没有特别介绍提升性能的设计，但一些角落有提到，对性能是否提升未知：

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

2.数据库的批量插入

3.async executor：异步执行器，能解决背压，但是对性能的提升程度未知

5.4. JBPM7

//jbpm.org/learn/jbpmPerformance.html

这里也没有介绍性能的具体情况。但提供了检测性能的方法，指明了不跟任何工作流作对比，言辞谨慎。官网给的例子仍然可以作为参考数据，翻译如下：

客户端：jmeter

版本：社区版 7.8

硬件：

Macos 10.14.4

Cpu i7 2.3GHZ

Memory 16GB

Db Postgre

测试内容：三个简单的流程，我做了简单的表格继承他的测试结果；（利用执行1000个实例用时得出TPS）

5.5. Activiti 7

//activiti.gitbook.io/activiti-7-developers-guide/

有提到一些提升查询性能的地方，但是不明确。

5.6. JFlow

未提及性能

6. 总结

大致总结以下调研的总体感受。Activiti7相对于5和6没有太多功能上的变化，主要致力于一些辅助功能，对接一些基础技术。比如云原生，ELK，spring cloud。分布式的应用或许会对性能有一定的提升。

Flowable的NoSql方案和消息队列比较特别，同时对DMN和CMMN的研究也比较多，是个不错的选择。

JBPM近年来新的文档少一些，应用和二次开发可能会比较吃力。JFlow功能比较齐全，而且中文化的设计器对开发人也和业务人也都比较友好，但是他的材料基本限于官网，后期不会保障。

Camunda BPM支持的功能比较多，对DMN和CMMN的支持也是推出最早的，性能上看起来也做了比较多的应对，虽然商业版的推出减少了开源版的维护，但仍然是几个竞品中综合看起来比较符合当前需求的，PVM的保留也会使得迁移比较顺滑，具体使用情况还需要进一步尝试，比较推荐。（如果不是旧产品迁移其实需要更多选择，框架改革的优化是可以考虑在内的，根据需求选择）

7. 一些参考网址

//github.com/qiudaoke/flowable-userguide/blob/master/%E6%A1%86%E6%9E%B6bug%E5%88%97%E8%A1%A8/bug.txt 《Flowable 6.5未修复bug列表》  

//flowable.com/blog/2016/09/decision-model-and-notation-dmn-how-to-start-a-project-2/  《decision-model-and-notation-dmn-how-to-start-a-project-2》

//blog.camunda.com/post/2016/10/migrate-from-activiti-to-camunda/ 《How to migrate from Activiti 5.21 to Camunda BPM 7.5》

//www.bpm-guide.de/2015/09/28/why-bpmn-is-not-enough/ 《Why BPMN is not enough》