微服务、事件驱动架构和 Kafka

想象一下，有一个巨大的整体应用程序，其中许多复杂的功能紧密地联系在一起。可扩展性是一个很大的挑战，部署过程可能会变得非常繁琐，而且由于内部组件高度耦合，改变功能流程也不是那么容易。

也许很多人都熟悉这个概念，因为直到几年前这是构建应用程序的标准方法，而且现在生产中仍然有很多单体应用。

但与此同时，尤其是在云服务“爆炸”之后，构建产品的过程转向了微服务方法。具有明确范围的小型微服务，可以与其他服务进行通信以完成业务范围。

尽管它们有其缺点，如复杂的集成测试、更多的远程调用、更大的安全挑战等，但它们在这个行业中已经证明了自己的实力。由于微服务是解耦的，它们可以更容易地扩展，如果你想做出改变，你只需要改变一个组件，只要它们之间的契约得到尊重，其他的微服务不应受到那个改变的影响。

但是，当然，并不是所有事情都是甜蜜的。这种情况很快演变为有很多微服务，每一个都与其他人通信，像在单体中的意大利面代码那样“绑定”在一起。

所以，你现在有很多微服务，它们通过REST、Soap、消息队列或其他通信渠道相互通信。这确实更具扩展性。但这样开发更简单吗？更容易理解工作流程吗？

答案是不！事实上更难。为了理解一个单体的工作流程，你必须从一个方法跳到另一个方法，从一个类跳到另一个类。现在你必须从一个微服务跳到另一个微服务。要做一些更改，你必须确保微服务之间的向后兼容性。

对于测试，你现在必须进行一个异步的集成测试，由不同的微服务组成，它们彼此通信，并且最终部署在不同的实例上。这似乎并不更简单。那么转向微服务方法是一个错误吗？答案是不。我们只需要一个范式变化。

事件驱动架构

为了克服这种问题，一些微服务应用采用了事件驱动架构。这是因为事件驱动架构具有一些适合微服务方法的特点。让我们来看看它们。

事件与业务流程相符

从商业角度看，把工作流程描述为一系列事件更容易理解。商人不关心你的内部逻辑。他看到的是事件。

例如，假设我们有一个在线商店。你有一些实体，如：客户、订单、支付和产品。流程是这样的：一个客户订购一些产品，如果支付成功，产品应该交付给客户。如果你以非事件的方式实施这一点，你的工作流程可能是这样的：

客户使用网页界面认证在线商店。
客户通过Web界面与服务器建立HTTP会话。
客户进行REST调用来订购一些产品。
在服务器端，创建了一个订单对象，并将产品添加到其中。
服务器向客户发送支付请求。
如果支付成功，服务器确认订单，更新仓库，产品交付将开始。

这很好，但商人不关心REST协议、会话、认证等细节。他像事件流那样看待一切，这可能会触发其他事件：

客户创建一个订单
客户收到支付请求
如果支付成功，库存将更新并交付订单

这更易于人类阅读，如果出现新的业务需求，更改流程也更容易。

事件与操作相匹配，微服务只关心事件，而不关心其他微服务。我们将有一个微服务，它将获取一个事件，进行一些操作，并可能发送另一个事件。

在我们的情况下，一个客户端应用程序将从客户那里获得一些输入，并触发一个创建订单事件。一些订单服务将接收此事件，它将创建一个订单，并将一个订单创建事件发送到支付服务。这个服务将向客户发送一个支付请求，并尝试验证支付。如果支付成功，它将发送一个支付成功事件到一个仓库服务，这个服务将更新库存并交付产品。

流程更简单，微服务是解耦的。如果你想添加另一个应该记录已创建订单的服务，更改非常小。你需要创建该服务并订阅它的创建订单事件。由于这将与其他服务解耦，原始工作流程不会受到任何修改，风险将是最小的。

事件驱动架构模式

