现代软件架构：事件驱动设计遇上事件溯源 _软件架构

在当今的软件领域中，做出正确的架构决策对于确保性能、可扩展性、可维护性和整体成功至关重要。在众多模式中，事件驱动架构（EDA）和事件溯源（ES）作为复杂软件系统最受欢迎的两种选择之一。虽然可以单独使用EDA或ES，但它们的结合可能效果惊人。

文章插图
事件驱动架构与传统的请求驱动系统相对立，传统系统中组件通过紧密耦合的方式显式调用彼此的方法或直接使用同步的API调用。在事件驱动架构中，组件通过事件间接通信，松耦合，促进灵活性、可扩展性和模块化。
事件溯源，另一个强大的设计模式也利用事件，强调维护事件的时间顺序记录，以实现更好的审计、分析和历史跟踪。事件溯源的主要理念是最终一致性。
让我们来详细了解它们，并看看如何将它们结合起来，构建一个适合我们使用案例的可扩展架构，有效服务数百万客户来自数千商家。
事件驱动架构解释事件驱动架构关注系统中事件的流动和处理。事件代表重要的事件或状态变化，在不同组件之间通信的骨干。在事件驱动系统中，组件（如微服务或函数）通过生成、检测和消费事件进行异步通信。这种方法促进了松耦合，允许灵活性、可扩展性，并对动态变化作出响应。EDA特别适用于分布式系统，在这些系统中，组件可以独立操作，在无需直接同步交互的情况下实时对事件做出反应。
EDA的常见使用案例：
1.可扩展的异步处理，即工作器

文章插图
通过消息代理实现可扩展的异步处理
在任务数量庞大且具有异步处理灵活性的场景中，此配置极具扩展性。在服务A中，组件X生成消息，并将其发布到消息代理（即事件代理）。随后，这些消息根据需要被许多消费者（称为工作器）订阅和处理。事件的来源可能包括cron作业、用户交互和类似来源。
在传统系统中，任务通常按顺序处理，或者在支持的堆栈中通过多线程支持。然而，即使有多线程支持，只有垂直扩展是可行的选项。
2.消息队列

文章插图
消息队列
【现代软件架构：事件驱动设计遇上事件溯源】这是上述异步处理的一种变体，但是工作器现在位于另一个服务中。这使得服务B能够在事件数量增加时无缝扩展。到达服务B的事件可能来自不同的服务。
这可用于由服务B负责同时处理大量小任务的体系结构，例如向移动设备提供大量推送通知或短信通知。
3.跨领域通信这是EDA的更高级版本，系统的多个组件可能对同一消息感兴趣，也可能不感兴趣。因此，复杂性更多地在代理端，事件通过不同的绑定路由到不同的服务。

文章插图
跨领域通信
上图展示了一个示例设置，其中服务A的事件通过不同的队列路由到服务B和C 。请注意，我在这里使用了RabbitMQ的术语：联邦、交换和虚拟主机。但是，这个设置也可以使用其他消息代理来完成。
事件溯源与CQRS在传统的以数据库为中心的方法中，我们通常存储实体的当前状态。相比之下，事件溯源将焦点从存储应用程序的当前状态转移到捕获并存储对该状态的更改的一系列不可变事件。这些事件表示系统中特定的事件或事务，并存储在事件日志或事件存储中。
1.关键概念

事件：表示系统中状态更改的不可变记录。事件捕获发生了什么，而不是当前状态。
事件存储：专门的数据存储，维护事件的时间顺序序列。这允许通过重新播放事件轻松重建系统在任何时间点的状态。
聚合：将相关事件分组的一致性单元。聚合负责执行业务规则和维护数据完整性。

很多情况下，事件溯源与CQRS结合使用。这将读模型（查询模型）和写模型（命令模型）分开，以实现关注点的分离。在此结合时，还有两个事件溯源的重要概念：
2.读模型专门用于查询和呈现数据的模型。它对读取操作进行了优化，并根据写模型生成的事件构建。读模型是去规范化的，并根据其服务的查询需求定制。从相同的事件源，可以构建不同视图的读模型，为业务领域提供不同的视角。