微服务中的事件溯源、CQRS 和数据库

Question

我是微服务架构方面的新手，阅读这​​篇文章：http://microservices.io/patterns/data/event-sourcing.html 以熟悉微服务架构中的事件溯源和数据存储。 我已经阅读了很多关于系统 3 个重要方面的文档：

1. 使用事件溯源而不是简单的共享 DB 和 ORM 和 行更新
2. 事件是 JAVA 对象。
3. 在永久保存数据的情况下 ，我们需要使用 DB（关系型或 noSQL）

这是我的问题：

1. 数据库如何与事件溯源一起出现？我读过 CQRS 模式，但我不明白 CQRS 模式与 事件存储和事件对象？

2. 任何机构都可以为我提供 完整的画面和一组操作发生在所有玩家身上 收集：CQRS 模式，事件溯源（包括事件存储 模块），最后是不同的微服务？

3. 在系统中 由许多微服务组成，我们应该有一个事件存储还是 每个微服务都有自己的？还是两者都可以？
4. 相同 关于CQRS的问题。这种模式在所有实现 微服务还是只有一个？
5. 最后，在使用的情况下 微服务架构，必须只有一个 DB 或 每个微服务都应该有自己的？

如你所见，我已经理解了所有游戏的小片段，但我无法将它们联系在一起组成一个完整的图像。 CQRS 与事件溯源和在数据库中存储数据之间的特别相关性。 例如，我阅读了很多文章：

• https://ookami86.github.io/event-sourcing-in-practice/
• https://msdn.microsoft.com/en-us/library/jj591577.aspx

但在所有这些中都讨论了小玩家。即使是手绘图像也会受到赞赏。

Answer 1

数据库是如何与事件溯源一起出现的？我读过 CQRS 模式，但我不明白 CQRS 模式与事件存储和事件对象的关系？

CQRS 的“查询”部分指导您如何创建事件的投影，这适用于某些“有界上下文”，其中数据库可以用作持久化该投影的一种手段。 “命令”部分允许您隔离数据转换逻辑并将其与应用程序的“查询”和“持久性”方面分离。简单地说 - 您只需以多种方式将事件流投影到数据库中（投影也可以是关系的），具体取决于任务。在这个模型中，“查询”和“命令”有自己的投射和存储事件数据的方式，针对应用程序特定部分的需求进行了优化。相同的数据将存储在事件和投影中，这将允许实现子域（有界上下文、微服务）之间的简单性和松散耦合。

任何机构都可以为我提供一个完整的图片和所有玩家收集的一组操作：CQRS 模式、事件溯源（包括事件存储模块）以及最后不同的微服务吗？

您是否看到 Greg Young 尝试提供 simplest possible implementation？如果您仍然感到困惑，请考虑针对他的示例提出更具体的问题。

在一个由许多微服务组成的系统中，我们应该有一个事件存储还是每个微服务都有自己的？还是两者都可能？

它通常是一种常见的事件存储，但肯定会有一些例外情况，在这种情况下，您确实需要多个存储来存储不同的微服务。这一切都取决于业务案例。如果您不确定 - 很可能您现在只需要一个存储空间。

关于 CQRS 的同样问题。这种模式是在所有微服务中实现还是只在一个微服务中实现？

它可以在大多数性能要求高的微服务中实现。这完全取决于当您将 CQRS 引入其中时，您的实现变得多么复杂。如果它变得更简单 - 为什么不到处实现它呢？但是，如果您的团队中的人们对在命令和查询部分之间执行更明确的同步的需要变得越来越困惑 - 也许 cqrs 对您来说太多了。这完全取决于您的团队，您的领域......不幸的是，没有一个简单的答案。

最后，在使用微服务架构的情况下，是否必须只有一个数据库，或者每个微服务都应该有自己的？

如果相同的微服务共享相同的表 - 这通常被认为是一种反模式，因为它增加了耦合，系统变得更加脆弱。您仍然可以共享同一个数据库，但不应该有共享表。此外，一个微服务中的表最好不要对另一个微服务中的表有 FK。同样的原因 - 减少耦合。

PS：考虑不要问粗粒度的问题，因为这样会更难得到人们的回应。几个更小、更具体的问题将有更好的机会得到回答。