如何设计事件流，第 1 部分

事件流在当今世界变得越来越普遍。事件是一条数据，它以时间快照的形式描述了您的业务中发生的重要事件。我们将该数据记录到事件流(通常使用 Apache Kafka 主题)，这为其他应用程序和业务流程做出相应的响应和反应提供了基础——也称为事件驱动架构 (EDA)。

事件驱动架构 (EDA) 广泛依赖于事件。为了在 EDA 方面取得成功，您需要知道如何正确设计您的活动，因为这不仅会显着影响您今天可以做的事情，还会影响明天的事情。

设计活动可能具有挑战性，特别是在考虑消费者的不同需求、数据格式和延迟要求时。在这篇文章中，我们将讨论构建事件时的主要考虑因素之一：围绕状态进行设计与围绕更改进行设计。

但首先，让我们看一下事件流的基础知识。

什么是事件?

事件代表在特定时间点发生的事件。

事件确实可以代表任何事物，但它几乎总是代表对业务重要的事物。例如，电子商务企业可能会记录有关销售、订单、客户、交货和库存的事件。航空公司可以记录有关付款、航班、飞行员、航线、机场和航班遥测的事件。

事件流的基础知识

事件流(有时也称为数据流)是一系列事件，发布到不可变的仅附加日志代理(例如Apache Kafka)。生产者系统将事件写入流(Kafka 主题)，该流由一个或多个消费者系统消费。一旦记录了事件，它们就会被写入事件流中。

· 事件和事件流都是完全不可变的——一旦发布，您就无法更改它们的内容，也无法更改它们在流中的顺序。就像生活一样，你无法改变过去:)。

· 多个消费者可以根据自己的选择使用该事件。

· 事件是持久且可重玩的。与传统的排队系统不同，写入主题的事件仍然可以根据您选择的次数进行处理和使用。

流中的事件日志可用于构建系统随时间变化的详细情况，而不仅仅是当前的快照。

设计活动时需要考虑几个因素。目标消费者是谁?事件是在单个系统内生成以供同一系统内部使用吗?还是与外部消费者共享，例如其他系统、团队和人员?

事件设计中最大的问题之一是决定哪些数据应该出现在事件中，哪些数据不应该出现。解决这个问题需要采用与确定服务边界和 API 组成相同的思维方法。我们将什么封装在服务内部，以及我们愿意向更广阔的世界公开什么?

让我们更深入地了解一下。

内部数据与外部数据

所有(或至少绝大多数)服务都包含数据——已提供、创建、计算、处理或计算的数据。其中一些数据是私有的，一些是公共的，一些表示作为业务流程一部分的中间表单，一些表示需要与其他系统共享的数据。

无论如何，您可以将服务的数据需求分为两个阵营：

· 内部数据由应用程序或服务内部的数据模型和数据结构组成。此数据是您的系统私有的。但它还包括您可能想要在边界之外共享的数据。

· 外部的数据是我们与其他系统共享的数据。它是为其他团队、系统和人员的发现、消费和使用而明确建模的。

内部数据的两个示例：数据库支持的系统和事件源系统

服务可以将其数据存储在关系数据库、键值存储、文档数据库中，甚至存储在一组事件流中(例如在事件溯源系统中)。内部数据是私有的，专门供系统内部使用。它是根据其服务的需求进行建模的。它不适合其他系统和团队使用，也不向更广阔的世界开放。它保持封装并与服务内部工作的需求紧密耦合。

内部(内部数据)和外部(外部数据)世界的高级视图

相反，外部的数据是我们与其他系统共享的数据。它是为其他团队、系统和人员的发现、消费和使用而明确建模的。创建外部模型需要与下游消费者进行协商，还需要考虑状态、变更、非规范化、安全性、性能和成本——当我们研究事件设计的四个主要因素时，我们将涵盖所有内容。

内部/外部数据是思考数据用途以及谁应该能够访问和使用数据的有用方法。正如我们必须考虑通过 REST API 向其他服务公开哪些数据一样，我们还必须考虑使用事件向其他服务公开哪些数据。

还有一个与 REST API 类似的地方值得探索。当您成功发出 REST 请求(例如 GET)时，您将收到包含键和值的数据负载。然后，您必须解析该数据以获得对您的服务的意义。但我们并不期望每个使用 REST API 的人或服务都能自己弄清楚这些数据的含义。不，我们(通常)为他们提供文档和他们应该期望的数据的模式，以便他们可以轻松使用它 - 事件也不例外。

模式对于创建可重用、可发现且无错误的事件流至关重要。它们提供基础和结构，并赋予事件随时间演变和变化的能力。让我们更深入地了解一下。