Zeebe是一个用于微服务编排的工作流引擎。

这篇文章将帮助你确切地了解什么是Zeebe以及它如何可能与你相关。我们将简要介绍Zeebe以及它所解决的问题，然后再进行更详细的介绍。

我们将在整个写作过程中使用“工作流”这个词，根据您的背景，在微服务的环境中您可能不熟悉这个词。当我们说“工作流”时，我们的意思是“允许我们实现某个目标的一系列任务”。“工作流”可以与“业务流程”或“流程”同义使用。

在Zeebe编排的工作流中，每个任务通常由不同的微服务执行。

介绍

公司的端到端工作流几乎总是跨越多个微服务。例如，在电子商务公司中，“客户订单”工作流可能涉及支付微服务、库存微服务、配送微服务等等。

这些跨微服务工作流是公司的核心收入驱动因素，但它们很少被建模和监控;通常，通过不同微服务的事件流仅在代码中隐含地表示。

如果是这样，我们如何确保工作流的可见性并提供状态和错误监视?我们如何保证整个流始终是完整的，即使单个微服务失败?或者我们如何至少认识到一个流程被卡住了所以我们可以进去并修复它?

Zeebe是一个免费的、源代码可用的微服务编制工作流引擎，它提供:

• 对公司端到端的工作流状态的可见性，包括正在运行的工作流的数量、平均工作流持续时间、工作流中的当前错误，等等。
  
• 根据工作流的当前状态编制工作流;Zeebe将“命令”作为事件发布，可以由一个或多个微服务使用，确保工作流按照其定义进行。
  
• 监视超时或其他流程错误，以及配置错误处理路径的能力，例如有状态重试或向能够手动解决问题的团队升级，确保工作流始终按计划完成。
  

Zeebe被设计用来解决非常大规模的微服务编排问题，为了实现这一点，它提供:

• 横向可伸缩性，不依赖于外部数据库;相反，Zeebe直接将数据写入部署它的服务器上的文件系统，并且可以轻松地跨计算机集群分发处理，从而提供高吞吐量。
  
• 通过易于配置的复制机制实现容错，确保Zeebe可以从机器或软件故障中恢复，而不会造成数据丢失和最小的停机时间。
  
• 一种消息驱动的体系结构，其中所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导出到外部系统进行长期存储，以提供一个完整的工作流审计日志。
  
• 发布-订阅交互模型，它允许连接到Zeebe的微服务在提供处理反压力机制的同时保持高度的控制。
  
• 在iso标准BPMN 2.0中建模的可视化工作流，使得技术和非技术涉众可以用一种公共语言协作进行工作流设计。
  
• 与语言无关的客户机模型，使得用组织用来构建微服务的几乎任何编程语言构建Zeebe客户机成为可能。
  

您可以在文档中了解有关这些技术概念的更多信息。

如果您只需要看这些，并且您认为Zeebe可能适合您，我们鼓励您尝试一下。现在就可以下载了。入门教程是不需要编写任何代码就可以动手操作的好方法。

如果你有问题，请联系Zeebe社区。你可以在Zeebe论坛上发布一个问题，或者在我们的Slack频道与Zeebe开发者合作。我们希望收到你的来信。

Zeebe现在可以用于生产。您可以在这里看到路线图。

如果你想了解更多关于Zeebe的信息，你可以继续阅读。在这篇文章的其余部分，我们将更详细地讨论三个主题:

• Zeebe解决的问题和它的重要性
  
• Zeebe如何解决这个问题
  
• 为什么Zeebe很适合解决这个问题
  

Zeebe解决的问题和它的重要性

微服务体系结构近年来变得越来越流行，这是有原因的。专注的、跨功能的团队在使用他们选择的技术堆栈时可以快速、独立地交付价值。

但是使微服务体系结构如此吸引人的原则——松耦合、独立的部署周期——也带来了重大的挑战。

微服务体系结构的核心原则是每个微服务只负责一种业务功能。我们将再次引用引言中的电子商务示例，其中一个微服务负责支付处理，另一个负责库存，另一个负责运输，等等:

