事件驱动 2.0

事件驱动 2.0

本文译自：Event Driven 2.0

在本文中，我们将讨论事件驱动架构与其他流行的消息驱动架构有何不同。

需要处理、过滤、连接和存储的数据量不断增长。能够快速处理数据的公司具有优势。理想情况下，它应该实时发生。事件驱动架构用于此。

这种架构允许实时交换消息，将它们存储在单个数据库中，并使用分布式系统发送和处理消息。

在本文中，我们将讨论事件驱动架构与其他流行的消息驱动架构有何不同。此外，我们还将学习最流行的事件驱动架构模式，以及它们的主要优缺点。

事件驱动与消息驱动架构

事件是在特定时间点发生的一些动作。它由服务生成，没有特定的收件人。任何系统组件都可以是事件消费者。

消息是从一项服务发送到另一项服务的固定数据包。事件是一种表示系统状态发生变化的消息。

在事件驱动架构中，生成事件的组件告诉其他组件它将存储在哪里。这样，任何组件都可以保存、处理和响应事件，而生产者将不知道消费者是谁。

在消息驱动系统中，创建消息的组件将消息发送到特定地址。发送消息后，组件立即接收控制，不等待消息被处理。

在消息驱动的架构中，如果需要将类似的消息发送给多个接收者，则发送者必须将其分别发送给每个接收者。相反，在事件驱动架构中，生产者生成一次事件并将其发送到处理系统/之后，该事件可以被连接到该系统的任意数量的订阅者使用。

事件驱动模式

有不同的方法来实现事件驱动架构。通常，在设计程序时，会同时使用多种方法。在本节中，我们将讨论允许您实现事件驱动架构的最流行的模式、它们的优势和应用领域。

全球事件流媒体平台

对于当今的公司来说，实时响应事件至关重要。客户希望企业能够立即响应各种事件。因此，需要开发这样的软件架构来满足现代业务需求，并且能够将数据作为事件流进行处理，而不仅仅是处于静止状态的数据。

一个很好的解决方案是使用全球事件流平台。它允许您将业务功能作为事件流进行处理。此外，该平台具有容错性和可扩展性。

系统中发生的所有事件都在数据流平台中记录一次。外部系统读取这些事件并实时处理它们。

事件流平台由一组不同的组件组成。它们的创建需要大量资源和工程经验。这种模式非常流行，并在许多行业中使用。

中央活动商店

中央事件存储确保在单个数据库中发布和存储事件。它是各种类型事件的单一端点。这允许应用程序和服务实时响应事件，而不会延迟或丢失数据。应用程序可以轻松订阅各种事件，降低开发成本。

中央事件存储用于多种目的：

• 发布消费者服务变更。
• 重建过去的状态并进行业务分析。
• 搜索事件。
• 将所有程序更改保存为事件序列。
• 基于应用程序状态更改的通知的单个端点。
• 监控系统状态。

使用中央事件存储，您可以创建新应用程序并使用现有事件，而无需重新发布它们。

事件优先和事件流应用程序

事件流允许您从各种来源接收数据，例如应用程序、数据库、各种传感器、互联网设备等，处理、清理和使用它们而无需先保存它们。这种事件处理方法提供了快速的结果，对于传输大量数据并需要快速接收信息的公司来说非常重要。

事件流平台的主要优势：

• **提升客户体验：**客户可以即时了解订单状态的变化，提升客户体验，进而增加公司收入。
• 降低风险： 使用流式事件的系统可以检测互联网上的欺诈行为，可以停止可疑交易或阻止卡片。
• **可靠性：**事件流平台支持能够有效处理订阅者故障的强大系统。
• **实时反馈：**用户可以在执行后立即看到自己的操作结果，无需等待一分钟。

事件流系统需要较少的基础设施和数据来支持，因此它们的构建简单且快速。

使用这种架构模式的应用程序被用于各种行业，例如金融交易、金融系统中的风险和欺诈检测、物联网、零售等。

CQRS

Command Query Responsibility Segregation (CQRS) 是分离读写信息的数据结构的原则。它用于提高软件的性能、安全性和可扩展性。

