拥有专门的事件存储服务是否明智

Question

我的项目有一个整体应用程序和围绕它的许多微服务。微服务通过 Pub/Sub (ServiceBus) 和 API 进行通信。

每个服务，包括单体应用，都会为每次更改发布事件。

目前我正在尝试设计一个存储多个实体的更改历史记录的解决方案。我应该能够查看所有更改并生成一份报告，告诉我两个日期之间发生了什么变化。

我入围的选项是：

1. 使用数据库的功能来跟踪更改（例如，SQL Server 中的更改数据捕获 (CDC)）并从中生成报告。但在每项服务中启用跟踪听起来既复杂又昂贵。
2. 使用事件溯源 - 我是事件溯源的新手，不确定这是否有点过头了。考虑到我想要实现的目标，更新现有的微服务在我的情况下也很昂贵。
3. 创建一个新的专用事件存储微服务 - 它所做的就是将系统中的每个事件记录到事件存储中，并通过 API 公开聚合的事件数据。该服务将存储来自所有实体和所有域的事件数据。

我已经有一个以这种方式审计日志记录的微服务，所以这可能会取代它。见下图。

这有道理吗？可能会出什么问题？期待看到一些想法。塔！

Answer 1

Vlad Khononov 在他的书学习领域驱动设计中专门关于事件溯源的章节中分享了他对这个问题的想法：

为什么我不能将日志写入文本文件并将其用作审核日志？

将数据写入操作数据库和日志文件是一种容易出错的操作。本质上，它是针对两种存储机制的事务：数据库和文件。如果第一个失败，则必须回滚第二个。例如，如果数据库事务失败，没有人关心删除先前的日志消息。因此，此类日志不是一致的，而是最终不一致的。

这个答案希望能给您带来一些思考。它可能并不直接适用于您的情况，因为您已经将所有状态更改作为事件发布，因此只要您确保在其他地方（即在专用事件存储微服务中）使用它们，您就可以在某种程度上保证事件日志保留（最终）一致。

该方法（发布所有状态更改的事件，但不应用事件源作为存储模式）的最大缺点是，在添加状态更改时更容易犯错误，例如忘记发布状态更改的事件。例如新功能。如果其他开发人员现在或将来在您的代码库上工作，这一点尤其正确。选择使用事件源作为应用程序状态的存储模式，可以使每个状态更改时事件的创建、存储和发布更加明确，反过来，您（或其他人）以后将更难通过以下方式引入错误/不一致： ，例如，无意中不发布某些给定状态更改的事件。