每个微服务的存在都是为了促进更广泛的工作流程:尽可能快速有效地为购物者提供他们想要的服务。而只有在端到端工作流成功的情况下，公司才会成功，因此确保工作流的质量至关重要。

在微服务体系结构中，每个微服务只负责严格限定范围的业务功能，谁负责端到端工作流?

默认情况下，没有人。实际上，端到端工作流甚至可能没有在公司内部正式文档化，从微服务到微服务的事件流仅在代码中隐式地表示。

许多微服务体系结构依赖于纯编舞（choreography）模式进行通信，其中微服务通过在没有中央控制器(也称为发布-订阅或发布-订阅模型)的情况下向消息传递平台发布事件和使用事件进行协作。编舞（choreography）确实为微服务的开发人员提供了一定程度的灵活性。

然而，在其典型的实现中，编舞（choreography）并不提供:

• 对业务当前状态的可见性:有多少端到端工作流实例正在进行中，它们的状态是什么?在过去24小时内，有多少工作流实例没有成功完成?为什么这些工作流实例没有成功完成?完成一个工作流实例或工作流中的一个特定步骤的平均时间是多少?
  
• 故障处理以确保即使在错误发生时工作流也能完成:如果作为工作流一部分的服务失败，谁负责处理该故障?工作流的重试逻辑是什么?如果需要人为干预，我们有什么规则来及时解决问题升级?
  

注意:当我们说“工作流实例”时，我们指的是“工作流的一次出现”。在电子商务示例中，单个工作流实例将是单个客户订单。

因此，微服务体系结构面临产生好的软件(在微服务级别)但产生坏的业务结果的风险。毕竟，工作流的成功最终决定了业务的成败。

开发团队如何在确保健壮的端到端工作流的同时获得微服务体系结构的好处?

这就是Zeebe的作用。

Zeebe如何解决这个问题

Zeebe是一个工作流引擎。如果你是工作流引擎的新手，这里有一个维基百科提供的通用定义:

工作流引擎是管理业务流程的系统。它监视工作流中活动的状态，并根据定义的流程确定要转换到哪个新活动。

标签“工作流引擎”与缓慢、低吞吐量的用例(如人工任务管理)有遗留关联。

另一方面，Zeebe提供高吞吐量、低延迟和水平可伸缩性（provides high throughput, low latency, and horizontal scalability. ）。为了解释原因，让我们介绍一些Zeebe的关键架构概念。

首先，Zeebe不需要中央数据库组件，而是利用了事件源，这意味着对工作流状态的所有更改都作为事件捕获，并存储在仅用于追加的日志中。在Zeebe中，这个日志被称为“主题”。主题被直接写入运行Zeebe的服务器上的文件系统，工作流的当前状态可以从存储在主题中的事件中派生出来。

为了实现可伸缩性，主题可以很容易地分布在集群(分区)中的多个节点上，分区通常存储在多个节点上(复制)，以实现容错。

Zeebe使用客户机/服务器模型。服务器(代理)是一个远程引擎，作为它自己的程序在Java虚拟机上运行。代理负责存储与工作流相关的主题，在适当的时候将工作项分发给客户端，并通过发布-sub将工作流事件流公开给Zeebe客户端。Zeebe客户机可以嵌入到应用程序中以连接到代理。

如果您使用过Apache Kafka、Apache Pulsar或类似的消息传递系统，那么您可能对这种架构很熟悉。如果您想了解更多关于Zeebe的核心概念，请查看文档。

现在让我们讨论一下Zeebe如何在更实际的术语中解决端到端工作流问题。Zeebe使用户能够:

• 显式地定义和建模跨越多个微服务的工作流
  
• 获得工作流如何执行的详细可见性，并了解哪里存在问题
  
• 编排完成已定义工作流的微服务，以确保所有工作流实例都按照计划完成——即使在过程中出现问题
  

在下面的部分中，我们将讨论如何在一般意义上使用Zeebe，而不使用代码示例。在未来，我们可能会分享“蓝图”来演示如何准确地构建这些解决方案，如果社区认为它有用的话。

用Zeebe解决工作流问题，第1步:感知工作流的事件监控

