开源工作流BPM比较

开源工作流BPM比较

24-01-12

banq

本文的分析是在 jBPM 7.7、Camunda 7.17.0、Flowable 6.7.2 和 Activiti 7.3.10上进行的：

本文将概述工作流、BPM 以及 BPM 产品支持的一些行业标准符号。接下来，本文将介绍 BPM 替代方案以及何时应该使用其中一种，以及可扩展性注意事项。最后，深入探讨了四个开源 BPM 项目：jBPM、Camunda、Activiti 和 Flowable。本文将把这四个维度与这三个维度进行比较：

开源模型（即社区与企业）

能力集

社区活动

什么是工作流程？工作流通常是一个含义过多的术语。根据其使用的上下文，它至少可以具有三种不同的含义。在基本层面上，工作流是业务流程的离散步骤的结构化流程。工作流程的一种形式是人工工作流程。例如，某人正在调查案件或将申请发送给另一个小组进行审查。工作流程的第二种形式是系统编排。可能存在需要以特定顺序调用一组API来完成仅涉及系统步骤的业务流程。第三种类型的工作流程涉及人工和系统编排的混合。通常，系统编排可能会遇到错误场景，或者可能需要审查某些内容以进行进一步研究。从这三个示例中，您可以看出了解工作流上下文的重要性，因为它可以具有不同的含义。

工作流的特征也可能具有不同的复杂程度。工作流程分为两类：简单的和复杂的。以下是每个的一些特征：

简单的工作流程

任务管理——考虑用户的待办事项列表

通知——通过电子邮件或短信提醒用户

状态管理——项目的状态，例如未开始、进行中或完成

单个组中的用户数量较少 - 没有跨团队或部门协调

复杂的工作流程：（包括所有简单特征以及以下特征）

许多组/用户 -跨越许多部门或部门

多层次的工作流程——各种分支和路径

异常路径、回调——错误处理并根据条件返回到之前的步骤

案件管理——不可预测的临时调查类型活动；根据条件可以使用一个或多个工作流程

与规则集成- if/then 键入业务或政策决策的逻辑

与系统编排集成——人工工作流程和系统工作流程的结合

什么是 BPM 产品？BPM 产品的核心是提供管理业务流程的模型的可视化建模和执行。它们通常提供与各种适配器的附加集成功能。类似的名称还有业务流程管理系统 (BPMS) 或智能业务流程管理系统 (iBPMS)。其他类别的产品可能只提供建模，但 BPM/BPMS/iBPMS 产品同时提供建模和执行。开源环境可能会令人困惑，因为有 20 多种产品提供不同级别的功能

行业标准符号开源 BPM 产品支持的一个常见主题是对象建模组 (OMG) 实施的一些行业标准符号。共有三种行业标准符号：BPMN、CMMN 和 DMN。让我们更详细地了解每一个。

1、BPMN — 业务流程建模符号BPMN 于 2004 年首次发布，为业务流程建模提供了行业标准。它很重要，因为它使 BPMN 视觉模型可移植，这意味着在一个应用程序中构建的 BPMN 图可以在另一个应用程序中使用（只要该工具没有在其上覆盖任何专有项目）。它还鼓励商业和技术合作。通常，您可以让熟悉 BPMN 的业务分析师创建一个业务流程，然后将其交给他们的技术合作伙伴以在 BPM 产品中实施。

2、DMN：决策建模符号在业务流程中，您通常需要 if/then 逻辑来做出业务决策。这就是 DMN 派上用场的地方。它于 2015 年首次发布，为与 BPMN 兼容的业务规则和决策提供了行业标准符号。

3、CMMN — 案例管理建模符号第三种类型的行业标准建模符号是 CMMN，它于 2014 年首次发布。案例管理通常与标准工作流程不同，因为它本质上是临时性和调查性的，而且是不可预测的。

何时使用 BPM 产品？虽然 BPM 产品非常擅长以可视化方式解决多个工作流程问题，但您可能并不总是需要如此丰富的功能。在某些情况下，基于配置的轻量级解决方案可能更适合。以下是状态机的一些示例：

AWS Step Functions（工作流工作室）。提供了一种在 AWS 中编排 lambda 函数的方法。还提供了可视化建模器（不支持 BPMN）

X状态。基于 JSON 的状态机，可用于实现工作流程

Conductor (Netflix)可用于面向微服务的系统编排

