活动来源-活动流澄清

Question

我进入了一个微服务项目，并且遇到了这个问题。 假设您有一个由两个微服务组成的表预订服务：

• 餐厅服务（管理餐厅信息，例如名称，所有者，餐桌）。
• 预订服务（管理预订验证 工作流程）。

“餐厅”实体的事件流非常简单：streamId是restaurantId，每个事件（例如“ tableAdded”或“ tableRemoved”）都有一个递增的eventId。 重播每个事件并获得汇总很简单。

那预订呢？ 我当前的事件流设计使用restaurantId作为streamId，并且每个事件（例如“ reservationAccepted”或“ reservationRefused”）都将附加到该流。

负责确认预订请求的算法需要知道之前和之后的预订（从传入请求的预订时间起3小时之内）。

无论如何，都应考虑预订时间早于 now 的预订，并且不应该重播其事件，但是采用这种设计时，会针对每个请求重播每个事件。

总结：如果我要明天预订，系统会重播6个月前的预订，这些预订通常与传入请求无关，因为它们指的是过去的某个时刻。

随着时间的流逝，由于大量不必要的事件被重播，导致效率低下。我本以为可以使用每日快照来解决它，但这似乎是错误的方法。

有什么想法吗？

在此先感谢您的帮助！

Answer 1

我建议学习有关CQRS https://martinfowler.com/bliki/CQRS.html的知识，这在使用事件驱动时是一个很重要的难题。

简而言之，在单独的实体中保留与业务需求相关的事件的视图是合理的，您可以使用相关数据进行查询。

在您的示例中，有一个关于请求验证的业务需求，因此有意义的是，您可以从事件中建立一个表，您可以简单地要求最近3个小时的预订以在创建之前接收相关信息一个有效的新事件。

这有时也称为投影：https://dzone.com/articles/the-good-of-event-sourcing-projections

投影可以是

1. 在验证发生时进行计算（可能效率不高，如您所述）

2. 与该投影相关的新事件发生时重新计算或更新。

3. 这些选项之间对您来说有意义的一切。