CQRS 的应用在单一数据读写模型过于复杂的复杂领域非常有用。分开后，就大大简化了。当读取和写入操作的数量明显不同时，这一点尤其明显。

可以使用不同的数据库来读取和存储数据。在这种情况下，它们必须同步。为此，记录模型必须在每次更新数据库时发布一个事件。

CQRS 的优点：

• 读取和写入工作负载的独立扩展。
• 用于读取和写入的单独优化数据方案。
• 由于关注点分离，使用更灵活和方便的模型。
• 能够通过将物化视图存储在读取数据库中来避免复杂的查询。

CQRS 模板适用于以下场景：

• 在许多用户同时访问相同数据的系统中。
• 何时应将数据读取性能与数据写入性能分开配置。当读取次数大大超过写入次数时，这一点尤为重要。
• 当读写模型由不同的开发团队创建时。
• 随着业务规则的频繁变化。

在系统逻辑和用户界面非常简单的情况下，不推荐使用此模板。

事件溯源

事件源将系统状态存储为事件序列。每当系统状态发生变化时，一个新事件就会添加到事件列表中。但是，此系统状态可以通过将来重新处理事件来恢复。所有事件都存储在事件存储中，它是一个事件数据库。

这种架构的一个很好的例子是版本控制系统。它的事件存储是所有提交的日志，源树的工作副本是系统状态。

事件搜索的主要优点：

• 每次系统状态更改时都可以发布事件。
• 确保可靠的更改审核日志。
• 随时判断系统状态的能力。
• 通过使用交换事件的松散耦合对象轻松地从单体应用程序过渡到微服务架构的能力。

但是重构业务对象的状态，需要发送标准的请求，难度大，效率低。因此，系统必须使用命令请求责任分配（CQRS）来实现请求。这意味着应用程序必须处理最终商定的数据。

自动数据供应

此模式提供完全自助式数据供应。用户必须确定他需要什么数据，需要什么格式，以及数据应该存储在哪里。例如，在数据库、分布式缓存、微服务等中。选择的存储库可以与中央存储库一起使用。

该系统为客户提供基础设施以及预加载的数据并管理事件流。处理器根据用户要求对数据流进行处理和过滤。云基础设施的使用使得这样的系统更快、更实用。

使用自动数据供应的系统用于金融、零售和 Internet，包括本地和云端。

事件驱动架构的优缺点

尽管事件驱动架构现在很流行，发展很快，有助于解决很多业务问题，但是使用这种方式也有一些缺点。在本节中，我们列出了事件驱动架构的主要优点和缺点。

优点

• **自治：**使用此架构的组件的松散耦合允许事件生产者和消费者彼此独立运行。这种连接允许您使用不同的编程语言和技术来开发不同的组件。此外，可以在系统中添加和删除生产者和消费者，而不会影响其他参与者。
• **容错：**事件发生后立即发布。各种服务和程序订阅这些事件。如果消费者关闭，事件将继续发布和排队。当消费者重新连接时，它将能够处理这些事件。
• 实时用户交互以获得更好的用户体验。
• **经济性：**消费者在生产者发布消息后立即收到消息，无需不断轮询来验证事件。这减少了 CPU 消耗和网络带宽使用。

缺点

• 错误处理很困难。由于事件生产者和消费者可能很多且连接松散，因此很难跟踪它们之间的操作并确定故障的根本原因。
• 无法预测不同时期发生的事件。由于事件是异步的，因此无法预测它们发生的顺序。此外，可能存在重复，每个都可能需要上下文响应。这需要额外的测试时间和深入的系统分析以防止数据丢失。
• 生成事件的系统与接收事件的系统之间的弱连接可能是攻击者可以利用的漏洞点。

结论

事件驱动架构已经存在了很长时间，并被用来传递消息。结合现代商业需求，他们正在积极开发并提供更好的连接和管理机会。正如许多现代系统所要求的那样，事件驱动架构对于实时事件处理是必不可少的。

要实现这样的体系结构，有几种不同的模式，每种模式都有其优点和应用程序特性。在设计系统时，需要明确定义其功能和应用，以选择正确的模式。

尽管事件驱动架构被广泛使用并具有许多优点，但其特性有时会对系统产生不良影响，在设计时必须考虑到这一点。