如何在微服务架构中实现事件溯源和数据库？
How to implement Event sourcing and a database in a microservice architecture?
我最近一直在学习微服务架构及其特性。
在 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 与一个数据库无关。它是我们用于 DB 模型的一种模式，一个用于命令，另一个用于查询。
如果您理解 Java 那么请参考书籍“微服务模式 - Chris Richardson”，如果您来自 C# 或 Microsoft 技术堆栈，那么您可以参考“https://github。com/dotnet-architecture/eShopOnAzure".
Where is the queryable database?
我猜这是最有用的起点，因为它是最熟悉的。可查询数据库与您未进行事件溯源时“这就是整个数据库”所在的位置相同。
这可能是一个专门支持此微服务的数据库，也可能是一个由多个微服务共享的数据库，其中该微服务具有独占写入权限的架构的某些部分。另一种思考方式：微服务使用不同的逻辑数据库，这些数据库可能在物理上部署在一起。
Where is the events database?
相同的总体思路 - 每个微服务可以有一个事件数据库；或者你可以有几个不同的微服务共享同一个数据库。同样，您有权限划分，并且需要考虑相同的逻辑与物理分离。
引入事件和 CQRS 后发生的变化是 query/reporting 数据库不再存储微服务使用的信息的 权威 副本。权威信息存在于事件存储中，query/reporting 数据库更像是一个 缓存 .
我们的命令处理程序通常只会从权威存储（又名事件）加载信息；如果我们同时处理命令，那就是我们锁定的数据。
我们将存储在事件中的信息复制到 query/reporting 数据库中。根据我们的需要，这可以由命令处理程序同步完成，但更常见的是使用后台批处理来完成这项工作，这意味着报告数据库中的数据通常会有点陈旧。
can I store events in a message broker like Kafka?
目前的共识是，正如 CQRS 社区所理解的那样，Kafka 不能可靠地用于事件溯源。
- https://issues.apache.org/jira/browse/KAFKA-2260
- https://cwiki.apache.org/confluence/display/KAFKA/KIP-27+-+Conditional+Publish
粗略地说，问题是这样的：当你有两个进程有写入事件的权限时，你如何保证它们不会引入不一致？对于事件存储，我们可以使用锁或条件写入（也称为比较和交换），以确保没有人出现并偷偷加入一些可能会改变我们正在写入的事件的额外事件。
对于 Kafka，似乎没有支持预防的机制，因此您需要更多地了解 apologies 或其他东西。
the CQRS database actually is one "whole" database that collects all the events?
逻辑上？不，但您确实可以将它们物理组合到同一个设备中。例如，message-db“只是”一个带有一些表、函数等的 postgres 模式。您当然可以将其与用于查询和报告的表格结合起来。
I'm looking for a full example architecture of how things will look in the grand picture.
2010 年的资料 published by Greg Young 可能是一个不错的起点。
我最近一直在学习微服务架构及其特性。 在 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 与一个数据库无关。它是我们用于 DB 模型的一种模式，一个用于命令，另一个用于查询。
如果您理解 Java 那么请参考书籍“微服务模式 - Chris Richardson”，如果您来自 C# 或 Microsoft 技术堆栈，那么您可以参考“https://github。com/dotnet-architecture/eShopOnAzure".
Where is the queryable database?
我猜这是最有用的起点，因为它是最熟悉的。可查询数据库与您未进行事件溯源时“这就是整个数据库”所在的位置相同。
这可能是一个专门支持此微服务的数据库，也可能是一个由多个微服务共享的数据库，其中该微服务具有独占写入权限的架构的某些部分。另一种思考方式：微服务使用不同的逻辑数据库，这些数据库可能在物理上部署在一起。
Where is the events database?
相同的总体思路 - 每个微服务可以有一个事件数据库；或者你可以有几个不同的微服务共享同一个数据库。同样，您有权限划分，并且需要考虑相同的逻辑与物理分离。
引入事件和 CQRS 后发生的变化是 query/reporting 数据库不再存储微服务使用的信息的 权威 副本。权威信息存在于事件存储中，query/reporting 数据库更像是一个 缓存 .
我们的命令处理程序通常只会从权威存储（又名事件）加载信息；如果我们同时处理命令，那就是我们锁定的数据。
我们将存储在事件中的信息复制到 query/reporting 数据库中。根据我们的需要，这可以由命令处理程序同步完成，但更常见的是使用后台批处理来完成这项工作，这意味着报告数据库中的数据通常会有点陈旧。
can I store events in a message broker like Kafka?
目前的共识是，正如 CQRS 社区所理解的那样，Kafka 不能可靠地用于事件溯源。
- https://issues.apache.org/jira/browse/KAFKA-2260
- https://cwiki.apache.org/confluence/display/KAFKA/KIP-27+-+Conditional+Publish
粗略地说，问题是这样的：当你有两个进程有写入事件的权限时，你如何保证它们不会引入不一致？对于事件存储，我们可以使用锁或条件写入（也称为比较和交换），以确保没有人出现并偷偷加入一些可能会改变我们正在写入的事件的额外事件。
对于 Kafka，似乎没有支持预防的机制，因此您需要更多地了解 apologies 或其他东西。
the CQRS database actually is one "whole" database that collects all the events?
逻辑上？不，但您确实可以将它们物理组合到同一个设备中。例如，message-db“只是”一个带有一些表、函数等的 postgres 模式。您当然可以将其与用于查询和报告的表格结合起来。
I'm looking for a full example architecture of how things will look in the grand picture.
2010 年的资料 published by Greg Young 可能是一个不错的起点。