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 月正式投入生产应用。
在 InfoQ 的一次采访中,Rucker 指出,他认为订单履行(这对一个公司来说非常重要)有点奇怪,它不是在核心领域处理的,而是必须通过监控事件来完成,因为这样可以检测是否有任何订单被卡住了。在他看来,订单履行服务应该关注订单的履行情况,而不是仅仅发布一个已创建订单的事件,并希望其他服务确保支付得到处理和货物交付给客户。
我们通常讨论事件流,但 Rucker 认为我们应该讨论记录或消息流,他还强调,Kafka API 中的术语是记录,而不是事件。在他看来,Kafka 可以用于不同类型的消息,比如事件和命令,他提到了Gregor Hohpe和Bobby Woolf的重要著作《企业集成模式》,其中描述了命令、文档和事件消息。
查看英文原文:Event Streams and Workflow Engines – Kafka and Zeebe
评论