我已经阅读了大量关于将 EventSource 用作微服务系统中有用架构的 CQRS 的文档、博客文章和示例。
一个流行的例子是银行转账应用程序：
很明显有四个微服务，但我不明白，因为“命令端”微服务没有自己的数据库。
通过这张图片，所有微服务都使用相同的 eventStore 数据库，这应该违反微服务模式吗？
EventStore 数据库应该如何？单表？每个服务一张桌子？
问问题
2000 次
3 回答
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 上发表演讲时，他提出了将一个微服务发布到事件存储中，而第二个微服务订阅这些事件并更新视图存储的模式。
因此，我认为您可以提出合理的论据，将其视为一个、两个、三个或四个微服务。
计算时要考虑的一件事是，Account View Adapter 需要与 Accounts 有共同的理解，并且与 Transfers 有共同的理解，以便理解事件中包含的状态信息以生成视图（Account View读者不需要这种共享理解，因为它只是从视图存储中复制数据）。
Udi Dahan关于服务边界有一些有趣的说法；特别是，您通过限制服务公开共享的数据量来保持服务之间的松散耦合。
我将他的指导应用于此图告诉我，帐户视图和两个聚合必须是同一边界的一部分，因为它们都可以访问此服务的私有数据。
当然，如果您小心保留对事件模式的向后兼容更改，您仍然可以单独设计这四个服务组件。
很明显有四个微服务，但我不明白，因为“命令端”微服务没有自己的数据库。
您可以将这两个微服务视为具有恰好是同一个物理存储的不同逻辑事件存储。如果您决定需要迁移其中一个逻辑存储，但聚合事件流彼此隔离，则可能会涉及一些令人头疼的问题，因此您无需过多担心账户和转账之间的耦合。
EventStore 数据库应该如何？单表？每个服务一张桌子？
事件存储的典型关系模式会将事件本身视为 blob，并公开一些元数据（例如 eventId），以便它可以与其他表连接。因此，通用存储可能看起来像一个保存事件的表，另一个保存事件流的表。有一些链接可以讨论在使用事件溯源时存储事件的关系模式。
如果您想将架构分区/分片到多个物理表中，您也可以这样做。
您还可以使用非关系存储。如果您查看Event Store（它是开源的）的详细信息，您可以了解很多有关如何实现商店的信息。
或者你可以把它当作一个黑匣子。
于 2016-08-02T19:06:38.220 回答
2
大多数决策都是关于权衡的，这也不例外。在微服务的通常定义中，由于@thiago-custodio 提到的原因，每个服务都有自己的数据库。您可以完全分离和封装您的服务。但是，这会给业务的运营方面带来更多负担，因为您现在有 N 个数据库要管理。您还需要解决一个新的“所有事物如何相互通信”的问题。这对您来说可能是也可能不是问题。
您可以从共享数据库中获得服务分离和封装的一些好处，例如，为每个服务提供单独的模式。您仍然可以在数据库级别获得某种程度的隔离，但会降低您的操作复杂性。再次，权衡。
我认为使用单个事件存储/消息队列是一种可接受的折衷方案，可以作为实现大量服务之间通信的一种方式。
很明显有四个微服务，
不一定只是从上下文中查看图表。有两个控制器将事件写入事件存储，一个控制器返回查询。这看起来像是解释 CQRS 而不是微服务的图表。CQRS 不是顶级架构——您可以在微服务中应用它。
但我不明白，因为“命令端”微服务没有自己的数据库。
事件存储是数据库。查询端有一个单独的数据库，将针对查询进行优化。
于 2016-08-02T05:42:26.673 回答
0
在我看来，根据我目前所读到的关于微服务架构的内容，每个服务都有自己的持久性机制的想法是创建一个独立的服务，如果需要，可以完全重写，而不会影响消费者。（只要您保留客户的请求/响应合同）。
这就是去中心化数据管理。 特性，并使用相同的数据库制作微服务，您将无法实现。
进一步阅读：
于 2016-08-02T05:06:55.630 回答