现在您可能想知道，我什么时候应该使用 BPM 产品？一般经验法则是，当在模型中可视化构建工作流比在代码或配置中更容易构建时，请使用 BPM 产品。用例通常属于两个维度：集成程度和业务流程的复杂性。需要高度集成和/或高复杂性的业务流程通常是 BPM 产品的最佳选择。

单体架构、微服务和可扩展性注意事项使用 BPM 产品时需要注意的一个方面是确保您没有在其中构建整体应用程序。做到这一点很容易，因为产品通常提供开发应用程序所需的大量工具。此外，一些 BPM 产品本身就是整体部署。我们稍后将讨论这一点，因为许多开源 BPM 产品正在转向基于云原生微服务的部署模型。

一个关键的考虑因素是要有意识地了解您在 BPM 产品内部构建了哪些内容以及将哪些内容保留在 BPM 产品之外。我通常建议您仅将 BPM 产品用于其擅长的领域——工作流程。将其他所有内容保留在产品外部，并使用各种适配器来构建与工作流程的集成。

努力实现的一个关键目标是在使用 BPM 产品时构建微服务。实现此目的的一种方法是将流程分解为子流程，并将每个子流程部署为自己的微服务，以使其更具可扩展性。

另一个可扩展性考虑因素是评估 BPM 引擎的部署方法。通常有两种方法：进程内/嵌入模式或独立模式。这些方法各有利弊。

进程内/嵌入式模式

在进程内/嵌入模式下，BPM 引擎作为应用程序的一部分在同一 JVM 下运行。这种方法提供了高性能，因为应用程序和 BPM 引擎之间没有任何网络调用。然而，它在两者之间造成了紧密耦合。它还可能使扩展变得更加困难，因为要扩展 BPM 引擎，您还需要扩展应用程序。

独立模式

在独立模式下，BPM 引擎作为其自己的独立服务进行部署，应用程序通过 API 调用与其集成。这将 BPM 引擎与应用程序解耦，并允许每个引擎独立扩展。一个缺点是，由于应用程序和 BPM 引擎之间的网络 API 调用，它可能会提供较低的性能。

开源 BPM 比较现在我们已经介绍了很多背景和上下文，让我们开始仔细研究一些开源 BPM 产品。首先，让我们看一下开源 BPM 的一些历史性里程碑，特别关注那些基于 jBPM 重写（即 Activiti）或 jBPM 分支（即 Camunda、Flowable）的里程碑

jBPMjBPM 于 2003 年推出，是第一个推向市场的开源 BPM 产品。它是唯一的开源 BPM 产品大约七年时间，直到 2010 年 Activiti 推出。三年后的 2013 年，Camunda 从 Activiti 中分叉出来。然后在 2017 年，Flowable 通过从 Activiti 中分叉而诞生。当每个产品分叉时，架构的某些部分被重用，而其他部分则被完全重写。

从行业标准符号的角度来看，BPMN的第一个版本于2004年发布，七年后的2011年发布了2.0版本。CMMN于2014年发布，一年后的2015年发布了DMN。

