2022 年开源 BPM 比较
2022 年开源 BPM 比较
开源BPM产品的比较与对比
早在 2016 年，我写了一篇 文章 比较和对比一些最流行的开源业务流程管理 (BPM) 产品。我最近对这个主题进行了一些研究，并很快意识到发生了很大的变化！以真正的开源方式，我最近在 开源峰会 并想在本文中分享我的发现。我希望你喜欢！
总体而言，开源在全球范围内的采用继续加速。截至 2022 年 6 月，公众 Github 拥有 2 亿个存储库和 8300 万开发人员，比 2016 年增长了 400% 以上。对于开源 BPM 项目，项目不断增长，例如 可流动的 2017 年从 Activiti 分叉。这个领域的变化仍然是一致的。
本文将概述工作流、BPM 和 BPM 产品支持的一些行业标准符号。接下来，本文将介绍 BPM 替代方案，以及何时应该使用其中一种或另一种以及可伸缩性注意事项。最后，深入探讨了四个开源 BPM 项目：jBPM、Camunda、Activiti 和 Flowable。这篇文章将把这四个维度中的每一个与这三个维度进行比较：
- 开源模型（即社区与企业）
- 能力集
- 社区活动
背景和背景
什么是工作流？
工作流通常是一个重载的术语。根据使用的上下文，它至少可以具有三种不同的含义。在基本级别上，工作流是业务流程离散步骤的结构化流程。工作流的一种形式是人工工作流。一个例子是一个人调查一个案例或将一个应用程序发送到另一个组进行审查。工作流的第二种形式是系统编排。可能有一组 API 需要按特定顺序调用，以完成仅涉及系统步骤的业务流程。第三种类型的工作流涉及人工和系统编排的混合。通常，系统编排可能会遇到错误场景，或者可能需要对某些内容进行审查以进行进一步研究。从这三个示例中，您可以看到理解工作流上下文的重要性，因为它可以有不同的含义。
工作流的特征也可以具有不同的复杂程度。有两类工作流：简单和复杂。以下是每个的一些特征：
简单的工作流程
- 任务管理 - 想想用户的待办事项列表
- 通知 — 通过电子邮件或短信提醒用户
- 状态管理—— 项目的状态，例如未开始、进行中或完成
- 单个组中的用户数量少——没有跨团队或部门协调
复杂的工作流程
（包括所有简单特征加上以下）
- 许多组/用户—— 跨越多个部门或部门
- 多层次的工作流程—— 各种分支和路径
- 异常路径，回调 — 错误处理并根据条件返回到较早的步骤
- 案例管理 ——不可预测的临时调查类型活动；可以根据条件使用一种或多种工作流程
- 与规则集成 — if/then 类型的业务或策略决策逻辑
- 与系统编排集成 — 人工工作流程和系统工作流程的结合
了解用例的工作流程特征很重要，因为这将引导您找到正确的解决方案。那么有哪些可能的工作流程解决方案呢？什么是 BPM 产品，它解决了哪些问题？让我们深入研究一下。
什么是 BPM 产品？
BPM 产品的核心是提供管理业务流程的模型的可视化建模和执行。它们通常提供与各种适配器的附加集成功能。类似的名称是业务流程管理系统 (BPMS) 或智能业务流程管理系统 (iBPMS)。其他类别的产品可能只提供建模，但 BPM/BPMS/iBPMS 产品同时提供建模和执行。开源环境可能令人困惑，
examples of some open source BPM products available today
行业标准符号
开源 BPM 产品支持的一个常见主题是对象建模组 (OMG) 实现的一些行业标准符号。共有三种行业标准符号：BPMN、CMMN 和 DMN。让我们更详细地介绍其中的每一个。
BPMN — 业务流程建模符号
BPMN 于 2004 年首次发布，为业务流程建模提供了行业标准。这很重要，因为它使 BPMN 可视化模型具有可移植性，这意味着构建在一个应用程序中的 BPMN 图可以在另一个应用程序中使用（只要工具没有在其上覆盖任何专有项目）。它还鼓励商业和技术合作。通常，您可以让熟悉 BPMN 的业务分析师创建业务流程，然后将其交给他们的技术合作伙伴以在 BPM 产品中实施。下面是详细规范中一些关键图标的高级视图：
BPMN spec from http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf
DMN - 决策建模符号
通常在业务流程中，您需要 if/then 逻辑来做出业务决策。这就是 DMN 派上用场的地方。它于 2015 年首次发布，为与 BPMN 兼容的业务规则和决策提供了行业标准符号。
DMN example from https://www.omg.org/spec/DMN/1.4/Beta1/PDF
CMMN — 案例管理建模符号
第三种行业标准建模符号是 CMMN，它于 2014 年首次发布。案例管理通常不同于标准工作流程，因为它具有临时性和调查性，并且不可预测。
下面是总结三种不同行业标准符号的视图。通常，开源 BPM 产品将支持这些的某些组合——全部三个或 BPMN 和 DMN。在本文后面，我们将更多地讨论 CMMN 以及 Camunda 发现的一些发现。
Summary of the three different industry standard notations https://www.omg.org/intro/TripleCrown.pdf
现在我们已经很好地处理了 BPM 产品提供的不同类型的行业标准符号，让我们来谈谈替代方案。
何时使用 BPM 产品？
虽然 BPM 产品非常擅长以可视方式解决多个工作流问题，但您可能并不总是需要如此丰富的功能。在某些情况下，基于配置的更轻量级的解决方案可能更适合。下面是一些状态机的例子：
- AWS Step Functions (Workflow Studio ）。提供一种在 AWS 中编排 lambda 函数的方法。还提供了可视化建模器（不支持 BPMN）
- 状态 .基于 JSON 的状态机，可用于实现工作流
- 指挥（Netflix） 可用于面向微服务的系统编排
所以现在您可能想知道，我什么时候应该使用 BPM 产品？一般的经验法则是，当工作流在模型中比在代码或配置中更容易构建时，使用 BPM 产品。用例通常属于两个维度：集成度和业务流程的复杂性。需要高度集成和/或高度复杂性的业务流程通常是 BPM 产品的最佳选择。下面是一个矩阵，它使用了我们之前讨论过的简单和复杂的工作流特征，并将它们与集成和业务流程复杂性维度对齐。
确保为您的用例使用正确的解决方案非常重要。如果集成和/或业务流程复杂性较低，BPM 产品可能会过度使用。
单体、微服务和可扩展性注意事项
使用 BPM 产品时要注意的一个方面是确保您没有在其中构建单体应用程序。这样做很容易，因为这些产品通常会提供您制作应用程序所需的大量工具。此外，一些 BPM 产品本身就是单体部署。随着许多开源 BPM 产品正在转向更多基于云原生微服务的部署模型，我们稍后会谈到这一点。一个关键的考虑因素是有意识地了解您在 BPM 产品内部构建的内容以及在其外部保留的内容。我通常建议您仅将 BPM 产品用于其擅长的工作——工作流。将所有其他内容保留在产品之外，并使用各种适配器来构建与工作流的集成。
http://martinfowler.com/aricles/microservices.html
争取的一个关键目标是在使用 BPM 产品时构建微服务。一种方法是将流程分解为子流程，并将每个流程部署为自己的微服务，以使其更具可扩展性。
http://martinfowler.com/aricles/microservices.html
另一个可扩展性考虑是评估 BPM 引擎的部署方法。通常有两种方法：进程内/嵌入模式，或独立模式。这些方法中的每一种都有其优点和缺点。
进程内/嵌入式模式
在进程内/嵌入模式下，BPM 引擎作为应用程序的一部分在同一个 JVM 下运行。这种方法提供了高性能，因为应用程序和 BPM 引擎之间没有任何网络调用。但是，它会在两者之间产生紧密耦合。它还可以使扩展更加困难，因为要扩展 BPM 引擎，您还需要扩展应用程序。
独立模式
在独立模式下，BPM 引擎被部署为自己的独立服务，应用程序通过 API 调用与其集成。这将 BPM 引擎与应用程序分离，并允许每个引擎独立扩展。一个缺点是，由于应用程序和 BPM 引擎之间的网络 API 调用，它可以提供较低的性能。
开源 BPM 比较
现在我们已经介绍了很多背景和上下文，让我们开始仔细研究一些开源 BPM 产品。首先，让我们看看开源 BPM 的一些历史里程碑，特别关注基于 jBPM 重写（即 Activiti）或 jBPM 分支（即 Camunda、Flowable）的里程碑
significant milestones of open source BPM
jBPM 于 2003 年推出，是第一个上市的开源 BPM 产品。在 2010 年 Activiti 推出之前，它是唯一的开源 BPM 产品产品大约七年。三年后的 2013 年，Camunda 分叉了 Activiti。然后在 2017 年，Flowable 诞生于 Activiti 的分支。当这些产品中的每一个分叉时，架构的某些部分被重用，而其他部分则被完全重写。
从行业标准符号的角度来看，BPMN 的第一个版本于 2004 年发布，7 年后的 2011 年发布了 2.0 版。CMMN 于 2014 年发布，DMN 于一年后的 2015 年发布。
在 DMN 发布后的几年里，我们看到许多开源产品与 CMMN 一起构建了对 DMN 的支持。有趣的是，经过五年的社区反馈，Camunda 决定根据社区反馈取消对 CMMN 的支持，因为它太复杂了。用户发现在 BPMN 中构建案例流比在 CMMN 中更容易。
2020 年，jBPM 启动了一个名为 小木人 ，这是对架构的重构 流口水 和 jBPM 是云原生和基于微服务的。 2022 年，Camunda 发布了他们的产品 v8，该产品具有高度可扩展性，专注于流程编排。
总体开源 BPM 兴趣
这四种 BPM 产品中哪一种最受欢迎？我生成了一个 Google 趋势图，以了解在 Google 搜索中使用最多的趋势图。请注意，这不是对实际用户安装的映射。此外，我必须为 Activiti 和 Flowable 过滤掉一些搜索词，以确保不会混入像酸奶和混凝土这样的词。
Google trends graph
结果很有趣。从 2004 年到 2010 年左右，jBPM 是最热门的搜索查询之一，然后对 Activiti 的兴趣飙升，然后在 2016 年超过了 jBPM。2016 年晚些时候，Camunda 成为最热门的搜索查询，并且从那时起一直最受关注，而 Activiti 和 Flowable 大约即使 jBPM 的搜索查询最少。
现在让我们深入了解这些产品的每一个细节，仔细看看我们之前提到的三个维度：
- 开源模型（即社区与企业）
- 能力集
- 社区活动
开源模型（即社区与企业）
这是要理解的最重要的方面之一，因为每个开源 BPM 产品都有不同的开源模型。这通常令人困惑，但您需要清楚社区与企业中可用的内容，以便确保解决方案能够解决问题。
jBPM 有最简单和最开放的模型。社区版中的所有内容都在企业版中。企业版基于从最新社区版本返回的多个分支，以确保其稳定版本（相对于实验性功能）。您在企业版中获得的增量是来自 Red Hat 的支持。
Camunda 有一个稍微不同的模型，其中他们的引擎（即 Zeebe）是可用的源代码，他们的 Modeler 是开源的，而他们提供操作能力的其他模块不是开源的，但可以在 QA 中免费使用。可用源代码的细微差别非常接近开源，不同之处在于您不能使用它来托管提供给其他人的商业解决方案（例如认为 SaaS 提供商）
Activiti 的开源模型与 jBPM 和 Camunda 不同。它们提供了所有功能的基本部分，但要获得更高级的功能，您必须购买企业版。 Flowable 也遵循与 Activiti 类似的开源模型。
能力集
现在让我们看一下这四款产品各自的高级功能集，重点关注以下领域：
- 规则引擎
- 建模和执行环境
- 部署模式
- 仪表板
- 案例管理
- 云原生/无服务器/容器
- 云托管服务产品
- 规则引擎
jBPM 是唯一提供内置业务规则管理系统（称为 Drools）的开源 BPM 产品。 Camunda、Flowable 和 Activiti 都支持利用决策表的 DMN 表示法，但是 Drools 具有更多功能，包括使用增强版本的前向和后向链接推理引擎 雷特算法。 这使 Drools 能够自动确定要执行哪些规则以及以什么顺序执行。
2. 建模与执行环境
jBPM 提供了一个基于 Web 的建模器，它是称为 Business Central 的整个 UI 的一部分。在 Business Central 中，您可以部署、管理和跟踪工作流程
Business Central UI
Camunda 提供了一个桌面建模器和一个 Web 建模器（仅通过 SaaS 产品提供）被称为任务列表、操作和优化的操作模块仅在企业中可用（但可以在 QA 环境中免费使用）
Camunda modeler
Activiti 提供了一个基于 Web 的建模器和一个 Eclipse 插件作为社区版本的一部分，而企业版添加了流程分析、定制业务应用程序、移动、DMN 设计器、流程应用程序设计器、管理、分析和集成。
Activiti modeler
Flowable仅通过eclipse插件提供建模器，并在社区版中提供了包括Task、Admin、Identity Management在内的各种操作模块的各种核心能力。
3.部署方式
jBPM、Activti 和 Flowable 都支持进程内/嵌入式模式以及独立模式。 Camunda 仅支持独立模式。这是一个有意的决定，因为他们发现进程内/嵌入式模式给他们的社区带来了可扩展性挑战，因此从 Camunda v8 开始采用了一个独立的模式。
4. 仪表板
jBPM 是唯一在其社区版本中提供仪表板功能的产品。其他三个在其企业版中提供仪表板，特别是 Camunda Optimize、Flowable Work 和 Activiti Process Analytics。
5. 案例管理
jBPM 和 Flowable 提供对 CMMN 的支持，而 Camunda 和 Activiti 不提供。早些时候，我们讨论了 Camunda 根据社区反馈有意取消对 CMMN 的支持的决定。
6. 云原生/无服务器/容器
如前所述，jBPM 正在大力投资 Kogito 项目，该项目是 jBPM 和 Drools 项目的下一代，迁移到云原生微服务部署。它还包括对反应式消息传递 (Kafka) 和无服务器工作流利用 (knative) 的支持。该计划是继续提供传统的 jBPM 和 Drools 项目以及下一代 (Kogito) 项目，以允许用户在项目之间进行选择。
Camunda 8 被吹捧为流程协调器和高度可扩展性。它们为 Kubernetes 和 Helm 图表提供支持。
Activiti 以其与 Spring Boot 的轻松集成而闻名，并且还支持 Kubernetes。
Flowable 最近做了几个例子，说明他们的引擎如何在 无服务器方法 ，例如在 AWS Lambda 中运行引擎。
7. 云托管服务产品
自 2016 年以来最大的变化之一是我们现在看到开源 BPM 产品作为云中的托管服务产品提供。 Camunda 提供 SaaS 产品，而 Alfresco Activiti 提供称为 Alfresco Cloud 的 PaaS 产品。这两个都是企业选项，无需您自己管理任何基础架构。
社区活动
如果您要使用开源产品，您希望使用具有活跃社区的产品。这使您可以依靠社区来获得支持和增强功能，而不是靠自己来完成。下面是四个开源 BPM 产品的提交图。每一个的比例都有点不同，所以你在解释图表时必须注意那个细节。我发现 Camunda 和 Flowable 似乎是最活跃的项目，其次是 jBPM（在过去三年中一直保持一致的活动水平），然后 Activiti 在过去两年中相对安静，提交量突然激增. Activiti 提交的安静可能是 Flowable 分叉的结果（以前的 Activiti 贡献者现在专注于提交 Flowable）
Camunda commits https://github.com/camunda/camunda-bpm-platform
Flowable commits https://github.com/flowable/flowable-engine
jBPM commits https://github.com/kiegroup/jbpm
Activiti commits https://github.com/Activiti/Activiti
比较总结
下面是一个并排图表，总结了三个不同维度与上面讨论的四种产品中的每一种的比较。我的建议是关注开源 BPM 产品的不同之处，并确定哪些对你的公司和你试图解决的用例很重要。此外，与社区保持密切联系，以了解路线图以及随着环境的不断变化而发生的变化。
Overall side by side comparison summary
结论
我们在本文中涉及了几个关键的开源 BPM 主题，并提供了四个常见项目的比较。最终由您决定哪一个最适合您的需求和用例。这是开源 BPM 的一个激动人心的时刻，唯一保持不变的是事情在不断变化。请继续关注第一资本继续创造、分享和贡献于世界 开源 解决方案！
- 本文的分析是在 jBPM 7.7、Camunda 7.17.0、Flowable 6.7.2 和 Activiti 7.3.10 上进行的
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
