事件流和工作流引擎——Kafka 与 Zeebe

Apache Kafka 是一个高度可伸缩的分布式流平台，通常用于在基于微服务的系统中分发消息或事件。这些事件有时是业务流程的一部分，其中的任务分布在多个微服务上。要处理复杂的业务流程，可以使用 工作流引擎 ，但是要匹配 Kafka，它就必须提供与 Kafka 相同的可伸缩性。 Zeebe 就是一个为了满足这种可伸缩性需求而生的工作流引擎，目前正在开发和设计中。在阿姆斯特丹的一次联席会议上， Kai Waehner 描述了 Kafka 的特性，以及它如何适用于 事件驱动架构 （EDA）， Bernd Rucker 介绍了工作流引擎、Zeebe 以及它如何与 Kafka 搭配使用。

对于 Confluent 的技术布道者 Waehner 来说，如今许多人使用 Kafka 的一个原因是越来越多的应用程序、微服务、移动应用程序和物联网设备被集成在一起，从而提供了更多的数据。我们必须处理比以前更多的消息，并且以更快的速度增长，而且通常是实时用例。许多年前，我们开始构建点对点集成，但是它的伸缩性不是很好，而且很难维护。大约 10 年前，我们开始使用企业服务总线（ Enterprise Service Bus ，缩写 ESB）进行集成。今天，ESB 被一个类似 Kafka 的消息流平台所取代，所有应用程序都连接到这个平台上。

EDA 不是一个新概念；这个概念已经存在了至少 10 到 20 年。新问题在于我们如何处理数据。不再将数据存储在数据库中供其他一些服务读取和处理，这些数据现在是流动的，并且是连续处理的。事件流平台的一个重要区别在于，它不像 SQL 或 NoSQL 数据库那样使用静态存储，而是存储事件或其他消息。这将影响你构建应用程序的方式；现在，事件被发布出来供其他应用程序消费。

Waehner 指出，Kafka 关乎三个概念：消息传递、数据存储和处理。它是一个消息传递代理，就像许多其他代理一样，它是一个存储系统，在这个系统中，数据可以存储任意期限，最后它还可以处理数据。Kafka 与数据库共享的两个重要特性是：

• 严格的消息排序，这在许多用例中都非常重要；

• 持久性，所有消息都存储在磁盘上，这意味着它在崩溃的时候也可以不丢失数据。

Kafka 的另一个关键组件是，它是按分布式设计的，并且在构建时充分考虑了失败。其主要概念包括复制、容错、分区和弹性缩放。

根据 Waehner 的经验，许多开发人员只将 Kafka 看作是一个消息传递平台，因此，他指出，Kafka 还包括两个组件：

• Kafka Connect，一个基于核心 Kafka 的集成框架；连接器的例子里包括许多数据库和消息传递系统；

• Kafka Streams 用于流处理，在 Waehner 看来，这是处理数据最简单的方法。

Waehner 最后指出，越来越多的人在构建核心业务应用程序时使用 Kafka——Kafka 在运营业务。分析业务仍然很重要，但这只是一小部分。他看到的另一个趋势是，他的大多数客户都是混合的；他们在云中构建新系统，但仍然有自己的系统，而且它们都需要通信。

Bernd Rücker

Rucker 是 Camunda 的联合创始人和开发大使，他认为，在过去的几年里，在他的客户中，有一个明显的使用微服务的趋势。他还注意到一种趋势，即一些客户已经开始使用事件驱动方法，而且现在正在将其用于所有事情。

使用 事件通知模式 ，系统由负责业务不同部分的微服务构建。服务发布事件来通知其他服务正在发生的事情。要完成业务功能，可能涉及多个服务，它们相互发送事件。Rucker 将此称为点对点事件链，他指出一个问题，就是很难从业务角度得到整个流图。他引用 Martin Fowler 的一篇文章指出， 尽管事件通知模式可能很有用，但它也增加了忽略更大规模流的风险 。

重新获得事件流视图的一种方法是使用监控和跟踪。在 InfoQ 的一篇文章中，Rucker 介绍了 如何实现这一功能的例子 。流程跟踪是他喜欢的方式，因为通过建模工作流并使用工作流引擎侦听所有事件，可以从业务角度验证每个事件流是否正确工作，并在它们失败时获得通知。

Rucker 指出，过程跟踪很容易应用，因为不需要修改任何东西；只需将工作流引擎附加到 Kafka 基础设施就可以。这也是处理潜在故障的第一步，例如，当流程花费太长时间才能完成时，添加超时和警告。他提到了 Vodafone 关于如何 替换现有中间件 的一个演示，首先使用跟踪，然后借助 编制 逐步替换每项任务。

点对点事件链的一个潜在问题是当工作流需要更改时，可能会要求多个服务必须更改它们的事件订阅。这还需要团队之间以及服务部署的协调，以及考虑系统中正在运转的工作流和活动事件。为了确保业务流程的实现，Rucker 更愿意将端到端职责提取到一个服务中。这样有一个好处，你将有一个服务专门负责对公司而言非常重要的事情，并且只有一个点可以控制任务的顺序。这也提供了开始使用命令来控制工作流的可能性。命令是编排—你告诉某人做某事—但是 Rucker 指出，编排是微服务的内部组成部分，而不是每个服务都使用的中心基础设施机制。他还指出，对于一个负责工作流的服务，有一个点可以检查正在运行的命令的状态、命令成功的数量等等。

Camunda 目前正在开发 Zeebe，这是一个面向微服务的水平可伸缩的工作流引擎，它适合与 Kafka 一起用于低延迟和高吞吐量的用例。它仍然处于开发人员预览状态，但是，他们有运行 100~200k 工作流实例的试点客户。据 Rücker 介绍，Camunda 计划于 2019 年 7 月正式投入生产应用。

感兴趣的读者可以查看 Wahner 和 Rucker 的幻灯片。

在 InfoQ 的一次采访中，Rucker 指出，他认为订单履行（这对一个公司来说非常重要）有点奇怪，它不是在核心领域处理的，而是必须通过监控事件来完成，因为这样可以检测是否有任何订单被卡住了。在他看来，订单履行服务应该关注订单的履行情况，而不是仅仅发布一个已创建订单的事件，并希望其他服务确保支付得到处理和货物交付给客户。

我们通常讨论事件流，但 Rucker 认为我们应该讨论记录或消息流，他还强调，Kafka API 中的术语是记录，而不是事件。在他看来，Kafka 可以用于不同类型的消息，比如事件和命令，他提到了 Gregor Hohpe 和 Bobby Woolf 的重要著作《 企业集成模式 》，其中描述了命令、文档和事件消息。

查看英文原文： Event Streams and Workflow Engines – Kafka and Zeebe