Zeebe和Camunda BPM：技术比较（上）

Zeebe和Camunda BPM：技术比较（上）

在上一个博客条目“压倒性的工作流选项集” 中，我们研究了工作流解决方案的三类-BPM套件，开源BPM平台和轻量级工作流平台-并得出以下结论：

• BPM套件（例如Appian，IBM BPM和Pegasystems）在用户期望其他功能（例如高级用户界面生成和工作流程解决方案的报告功能）时最合适。
• 轻量级工作流平台（例如Netflix Conductor和Zeebe）未经验证，但是如果工作流解决方案需要大规模的可扩展性（每天=> 1B个工作流实例），则该工具很有前途。
• 开源工作流平台最适合需要灵活性和开发人员友好性的情况。

由于某些用户可能很难在更新的“轻量级”工作流平台和较旧的（旧版本的）遗留开源工作流平台之间进行选择，因此让我们对其进行深入研究，并研究它们的相对功能。

 

背景

 

Camunda BPM是一组具有共同遗产的开源工作流工具之一，Flowable的Joram Barrez和Paul-Holmes Higgin撰写了一篇精彩的博客文章，此处详细介绍了Camunda BPM。总之，在开源BPM平台市场四个相关的平台：jBPM，Activiti，Camunda BPM和FlowableBPM。jBPM是所有这些平台的精神祖先，它的创建者开发了Activiti，是jBPM当时概念的发展。Camunda BPM和Flowable BPM都来自Activiti。在本博客文章的其余部分中，我们将使用Camunda BPM作为这组相关产品的代表，但是该类别中的其他产品具有相似的功能。

 

Netflix Conductor和Camunda的Zeebe是最近几年推出的两个新的轻量级工作流引擎。对于Conductor来说，它是为了“协调基于微服务的流程”而构建的；在Zeebe的案例中，它旨在“解决微服务编排问题”。而且，两种产品的设计都能够进行扩展以处理大量并发实例。换句话说，它们具有非常相似的既定目标。

 

Netflix和Camunda-以及Conductor和Zeebe-专注于构建非常快速和可扩展的状态机，即可以非常有效地管理每个实例状态的工作流引擎。双方通常都希望外部客户在每个工作流程的每个步骤中完成工作；尽管这肯定有其优势，但它往往会限制这些工具的功能。

 

相对能力

 

Camunda BPM为工作流程社区中的独立标准BPMN（业务流程模型和表示法）2.0提供了几乎完整的支持。它支持：

• 任务：用户任务，服务任务，脚本任务，业务规则任务等。
• 事件：计时器事件，消息事件，信号事件等。
• 网关：专用网关，并行网关，包含网关和基于事件的网关
• 其他：池，通道，呼叫活动（用于调用单独的工作流），嵌入式子过程等。

轻量级工作流工具仅提供此功能的子集。例如，Zeebe仅支持：

• 任务：服务任务
• 事件：计时器事件和消息事件
• 网关：专用网关
• 其他：嵌入式子流程

Netflix Conductor不支持BPMN 2.0，并且拥有自己的使用JSON的建模语言。为了进行比较，我们可以说它支持以下类似内容（括号中各为Netflix Conductor名称）：

• 任务：服务任务（称为简单任务）和脚本任务（Lambda任务）
• 事件：消息事件（事件和等待）
• 网关：专用网关（决策）和并行网关（分叉）
• 其他：呼叫活动（子工作流程）

 

尽管Zeebe实际上仅允许外部客户端执行逻辑，但Netflix Conductor提供了一些功能以允许在引擎本身内完成工作，例如使用Lambda Tasks。 

 

我们相信这些平台将不断发展，以提供更完整的工作流功能集，但目前受到一定限制。

 

用例比较

 

让我们在所有三个平台上实现一个简单的工作流/状态机用例，并以此对这三个工具进行技术比较。

 

首先，这是Camunda BPM和Zeebe中用于我们的用例的过程模型：

 

图1：Camunda BPM和Zeebe中的自动发票工作流程

 

这是Netflix Conductor中使用的工作流程定义：

图2：Netflix Conductor中的自动发票工作流程

 

让我们简要地讨论一下这些图。由于两个Zeebe和Camunda BPM杠杆BPMN 2.0标准，其过程模型看起来是一样的视觉。相反，由于Netflix Conductor使用前面提到的专有JSON表示形式和自定义渲染器，因此其模型看起来有所不同。这些视觉表示形式背后隐藏着重大差异：