在 DMN 发布后的接下来几年里，我们看到许多开源产品与 CMMN 一起构建了对 DMN 的支持。有趣的是，经过五年的社区反馈，Camunda 基于社区反馈认为 CMMN 过于复杂，决定取消对 CMMN 的支持。用户发现在 BPMN 中构建案例流比在 CMMN 中更容易。2020 年，jBPM 启动了一个名为Kogito 的新项目，该项目将[url=https://drools.org/]Drools[/url]和jBPM的架构重构为云原生和基于微服务。2022 年，Camunda 发布了其产品 v8，该产品具有高度可扩展性并专注于流程编排。

从 2004 年到 2010 年左右，jBPM 一直是热门搜索查询之一，然后人们对 Activiti 的兴趣激增，并在 2016 年超过了 jBPM。2016 年晚些时候，Camunda 成为热门搜索查询，从那时起，人们对 Activiti 和 Flowable 的兴趣就最大了。即使 jBPM 的搜索查询量最低。

开源模型（即社区与企业）这是需要理解的最重要的方面之一，因为每个开源 BPM 产品都有不同的开源模型。这通常会令人困惑，但您需要清楚社区和企业中可用的内容，以便确保解决方案能够解决问题。

jBPM 拥有最简单、最开放的模型。社区版中的一切都在企业版中。企业版基于最新社区版本的多个分支，以确保其稳定版本（相对于实验性功能）。您使用企业版获得的增量是来自红帽的支持。

Camunda 的模型略有不同，他们的引擎（即 Zeebe）是可用的，他们的 Modeler 是开源的，而提供操作功能的其他模块不是开源的，但可以在 QA 中免费使用。可用源的细微差别与开源非常接近，区别在于您不能使用它来托管提供给其他人的商业解决方案（例如，认为 SaaS 提供商）

Activiti 具有与 jBPM 和 Camunda 不同的开源模型。他们提供了所有功能的基本部分，但要获得更高级的功能，您必须购买企业版本。Flowable 也遵循与 Activiti 类似的开源模型。

能力集现在让我们来看看这四种产品各自的高级功能集，重点关注以下领域：

规则引擎

建模和执行环境

部署方式

仪表板

案例管理

云原生/无服务器/容器

云托管服务产品

规则引擎：

jBPM 是唯一提供内置业务规则管理系统（称为 Drools）的开源 BPM 产品。

Camunda、Flowable 和 Activiti 都支持利用决策表的 DMN 表示法，

但是 Drools 具有更多功能，包括使用增强版Rete 算法的前向和后向链接推理引擎。这使得 Drools 能够自动找出要执行的规则以及执行顺序。

建模与执行环境：

jBPM 提供了一个基于 Web 的建模器，它是称为 Business Central 的整体 UI 的一部分。在 Business Central 中，您可以部署、管理和跟踪工作流程

Camunda 提供桌面建模器和 Web 建模器（仅通过 SaaS 产品提供） 称为任务列表、操作和优化的操作模块仅在企业中可用（但可以在 QA 环境中免费使用）

Activiti 提供了一个基于 Web 的建模器以​​及一个 Eclipse 插件作为社区版本的一部分，而企业版本则添加了流程分析、定制业务应用程序、移动、DMN 设计器、流程应用程序设计器、管理、分析和集成。

Flowable 提供了基于 Web 的建模器和 eclipse 插件，并在社区版本中提供了各种操作模块的各种核心功能，包括任务、管理和身份管理。

部署方式jBPM、Activti 和 Flowable 都支持进程内/嵌入模式以及独立模式。Camunda 仅支持独立模式。这是一个有意的决定，因为他们发现进程内/嵌入模式给他们的社区带来了可扩展性挑战，因此从 Camunda v8 开始采用了仅独立模式。

仪表板jBPM 是唯一在其社区版本中提供仪表板功能的产品。其他三个在其企业版中提供仪表板，特别是 Camunda Optimize、Flowable Work 和 Activiti Process Analytics。

Case管理CMMNjBPM 和 Flowable 提供对 CMMN 的支持，而 Camunda 和 Activiti 则不支持。之前我们讨论了 Camunda 根据社区反馈有意决定取消对 CMMN 的支持。

云原生/无服务器/容器

如前所述，jBPM 大力投资 Kogito 项目，该项目是迁移到云原生微服务部署的下一代 jBPM 和 Drools 项目。它还包括对反应式消息传递 (Kafka) 和无服务器工作流程利用 (knative) 的支持。该计划是继续提供传统的 jBPM 和 Drools 项目以及下一代 (Kogito) 项目，以允许用户在项目之间进行选择。

Camunda 8 被誉为流程协调器和高度可扩展的。它们提供对 Kubernetes 和 Helm 图表的支持。

Activiti 以其与 Spring Boot 的轻松集成而闻名，并且还支持 Kubernetes。

Flowable 最近做了几个示例，展示了他们的引擎如何以#无服务器 方式运行，例如在 AWS Lambda 中运行引擎。

云托管服务产品自 2016 年以来最大的变化之一是，我们现在看到开源 BPM 产品作为云中的托管服务产品提供。Camunda 提供 SaaS 产品，而 Alfresco Activiti 提供称为 Alfresco Cloud 的 PaaS 产品。这两个都是企业选项，让您无需自行管理任何基础设施。

社区活动如果您要使用开源产品，您希望使用具有活跃社区的产品。这使您能够依赖社区的支持和增强，而不是独自完成这一切。发现 Camunda 和 Flowable 似乎是最活跃的项目，其次是 jBPM（过去三年的活动水平保持一致），然后 Activiti 在过去两年相对安静，提交量突然激增。Activiti 提交的安静可能是 Flowable 分叉的结果（以前的 Activiti 贡献者现在专注于提交 Flowable）

结论我们在本文中讨论了几个关键的开源 BPM 主题，并提供了四个常见项目的比较。最终由您决定哪一种最适合您的需求和用例。