如何在微服务架构中实现事件溯源和数据库？

如何解决如何在微服务架构中实现事件溯源和数据库？

我最近一直在学习微服务架构及其功能。在 this source 中，事件溯源似乎是替换数据库，但是，后来声明：

The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities. That is likely to be complex and inefficient. As a result,the application must use Command Query Responsibility Segregation (CQRS) to implement queries.

在the CQRS Page中，作者似乎描述了一个单一的数据库，它可以监听所有事件并自行重建。

我的问题是：

使用可查询数据库实现事件溯源实际上需要什么？特别是：

事件数据库在哪里？可查询的数据库在哪里？我是否需要为每个服务拥有多个事件存储，或者我可以将事件存储在像 Kafka 这样的消息代理中吗？ CQRS 数据库实际上是一个收集所有事件的“完整”数据库吗？而这一切又是如何扩展的？

如果我的问题不清楚，我很抱歉，我自己也很困惑。我想我正在寻找一个完整的示例架构，说明事物在宏观图景中的样子。

解决方法

可查询的数据库在哪里？

我猜这是最有用的起点，因为它会是最熟悉的。可查询数据库所在的位置与您不进行事件溯源时的整个数据库所在的位置相同。

这可能是一个专门支持该微服务的数据库，也可能是一个由多个微服务共享的数据库，其中该微服务具有独占写入权限的架构的某些部分。另一种思考方式：微服务使用不同的逻辑数据库，这些数据库可能在物理上部署在一起。

事件数据库在哪里？

相同的总体思路 - 每个微服务可以有一个事件数据库；或者您可以有多个不同的微服务共享同一个数据库。同样，您需要划分权限，并且要考虑相同的逻辑与物理分离。

引入事件和 CQRS 后的变化是查询/报告数据库不再存储微服务使用的信息的权威副本。权威信息存在于事件存储中，查询/报告数据库更像是一个缓存。

我们的命令处理程序通常只会从权威存储（也就是事件）加载信息；如果我们同时处理命令，那就是我们锁定的数据。

我们将存储在事件中的信息复制到查询/报告数据库中。根据我们的需要，这可以由命令处理程序同步完成，但更常见的是使用后台批处理来完成这项工作，这意味着报告数据库中的数据通常会有些陈旧。

我可以在像 Kafka 这样的消息代理中存储事件吗？

目前的共识是，按照 CQRS 社区的理解，Kafka 不能可靠地用于事件溯源。

粗略地说，问题是这样的：当您有两个具有写入事件权限的进程时，您如何确保它们不会引入不一致？通过事件存储，我们可以使用锁或条件写入（也称为比较和交换），以确保没有人出现并偷偷加入一些可能会改变我们正在写入的事件的额外事件。

对于 Kafka，似乎没有支持预防的机制，因此您需要更多地关注 apologies 或其他东西。

CQRS 数据库实际上是一个收集所有事件的“整体”数据库？

逻辑上？不可以。但您肯定可以将它们以物理方式组合到同一个设备中。例如，message-db“只是”包含一些表、函数等的 postgres 模式。您当然可以将其与用于查询和报告的表格结合起来。

我正在寻找一个完整的示例架构，说明事物在大局中的样子。

2010 年的材料 published by Greg Young 可能是一个不错的起点。

事件源不会替换数据库。它有一些好处和挑战。所以，我们应该明智地选择它。如果你不舒服，那就不要选择它。您可以在没有事件溯源的情况下实现微服务风格。

可查询数据库 - 简单的解决方案是实现 CQRS 模式并使您的查询数据库与事件源数据库同步。

事件数据库应该与所有者服务一起使用，就像您保留有关订单的事件而不是订单服务中的事件。（是的，其他服务可以有相同的副本）。

您可以将 Kafka 用作事件的中间存储，但不是最后一个。

CQRS 不是一个数据库。这是我们用于 DB 模型的一种模式，一种用于 Command，另一种用于 Query。

如果您了解 Java，请参阅“微服务模式 - Chris Richardson”一书；如果您来自 C# 或 Microsoft 技术堆栈，则可以参阅“https://github.com/dotnet-architecture/eShopOnAzure”。