虽然事件驱动架构的主要关注点是处理事件，但在某些情况下，您需要将事件保留用于后处理和其他应用程序的查询。事件主干具有内置事件日志，可用于存储和回复发布到主干的事件。但是，考虑到事件驱动解决方案的全部范围，可以支持其他用例和商店类型：
- 针对分析进行了优化的事件存储
- 事件源作为记录跨分布式系统的状态更改和更新的模式
- 命令查询响应分离（CQRS）作为一种优化，可以跨不同的存储区分更新和读取
当系统状态发生变化时，应用程序会发出有关状态更改的通知事件。任何有兴趣的人士都可以成为活动的消费者并采取必要的行动。状态更改事件按时间顺序存储在事件日志或事件存储中。事件日志或商店成为事实的主要来源。通过在将来的任何时间重新处理事件，可以将系统状态重新创建到某个时间点。状态变化的历史成为业务的审计记录，并且通常是数据科学家获取业务洞察力的有用数据来源。
在某些情况下，事件源模式通过使用事件日志和Kafka流完全在事件主干内实现。但是，您还可以考虑使用外部事件存储来实现模式，该存储提供了如何访问和使用数据的优化。例如，IBM®Db2®EventStore可以提供连接到主干的处理程序和事件存储，并为数据的下游分析处理提供优化。
在操作中，事件存储将按时间顺序保留具有时间戳的对象的所有状态更改事件，从而为对象创建时间序列的更改。您可以通过重播时间系列中的事件来派生对象的当前状态。事件存储只需要存储三条信息：
- 事件或聚合的类型
- 事件的序列号
- 数据作为序列化blob
您可以添加更多数据来帮助进行诊断和审计，但核心功能只需要一组很小的字段。这种方法导致数据设计可以大大优化，以便附加和检索记录序列。
命令查询责任分离（CQRS）
事件日志会导致更多工作来支持业务查询，因为它需要将事件转换为适合查询的应用程序状态。
CQRS应用模式经常与事件源有关。在此模式中，您将命令操作与查询/读取操作分开。使用事件源模式和CQRS，您通常会得到一种模式，其中更新作为状态通知事件（状态更改）完成。这些事件将保留在事件日志或存储中。在读取方面，您可以将状态保留在针对其他应用程序可能查询或读取数据的方式进行优化的不同存储中。
事件溯源，CQRS和微服务
随着微服务的采用，你有一个明确分离的状态，以便微服务与自己的状态有关。此外，通过使用事件源，您可以创建难以查询的历史记录日志。当您需要实现需要从多个服务加入数据的查询时，就会遇到挑战。要解决服务编排问题，您可以使用API组合或CQRS模式。
对于API组合，查询由与所有其他微服务集成的操作支持，并且可能转换数据以组合结果。使用此模式，您需要评估聚合要求，因为它们可以显着影响性能。您可能需要评估此API组合组件的放置位置。该组件可以是API网关，后端前端（BFF）的一部分，甚至是它自己的微服务。
另一个答案是实现CQRS模式，其中状态更改由相关业务对象作为事件发布。每个更改都保留在事件日志或事件存储中，更高级别的操作将订阅每个事件，并将数据保留在可查询数据存储中。
下一步是什么
阅读有关CQRS模式的更多信息。
讨论；加入知识星球【首席架构师圈】