工作流感知事件监视是Zeebe对我们上面定义的可见性问题的回答。

回顾一下:

• 您的业务依赖于一个或多个长时间运行的工作流的成功完成
  
• 这些工作流是由独立开发和独立部署的微服务执行的，这些微服务通过发布-订阅进行通信，没有中央控制机制
  
• 尽管您可以洞察到给定微服务的性能，但您对工作流的端到端运行状况以及业务的当前状态几乎没有可见性
  

Zeebe可以与已经在事件驱动架构中使用的组件一起工作，而不需要替换或删除任何现有系统来提供工作流可见性。

下面是一个简单的图表，展示了Zeebe如何用于跨微服务的工作流的可见性:

在本例中，Zeebe订阅发布到您的消息传递平台的事件，并将它们与预定义的工作流相关联，工作流已在BPMN 2.0中可视化建模并部署到Zeebe代理中(要了解有关Zeebe工作流的更多信息，请参阅文档)。

Zeebe处理的与工作流相关的事件可用于为仪表板提供动力，构建揭示工作流中问题区域的热图，以及在工作流实例出现问题并需要关注时构建警报工具。

在此实现中，Zeebe超出了监视单个微服务运行状况的范围，并提供了以下可见性:

• 业务的当前状态:当前有多少跨微服务工作流正在运行，它们的状态是什么?
  
• 是否有正在运行的进程由于错误或其他问题而“卡住”?
  
• 我们的平均端到端流程持续时间是多长?我们在流程的哪些地方遇到了问题?
  

在本例中，Zeebe纯粹作为“侦听器”操作，不直接与参与工作流的微服务交互。让我们讨论一下如何扩展这个“可见性”解决方案，以利用Zeebe的编排功能。

用Zeebe解决工作流问题，步骤2:微服务编制

Microservices编排是Zeebe对我们在本文前面讨论的失败处理和重试问题的回答。

在微服务社区中，微服务编排有时被认为与核心微服务原则(如松散耦合和独立可部署性)不一致。但事实并非如此!微服务编排可以按照符合这些原则的方式实现，Zeebe也相应地设计了。

下面是一个简单的图表，展示了Zeebe如何用于微服务编排:

该体系结构与我们上面描述的“Zeebe for visibility”体系结构非常相似。一个显著的区别是，在我们的图中，我们删除了消息传递平台层，而Zeebe直接与参与工作流的微服务通信。

仍然可以在不删除现有消息传递平台的情况下使用Zeebe进行微服务编排——除了订阅与工作流相关的事件(如“可见性”解决方案中所示)之外，Zeebe还可以简单地将事件发布到消息传递平台。

但是Zeebe也可以在没有消息传递平台的情况下使用，这里我们想强调一下这种方法。

您可以将Zeebe的工作流编制方法视为状态机。当工作流实例进展到某个任务时，Zeebe发送一条消息通知负责的worker服务，然后等待该worker完成任务。

任务完成后，worker服务通知Zeebe，流继续执行下一个步骤。如果工作人员未能完成任务，工作流将保持在当前步骤，可能会重新尝试该任务，直到最终成功，或者如果需要人工干预，将其升级到另一个团队。

Zeebe将任务通知消息的创建与工作的实际执行分离开来，这意味着Zeebe可以以最大的可能速率发送任务通知消息，而不管是否有工作人员服务可用来承担工作。

Zeebe将任务通知排队，直到它能够将它们推送给工作人员。如果当前没有工作人员服务可用，工作消息将保持排队状态。如果工人服务订阅了，Zeebe的背压协议确保工人可以控制他们接收任务的速度。

这种微服务编排方法仍然提供了工作流和工作流实例的完整可见性，同时也确保工作流按照其定义完成，即使在过程中出现了故障。

为什么Zeebe很适合解决这些问题?

Zeebe 支持横向扩展

扩展以处理高吞吐量工作负载的能力对于Zeebe在微服务编排中的角色至关重要。为了处理大量的工作流实例，可能需要跨计算机集群分发Zeebe，以满足吞吐量需求。

