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

 

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

 

  1. 由于Camunda BPM几乎完全支持BPMN 2.0，因此它支持BPMN 2.0标准的绝大多数。因此，从BPMN 2.0功能集中可获得的功能远远超过此处显示的功能。该图必然限于Zeebe和Netflix Conductor可以支持的功能。
  2. Zeebe的支持基本上仅限于此处显示的内容。当前唯一可用且此处未说明的功能是计时器和消息事件以及扩展的子流程。
  3. 尽管过滤了BPMN 2.0专用术语，但Netflix Conductor的支持与Zeebe相似，尽管Netflix Conductor还提供了内嵌JavaScript逻辑，内联调用Web服务，派生执行以及从内部引用单独的工作流程定义的功能。 “父”工作流程定义。

您可能已经注意到上面＃3中的“内联”一词，这为我们提供了一个很好的机会，可以过渡到Netflix Conductor和Zeebe的非常重要的设计原则，Camunda BPM在使用“外部任务”时也共享这一原则。由于这些工具在这里仅充当状态机，并期望外部客户端执行任务工作，因此它们实质上操作了队列，这些队列维护着完全由外部应用程序预订并完成的工作集。Zeebe使用一个完美地概括它的术语：“工作人员”。期望这些外部客户端订阅任务类型并完成这些任务类型的工作，从而在每个工作单元完成后通知引擎/状态机。

 

为了说明这些工具中的每一个都为客户或工作人员选择技术的不可知论方法（使用Zeebe的术语），我们使用C＃编写了用于此技术比较的客户。有关客户编写方式的一些重要细节：

 

 

现在，让我们更深入地研究如何为每个平台构建客户端。

 

Netflix指挥

 

我们使用以下三个REST API端点来轮询和完成Netflix Conductor中的任务：

 

  1. GET / tasks / poll / batch：此端点允许客户端“长时间轮询”，即指示服务器在指定的时间段内保持连接打开，或者直到至少一个满足提供的条件的任务到达为止。
  2. POST / tasks / {taskId} / ack：此端点允许客户端“确认”任务，本质上将其锁定以完成任务，以防止其他客户端同时处理同一任务。
  3. POST / tasks：最后，此端点允许客户端完成任务，将任何新数据提供给特定的工作流实例。

 

这是示例代码行，在这种情况下，该代码使用RESTUtility（我们的实用程序类）对可用任务进行长时间轮询：

Object lpResponse = RESTUtility.get(CONDUCTOR_BASE_URL,

    "poll/batch/Determine%20Approver%20Groups?count=5&timeout=5000&workerId=" +

     WORKER_ID,

     typeof(List));

 

在这种情况下，lpResponse对象是多态的。它可以代表有效的响应或错误，我们将对其进行相应的处理。更多详细信息在这里不做讨论。

一切都按预期进行。我们能够按预期完成工作流程实例。

Zeebe

由于Zeebe的社区提供了一个优雅的，由社区提供的C＃客户端，因此为每个Zeebe任务编写客户端代码非常容易。这是一个打开订阅以完成任务的调用示例：

client.NewWorker()

    .JobType("determine-approver-groups")

    .Handler(HandleDetermineApproverGroups)

    .MaxJobsActive(5)

    .Name(WORKER_NAME)

    .AutoCompletion()

    .PollInterval(TimeSpan.FromSeconds(1))

    .Timeout(TimeSpan.FromSeconds(10))

    .Open();

由于它涉及到称为HandleDetermineApproverGroups的函数，因此该代码供您查看：

private static void HandleDetermineApproverGroups(IJobClient jobClient, IJob job) {

  var jobKey = job.Key;

  Console.WriteLine("Handling \"determine-approver-groups\" job: " + job);

​  jobClient.NewCompleteJobCommand(jobKey)

                  .Variables("{\"approverGroups\":\"accounting\"}")

                  .Send();

}

如上所述，由于从技术上讲这是gRPC客户端，因此只需对Netflix Conductor进行少量修改就可以使用它，它也支持将gRPC用于其客户端。

在同一应用程序中打开多个订阅也非常容易。尽管我们希望Zeebe提供REST API，但我们发现C＃客户端非常易于使用。实际上，这比用C＃为Netflix Conductor和Camunda BPM编写REST API客户端要容易得多。

Camunda BPM

由于Camunda BPM将长时间的轮询和确认/锁定任务的过程提炼到一个REST API调用中，因此与Netflix Conductor相比，通过REST进行交互稍微容易一些。结果，仅使用了两个端点：

  1. POST / external-task / fetchAndLock：允许长时间轮询以及一次调用中多个主题（任务类型）中任务的获取和锁定。
  2. POST / external-task / {id} / complete：允许完成任务，包括为工作流/流程实例提供任何新变量。

此处使用的代码类似于Netflix Conductor客户端使用的代码，包括RESTUtility类的使用。与Conductor和Zeebe一样，在订阅和完成任务时没有遇到任何问题。

结论

所有这三个产品都能够提供我们进行此练习所需的状态机功能和简单的分支功能。尽管Zeebe的C＃客户端（由其社区贡献）非常优雅且易于使用，但是Zeebe缺少REST API客户端意味着您仅限于它们提供的客户端或直接通过gRPC与引擎接口的客户端。另一方面，尽管Netflix Conductor和Camunda BPM没有提供C＃客户端，但是它们可用的REST API在客户端选择方面提供了更大的灵活性。

从可伸缩性的角度来看，Netflix Conductor和Zeebe具有理论上优越的体系结构设计特征，这些特征应允许在构建企业应用程序时实现更有效的可伸缩性。但是，在遇到麻烦的地方，正如我们之前题为“压倒性的工作流程选项集” *的博客中所讨论的那样，我们在这些新平台上没有真实的性能数据，这些数据无法说明它们的扩展能力。在开源工作流平台中已经见过。

对我们而言，与众不同之处在于Camunda BPM提供的更完整的功能集。虽然它可以提供与其他客户端相同的状态机功能并支持使用外部客户端，但其更完整的功能集为用户提供了更多的选择，以建立工作流程定义。因此，在大多数情况下，这是一个比其他两种情况更好的选择，但需要大规模扩展的情况除外。

 

相关教程