事件驱动架构有不同的风格。让我们看一下最常见的模式。

事件通知

在这种设计模式中，事件旨在仅通知状态更改。它们不带任何状态，只是告诉某事已经发生。通常，发送者不期望任何响应。它不是用于来回通信的。事件通知意味着发送者和可能的接收者之间有明确的分隔。因此，它们之间的耦合度很低。任何人都可以接收通知，发送者只是不关心。

让我们看一下在线商店的例子，看看这种模式如何应用。如果客户完成支付，那么支付服务可以发送一个通知，告诉支付已经成功。它不期望任何反馈。其他服务如何处理这个通知，完全取决于它们。

当然，这可能带来一些劣势。如果许多服务正在监听这种通知，如果此通知是复杂逻辑的一部分，跟踪流程并看到发生了什么非常困难。可能需要在生产环境中检查流程才能实际复现问题。

但是，尽管有其劣势，考虑到组件之间的低耦合度和你可以轻松扩展的方式，事件通知模式非常有用。

事件承载状态转移

顾名思义，在这个模式中，事件将包含整个状态而不仅仅是一个通知。客户端需要的所有信息都包含在那个事件中。客户端不需要为额外信息调用发送者。

如果我们看前面的例子，如果客户想买一些产品，他会选择它们并创建一个订单。然后，订单将发布到订单服务。订单事件包含完成订单所需的所有必要信息。客户详细信息，账单地址，产品，付款方式等。它不需要从客户那里获得任何其他细节。

显然，缺点是你从一个服务传递很多信息到另一个服务。

事件源

另一种事件驱动模式是事件源。在这里，所有事件都被记录，系统的状态可以通过重播所有事件来重新创建。整个记录库成为真理的唯一来源。

一个非常熟悉的例子是像GIT这样的版本控制服务，其中当前状态是通过重播所有提交来创建的。当然，你可以进行一些优化。例如，GIT会保留一个快照并与提交一起，所以当你克隆一个项目时，你实际上不是从开始重播所有提交，你是从一个快照开始的。但是，记录列表是真理的唯一来源。

这可以带来多种好处，如：

强大的审计功能。你可以看到每一个时间点发生了什么。
你可以重新创建历史状态。
通过返回到旧状态并应用不同的事件，你可以探索替代历史。

Kafka和事件驱动架构

如今有许多技术可以用来从一个组件传递事件到另一个组件，如Aws Kinesis, Apache Flink, Rabbit Mq等等。

在这篇文章中，我想谈谈Apache Kafka，它可能是目前最受欢迎的流媒体服务，以及为什么它非常适合事件驱动架构。

传统上有两种消息传传递模型：

消息队列：其中消费者从队列中读取。

优点：这种消息类型的优势是可扩展性。如果你需要更多的工人来处理事件，只需添加更多的消费者。
缺点：一个事件只被一个消费者消费。如果你希望两个不同的消费者获得相同的事件，那是做不到的。

发布-订阅者：其中一个消费者订阅一个发布者以获取某种类型的事件。使用这种模型，更多的消费者可以获得相同的数据。但是，由于所有的消息都发给所有的消费者，你不能并行化工作。

优点：事件分发给更多的消费者。
缺点：它不是可扩展的。

Apache Kafka是一个分布式流平台，每天能够处理万亿次的事件。考虑到它的设计，它为你提供了队列消息和发布-订阅服务的双重优势。

它是如何工作的

Kafka将事件存储在主题中。主题是数据的逻辑分割，如一个分类。例如：所有与客户请求相对应的事件可以保存在一个名为customer-requests的专用主题中，而所有与接收的付款相对应的事件可以保存在另一个名为payment-received的主题中。因此，如果你只想消费客户请求，那么你可以订阅customer-requests主题。这就像拥有多个消息队列，每个分类一个队列。

在内部，一个主题可以被分割成多个分区。分区是一个有序的、不可变的记录序列。