我正在阅读“构建事件驱动的微服务”。
它指出事件代理的要求是:
Infinite retention: Event streams must be able to retain events for an infinite period of time. This property is foundational for maintaining state in an event stream.
然而，这似乎并不是标准可用的。例如，Azure 事件中心的最长保留策略为 7 天，事件网格也有最长重试和保留时间策略。
有哪些技术可以应对所使用的事件代理技术的保留限制？
最佳答案
嗯，这取决于您事件的目的。
如果您使用事件在不同服务之间编排操作，那么您就是在使用事件来将不同服务彼此解耦。此类事件包含其他服务执行其应该执行的操作所需的一切。在这种情况下，无需将这些事件保留在存储中直到时间结束。一旦服务处理了事件，它本身就确定了其对象的新状态，并且很可能将此更新后的状态存储在某种特定于服务的存储中。
如果您使用事件来记录导致某事物的状态发生变化的操作，那么您正在执行事件溯源，并且事情会变得不同。在进行事件溯源时，您希望重放事件流以确定某个时间点的状态，而不是存储当时的状态本身。这意味着您希望随时重播此事件流(例如，当您启动服务的新实例时)。在这种情况下，事件应该“永远”存储。
一种可能的解决方法是创建快照。快照表示对象在某个时间点的状态。新操作将作为事件流再次存储在事件存储中，旧事件可能会被丢弃。在保留期结束之前，您应该更新快照以代表新的当前状态，并再次丢弃快照之前发生的事件。如果您需要重播事件，请从已知快照开始并处理所有后续事件以了解对象的新状态。一个重要的注意事项是，使用快照的副作用是丢失导致某一时间点状态的所有详细信息。
另一个解决方案是使用不同的事件存储，它允许您指定保留期...
事件溯源方法和“快照”存在不同的框架。您或许应该看看 AxonIQ 和 Eventuate 等解决方案。
可以使用事件来进行流处理。在这种情况下，您“只是”想要高速记录事件，就像在典型的物联网解决方案中捕获传感器数据一样。获取这些数据后，您想要对此事件流进行计算，因此称为流处理。是否要将这些事件保留到时间结束取决于项目的用例。如果不允许您更改保留期，您可以做的就是在摄取原始事件后将其存储在单独的专用存储中。该存储是进一步事件处理的基础。对于此类用例，您可以看看 Apache Kafka。
希望这能解答您的一些疑问...
关于architecture - 如何处理事件驱动架构中缺乏无限保留的问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69058355/