Zeebe简介

原文地址：zeebe.io/what-is-zee…

什么是Zeebe

Zeebe是一个用于微服务编排的工作流引擎。 在Zeebe编排的工作流中，每个任务通常由不同的微服务来执行。

介绍

一家公司的端到端工作流几乎总是跨越一个以上的微服务。例如，在一家电子商务公司，"客户订单 "工作流可能涉及到支付微服务、库存微服务、运输微服务等。

这些跨微服务的工作流是公司的核心收入驱动力，但它们却很少被建模和监控，通常情况下，通过不同微服务的事件流只在代码中隐含地表达。  

如果是这样，我们如何确保工作流的可观测性，并提供状态和错误监控？即使单个微服务失败，我们如何保证整体流转总是完整的？或者说，我们如何至少能识别出一个流卡住了，从而可以进去修复它？

Zeebe是一个免费的、开源的微服务编排工作流引擎，它提供。:

1. 可观测性 可以看到工作流的状态，包括在途工作流的数量、平均工作流持续时间、工作流中的当前错误等.

2. 工作流编排 基于工作流的当前状态；Zeebe将 "命令 "发布为可被一个或多个微服务消耗的事件，确保工作流按照其定义进行。.

3. 监控 监控超时或其他流程错误，加上配置错误处理路径的能力，如有状态的重试或将错误升级提交到技术团队来手动解决，确保工作流始终按计划完成。

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

• 不依赖外部数据库的水平扩展 Zeebe将数据直接写入部署在同一服务器上的文件系统，并可以轻松地在机器集群中分配处理，以提供高吞吐量。

• 容错 通过易于配置的复制机制进行容错，确保Zeebe能够从机器或软件故障中恢复，而不会丢失数据，并将停机时间降到最低。

• 消息驱动架构 ，其中所有与工作流相关的事件都被写入一个append-only的日志中。这些事件可以导出到外部系统进行长期存储，以提供完整的工作流审计日志等。

• 发布订阅模式 使连接到Zeebe的微服务能够保持高度控制，同时提供处理背压的机制。

• 可视化的BPMN2.0模型 使技术和非技术利益相关者能够以共同的语言合作设计工作流。

• 语言无关的客户端模型 可以使用任何编程语言来构建微服务的Zeebe客户端.

可以从这篇文档了解到更多技术架构相关的信息.

Zeebe解决了什么重要的问题以及这些问题为什么很重要

近年来，微服务架构越来越受欢迎，这是有原因的。专注的跨功能团队可以快速独立地交付价值，同时使用他们选择的技术栈。

但是，使微服务架构的松散耦合、独立的部署周期也带来了巨大的挑战。

微服务架构的一个核心原则是，每个微服务只负责一种业务能力。我们再参考前言中的电商例子，一个微服务负责支付处理，另一个微服务负责库存，另一个微服务负责发货，以此类推。

每一个微服务的存在都是为了促进更广泛的工作流程：尽可能快速、高效地让购物者得到他们想要的东西。而公司只有在端到端工作流成功的情况下才会成功，所以确保工作流质量至关重要。

在微服务架构中，每一个微服务只负责一个仔细范围的业务能力，谁来负责端到端的工作流？

默认情况下，没有人。事实上，端到端的工作流在公司内部可能都没有正式的文档，从微服务到微服务的事件流只在代码中隐性表达。

许多微服务架构都依赖于纯编排模式进行通信，微服务通过向消息平台发布事件和消耗事件进行协作，而不需要中央控制器（这种模式也被称为pub-sub，或pub-sub）。而编排确实为微服务的开发者提供了一定的灵活性.

然而，在其典型的实施过程中，编排并没有提供:

1. 可观测性 。有多少端到端工作流实例正在进行中，其状态如何？在过去24小时内，有多少工作流实例没有成功完成？为什么这些工作流实例没有成功完成？完成一个工作流实例或工作流中的一个具体步骤平均需要多少时间？
2. 故障处理 以确保即使发生错误时也能完成工作流。如果作为工作流一部分的服务发生故障，谁来负责处理？工作流的重试逻辑是什么？如果需要人工干预，我们有什么规则来及时升级问题？

因此，微服务架构有可能产生好的软件（在微服务层面），但业务结果却很糟糕。毕竟，工作流的成功与否最终决定了企业的成败。

开发团队如何在确保端到端工作流稳健的同时，获得微服务架构的好处？ 这就是Zeebe的优势所在。

Zeebe如何解决问题?

"工作流引擎 "这个标签与缓慢、低吞吐量的用例（如用户任务管理）有着传统的联系。

 而Zeebe则提供了高吞吐量、低延迟和横向扩展性。为了解释原因，我们来介绍一下Zeebe的几个关键架构概念。

首先，Zeebe不需要中央数据库组件，而是利用事件溯源，也就是说，工作流状态的所有变化都会作为事件被捕获，并存储在append-only日志中。在Zeebe中，这个日志被称为 "主题"。话题被直接写入Zeebe运行的服务器的文件系统中，工作流的当前状态可以从保存在话题中的事件中导出。

主题可以很容易地分布在集群中的各个节点上（分区），以实现可扩展性，分区通常会存储在多个节点上（复制），以实现容错。

Zeebe采用客户端/服务端模式。服务器（broker）是在Java虚拟机上作为自己的程序运行的远程引擎。broker负责存储与工作流相关的主题，在适当的时候将工作项目分配给客户端，并通过pub-sub将工作流事件流暴露给Zeebe客户端。Zeebe 客户端可以嵌入到应用程序中，以便连接到 broker。

现在让我们来谈谈Zeebe如何更实际地解决端到端的工作流程问题。Zeebe使用户能够:

• 明确定义和模拟跨越多个微服务的工作流。

