从AWS Eventbridge归档中读取事件数据。

Question

我正在寻找我们事件溯源解决方案的选项。由于我们已经在使用AWS Eventbridge，因此收到了使用Eventbridge Archive的推荐。

根据我所发现的有关存档功能的信息，它可以存储我们发送到事件总线的所有事件，并可以根据过滤器稍后重放它们。

问题是我无法找到一种在不重放事件的情况下从此存档中读取数据的方法。

是否有人知道是否存在允许我这样做的API？

我在Google上找到的所有内容都是关于创建、存档和重放的，但没有关于从存档中存储的事件中读取数据的相关信息。

我发现了这个问题，但它没有任何答案。

- Raul

---

请澄清一下，您是在寻找一种方法来提取一个特定的事件吗？ - Levi Ramsey

基本上，EventBridge文档在其首页上告诉您它是一个事件总线，旨在支持事件驱动的系统。它不是事件存储，不能用作存储事件的数据库。我不会将其写成答案，因为它并没有回答您的问题，但我建议您放弃那个建议。 - Alexey Zimarev

@AlexeyZimarev，我知道Eventbridge不支持这个功能。我在谈论存档。Eventbridge有一个存档功能，可以根据过滤器（如Eventbridge规则）存储事件。但似乎唯一访问这些归档事件的方法是使用重放功能，这并不理想。 - Raul

@LeviRamsey 不完全是。我的目标是以一种可以运行查询的方式存储所有事件。我找到了这个存档功能，但它似乎不允许查询。我认为实现我想要的方法是将所有事件发送到 Lambda，然后将它们写入数据库。 - Raul

@Raul，你所说的就是我所谓的“不适合这份工作”。你需要一个数据库，而不是一个经纪人。 - Alexey Zimarev

Answer 1

免责声明：该回答仅基于对Eventbridge文档的快速浏览。

事件溯源是一个有点过载的术语，它被用来表示从基于交换事件的架构到使用持久化事件作为真实数据来源的各种含义。

在后一种用法中（也许可以称之为“完全事件溯源”），严格来说，所有读取都是重放事件流，存在多个事件流，并且同一事件经常会被写入多个事件流（例如，“购物车结帐”事件可能会被写入特定购物车的事件流以及只包含“购物车结帐”事件的事件流）。

EventBridge和EventBridge Archive似乎足以实现“完全事件溯源”：每个事件流都成为事件总线。 动态创建新的总线可能不太便捷，向多个流发布相同事件的机制可能很复杂（例如，服务接收基本事件并不断将其投影到其他流中），假设您的实体数量少于100个（因为AWS账户限制为100个事件总线）。 如果您的实体数量超过100个，则EventBridge不适合事件溯源。

尽管如此，在事件溯源系统中，几乎普遍存在一些无法映射到重放流的读取功能（例如，针对事件的即席查询/聚合）。 这就是Command Query Responsibility Segregation（CQRS）的用处：如果采用CQRS，则

• 在应用程序中有多个数据模型
• 工作负载使用最适合该工作负载的数据模型

应用程序的命令处理/写入方面通常受益于事件溯源（特别是如果有基础架构帮助某些并发控制/缓存/维���单个写入者的组合）。 然后将事件流投影到其他数据模型（例如，数据库或搜索系统或警报基础架构），这些数据模型可以针对将针对它们执行的查询进行调整。

因此，您的问题可能更好地表达为“如何在事件溯源系统中执行CQRS”，幸运的是，已经有一套成熟的技��体系。 在您的情况下，将所有（至少一些）流中的所有事件发送到Lambda，然后将它们写入数据库可能是支持CQRS的合理方式。

- Levi Ramsey

---

“事件溯源”这个术语的问题不在于它被“重载”，而是被某些供应商误解和扭曲，以满足其营销目的，使其产品适用于本不应该适用的领域。 Greg Young 十多年前定义的事件溯源只是一种通过将状态转换存储为事件来持久化实体状态的方法。这意味着恢复给定实体的状态需要读取所有这些事件。消息代理根本没有为此设计，今天存在的任何消息代理都不符合这个基本要求。 - Alexey Zimarev

如果您的实体少于100个，则EventBridge加上Archive可以满足该要求。在此配额内，您可以读取单个实体的所有事件。 - Levi Ramsey

我要注意一下，@AlexeyZimarev，你是事件溯源解决方案供应商的员工。 - Levi Ramsey