Zeebe使用分区来提供水平可伸缩性，并且基于我们的内部基准测试，分区提供了一种有效的方法来扩展到每秒启动数千个工作流实例，即使在一个相对较小的(5个节点)集群上也是如此。

Zeebe具有容错能力和高可用性

Zeebe允许用户在创建主题时配置复制因子。复制因子决定在其他代理上存储一个分区的多少个“热备用”副本。如果一个代理宕机，另一个代理可以替换它，不会造成数据丢失。由于数据分布在集群中的多个代理中，Zeebe提供了容错和高可用性，而不需要外部数据库，直接将数据存储在部署数据的服务器的文件系统上。Zeebe也不需要外部集群协调器(如ZooKeeper)。Zeebe是完全自给自足的。

Zeebe允许可视化地定义工作流

ISO-standard BPMN 2.0是在Zeebe中定义工作流的默认建模语言。工作流是在技术和非技术涉众的充分参与下可视化地定义的。虽然Zeebe对BPMN符号的覆盖不如Camunda BPM等更成熟的BPM平台那么全面，但Zeebe的路线图包括定期添加对新符号的支持。

Zeebe是语言不可知论者

目前，Zeebe提供了两个开箱即用的Java客户机和Go客户机。Zeebe客户机基于gRPC，这意味着可以用组织通常用于构建微服务的许多编程语言轻松生成Zeebe客户机。这里提供了grpc支持的编程语言列表。

Zeebe是完全消息驱动的

Zeebe代理和客户端完全通过发布-订阅进行通信，这使得遵循松耦合原则并支持Zeebe和参与工作流的微服务之间的异步通信成为可能。Zeebe的订阅协议包括一个backpressure机制，以确保客户机不会因来自Zeebe的工作而超载。

Zeebe可以方便地存储用于审计的事件的完整历史

Zeebe导出器使工作流事件数据流化到存储系统变得很容易，因此这些数据可以无限期地使用。这对于报告和可见性很重要，而且根据您的行业，出于监管原因，这可能也是必要的。

Zeebe听起来不错，但我有一个在microservices编配之外的用例。我能用Zeebe吗?

是的,当然!我们经常在微服务编制用例的上下文中讨论Zeebe，因为Zeebe能够很好地解决这个问题，但是Zeebe可以应用于微服务编制之外的用例。

Zeebe是一个工作流引擎，可以处理广泛的高吞吐量用例。以下是Zeebe的一些一般特点:

• Zeebe在设计时考虑了大规模工作流(每秒最多可以启动数万个新的工作流实例)。Zeebe不依赖于外部数据库，而是将数据以不可变日志的形式直接存储在部署Zeebe的服务器上;这个体系结构对于Zeebe处理高吞吐量和水平伸缩的能力非常关键。
  
• 目前，Zeebe代理和外部服务之间的所有通信都由Zeebe的客户端处理。Zeebe的客户机协议与编程语言无关，这意味着可以用许多常用编程语言轻松生成客户机。
  
• Zeebe目前涵盖的BPMN符号比Camunda BPM等更成熟的工作流引擎还少。然而，Zeebe定期添加对新符号的支持，并且最终，Zeebe将提供对工作流自动化有意义的BPMN符号的完整覆盖。
  

我如何开始用Zeebe?

首先，感谢您的阅读!我们希望您能够清楚地理解我们为什么要构建Zeebe以及它如何能够帮助您。

要开始使用Zeebe，我们建议您:

• 阅读Zeebe的核心技术概念:Zeebe文档的“概述”部分介绍了Zeebe背后的一些关键思想和概念。
  
• 安装Zeebe:安装指南向您展示在哪里可以找到Zeebe的最新发行版，以及如何在Docker上运行Zeebe，然后指导您完成成功的安装。
  
• 尝试入门教程:获得动手和学习端到端Zeebe经验，从在Zeebe Modeler中建模，到使用Zeebe命令行界面创建和完成工作流实例，再到可视化操作中发生的事情。
  
• 在论坛中问一个问题:Zeebe文档中的“获取帮助和参与”页面包含了Zeebe论坛和我们的公共Slack频道的链接，这两个链接都可以用来与Zeebe工程团队取得联系。我们渴望听到问题和反馈。