• 详细了解工作流程的执行情况，并了解哪里存在问题。

• 编排满足定义的工作流的微服务，以确保所有工作流实例按照计划完成--即使在途中出现问题时也是如此。

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

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

总结:

• 您的业务依赖于一个或多个长期运行的工作流程的成功完成。
• 这些工作流程是由独立开发和独立部署的微服务来完成的，这些微服务通过pub-sub进行通信，没有中央控制机制。
• 虽然您可能对某个微服务的性能有深入了解，但您对工作流的端到端健康状况的可视性非常有限，因此，您的业务现状也是如此

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

下面是一个简单的图表，展示了如何使用Zeebe来实现跨越微服务的工作流的可观测性。

在这个例子中，Zeebe会订阅发布到您的消息平台上的事件，并将它们与您预定义的工作流相关联，该工作流已在BPMN 2.0中可视化建模，并部署到Zeebe broker中.

通过Zeebe处理的工作流相关事件，可以为仪表盘提供动力，建立热图以发现工作流中的问题区域，并在工作流实例出现问题并需要注意时建立警报工具。

在这个实现中，Zeebe超越了监控单个微服务健康状况的范围，并提供了对以下方面的可观测性:

• 目前有多少跨微服务的工作流程在进行中，它们的状态如何？
• 是否有流程因BUG或其他问题而 "阻塞"？
• 我们的平均端到端流程持续时间是多少？我们在流程中哪里遇到了问题？

在这个例子中，Zeebe纯粹是作为一个 "监听器 "来操作，并不直接与参与工作流的微服务进行交互。让我们来谈谈如何扩展这个 "可观测性 "解决方案，以利用Zeebe的编排功能。

用Zeebe解决工作流问题，第二步：微服务编排

微服务编排是Zeebe对我们在本文前面讨论的故障处理和重试问题的回答。

在微服务社区中，微服务编排有时被认为与松散耦合和独立部署性等微服务核心原则相悖。但情况并不一定如此! 微服务编排可以以符合这些原则的方式来实现，Zeebe也是这样设计的。 下面是一个简单的图，展示了Zeebe如何用于微服务编排。

这个架构与我们上面介绍的 "Zeebe for visibility "架构非常相似。一个显著的区别是，在我们的图中，我们已经删除了消息平台层，Zeebe直接与参与工作流的微服务进行通信。

 在不移除现有消息平台的情况下，仍然可以将Zeebe用于微服务协调--除了像 "可观测性 "解决方案中所说明的那样订阅与工作流相关的事件外，Zeebe还可以简单地将事件发布到消息平台。

但是Zeebe也可以在没有消息平台的情况下使用，我们想在这里强调一下这种方法。 你可以把Zeebe的工作流编排方法看作是一个状态机。当一个工作流实例进展到某个任务时，Zeebe会发送消息通知负责的工作者服务，然后等待工作者完成任务。  

一旦任务完成，工作者服务就会通知Zeebe，然后流程继续进行下一步。如果Worker未能完成任务，工作流仍停留在当前步骤，可能会重试任务，直到最终成功，或者在需要人工干预的情况下升级到其他团队。  

Zeebe将任务通知信息的创建与实际工作的执行脱钩，这意味着无论是否有Worker服务可以承担工作，Zeebe都能以最高速度发送任务通知信息。 Zeebe会将任务通知排队，直到可以将其推送给Worker。如果目前没有Worker服务，则工作信息保持排队状态。如果订阅了一个Worker服务，Zeebe的背压协议确保Worker可以控制他们接收任务的速度。 这种微服务编排方法仍然提供了对工作流和工作流实例的全面可观测性，同时也确保了工作流按照其定义完成，即使在途中出现故障。

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

水平扩展

规模化处理高吞吐量工作负载的能力对于Zeebe在微服务编排中的作用至关重要。为了处理大量的工作流实例，可能需要将Zeebe分布在一个机器集群上，以满足吞吐量的要求。

Zeebe使用分区来提供水平扩展性，根据我们的内部基准测试，分区提供了一种有效的方法，即使在一个相对较小的（5节点）集群上，也可以扩展到每秒启动数千个工作流实例。

高可用

Zeebe允许用户在创建主题时配置复制因子。复制因子决定了一个分区的 "热备份 "副本在其他经纪商上的数量。如果一个broker发生故障，另一个broker可以替换它而不会丢失数据。由于数据分布在集群中的各个broker，Zeebe提供了容错和高可用性。

无需额外的数据库

直接将数据存储在部署它的服务器的文件系统上，也不需要ZooKeeper等外部集群协调器。 Zeebe是完全独立的，自给自足的。

工作流可视化定义

在Zeebe中，ISO标准的BPMN 2.0是定义工作流程的默认建模语言。在技术和非技术利益相关者的充分参与下，工作流程被可视化地定义。虽然Zeebe对BPMN符号的覆盖范围不如Camunda BPM等更成熟的BPM平台那么全面，但Zeebe的路线图包括定期增加对新符号的支持。

语言无关

目前，Zeebe提供了Java和Go两种开箱即用的客户端。Zeebe客户端是基于gRPC的，这意味着Zeebe客户端可以很容易地用许多组织通常使用的编程语言生成微服务。

消息驱动

Zeebe的broker和客户端完全通过发布-订阅的方式进行通信，使得Zeebe和参与工作流的微服务之间可以坚持松散耦合的原则，实现异步通信。Zeebe的订阅协议中包含了背压机制，以确保客户端不会因为Zeebe的工作而负担过重。

历史记录审计

Zeebe提供了一个导出器，可以轻松地将工作流事件数据流导入存储系统，从而使这些数据可以无限期地使用。这对报告和可视性非常重要，而且根据您的行业，这也可能是出于监管的需要。