微服务事件驱动架构中有多少个数据库？

Question

我已经阅读了大量关于CQRS的文档，博客文章和示例，其中EventSource是微服务系统中的有用架构。

一个流行的例子是银行转账应用：

很明显，有四个微服务，但我不明白，因为＆＃34;命令方面＆＃34;微服务没有自己的数据库。

通过这个图像，所有微服务都使用相同的eventStore数据库，这应该是针对微服务模式的吗？

EventStore db应该怎么做？单桌？每个服务一个表 ？

Answer 1

大多数决定都是权衡取舍，这也不例外。在通常的微服务定义中，每个服务都有自己的数据库，原因是@ thiago-custodio提到的。您可以完全分离并封装您的服务。但是，这会给业务的运营方面带来更多负担，因为您现在有N个数据库需要管理。你还有一个新的“如何将所有事情相互交谈”的问题来解决。这对您来说可能是也可能不是问题。

您可以通过共享数据库获得服务分离和封装的一些好处，但是，例如，为每个服务提供单独的模式。您仍然可以在数据库级别获得某种程度的隔离，但会降低操作复杂性。再次，权衡。

我将单个事件存储/消息队列的使用视为可接受的权衡，以便在许多服务之间实现通信。

  

很明显有四个微服务，

不一定只是从上下文中查看图表。有两个控制器将事件写入事件存储，以及一个返回查询的控制器。这看起来像是解释CQRS而不是微服务的图表。 CQRS不是顶级架构 - 您可以将应用于微服务中。

  

但我不明白，因为“命令端”微服务没有自己的数据库。

事件存储是数据库。查询端有一个单独的数据库，将针对查询进行优化。

Answer 2

决定我需要更大的空间来澄清我的评论

  

很明显有四个微服务，

我认为这根本不清楚。

恰好这个特定的图像来自 https://github.com/cer/event-sourcing-examples

在概述中，理查森写道：

One of the neat things about the modular architecture is 
that there are two ways to deploy these four services:

monolithic-service - all services are packaged as a single Spring Boot executable JAR

Microservices - three separate Spring Boot executable JARs
    accounts-command-side-service - command-side accounts
    transactions-command-side-service - command-side money transfers
    accounts-query-side-service - Account View Updater and Account View Reader

在Scala By the Bay的

Presenting，他将一个微服务发布的模式称为事件存储，另一个微服务订阅这些事件并更新视图存储。

所以我认为你可以公平地将这个计算为一，二，三或四个微服务。

您需要考虑的一件事是，帐户视图适配器需要与帐户有一个共同的理解，以及与传输的共同理解，以便了解事件中包含的状态信息以生成视图（帐户视图阅读器不需要这种共享理解，因为它只是从视图存储中复制数据。）

Udi Dahan有一些关于服务边界的有趣内容;特别是，您可以通过限制服务公开共享的数据量来保持服务之间的松散耦合。

我将此指南应用于此图表告诉我，帐户视图和两个聚合必须属于同一边界，因为它们都可以访问此服务专用的数据。

当然，如果您小心保留对事件架构的向后兼容更改，您仍然可以单独设计这四个服务组件。

  

很明显有四个微服务，但我不明白，因为“命令端”微服务没有自己的数据库。

您可以将这两个微服务视为具有恰好是同一物理存储的不同逻辑事件存储。如果您确定需要迁移其中一个逻辑存储区，但是聚合事件流彼此隔离，则会涉及到一些潜在的问题，因此您不必担心帐户和传输之间的耦合。

  

EventStore db应该怎么做？单桌？每项服务一张桌子？

事件存储的典型关系模式将事件本身视为blob，并公开一些元数据（例如eventId），以便它可以与其他表连接。因此，通用存储可能看起来像一个表来保存事件，另一个表来保存事件流。在storing events when using event sourcing中有一些关于关系模式讨论的链接。

如果要将模式分区/分片到多个物理表中，您也可以这样做。

您还可以使用非关系型商店。如果您查看Event Store（这是开源）的详细信息，您可以了解有关如何实现商店的详细信息。

或者您可以将其视为黑盒子。

Answer 3

在我看来，根据我到目前为止所读到的有关微服务架构的内容，每个服务拥有自己的持久性机制的想法是创建一个独立的服务，如果需要可以完全重写，而不会影响消费者。 （只要您保留客户的请求/响应合同）。

这是分散式数据管理。特性，并且使用相同的数据库制作微服务，您将无法实现这一目标。

进一步阅读：

http://martinfowler.com/articles/microservices.html