CQRS 如何为更具可扩展性的应用程序做出贡献答案

【问题标题】：How can CQRS contribute to more scalable applicationsCQRS 如何为更具可扩展性的应用程序做出贡献
【发布时间】：2014-06-10 07:46:22
【问题描述】：

最近我阅读了很多关于 CQRS 架构的文章。关于为什么应该使用 CQRS 的最重要的一点是可扩展性。

现在我不太明白这是如何工作的。

假设您有您的typical CQRS 应用程序设计。

两个数据存储
一个用于指挥端
一个用于查询端
处理完命令后，将发送一个事件，该事件可以更新第二个数据存储区

人们经常说，拥有一个用于查询的数据存储和一个用于处理命令的数据存储将使您的应用程序更具可扩展性。但是，如果存储事件数据的第二个数据存储需要响应查询请求并且还需要不断地根据传入的事件更新自身，这将如何工作？

为什么没有一个数据存储来存储命令并且查询端可以在其中重新使用存储的数据来获取结果数据？

【问题讨论】：

标签： domain-driven-design cqrs

【解决方案1】：

阅读Greg Young 本人的old blog post 可能会很有趣，他解释了 CQRS 到底是什么。

CQRS 并不是要拥有 2 个不同的商店，而是正如 Greg 的文章所述：

CQRS 只是在之前创建两个对象只有一个。分离的发生基于方法是否是命令或查询

您在这里描述的更多的是事件溯源。

现在回到你的问题：How can CQRS contribute to more scalable applications? Greg 也回答了这个问题：

CQRS 允许以不同方式托管两种服务，例如：我们可以托管 25 台服务器上的读取服务和两台服务器上的写入服务。这命令和查询的处理基本上是不对称的，并且对称地扩展服务没有多大意义。

就是这样！

【讨论】：

【解决方案2】：

Two Datastores
One for the Command Side
One for Query Side
When a Command has been processed an Event is send which could update the second Datastore

这是 CQRS 和 ES（事件溯源），不要混淆！

事件溯源是关于存储通过处理传入命令引发的域事件。因此，您可以随时播放它们。这使得读取端更加灵活，因为您可以随时更改读取的数据库结构，之后您只需重放域事件，而不是编写一些花哨的迁移代码。存储命令是不行的，因为你不一定有相同的环境（例如服务器上的不同时间），所以你不能安全地重播它们。命令存储仅用于记录目的...

命令和查询职责分离是将传入的请求分为两组：写入（命令）和读取（查询）。这背后的基本思想是，您不必通过读取关系数据库来使用相同的 ORM 实体，就像通过编写它来使用它一样。因此，您可以通过读取节省对象关系映射，从而使事情变得更快。后来经过改进，现在这意味着您可以通过读取部分使用多个数据库，每个数据库特定于一组查询。例如，如果像 neo4j 这样的图形数据库更适合某些查询，那么您添加一个 neo4j 数据库，而不是使用相同的关系数据库来服务这些查询。这可以使事情变得更快......

【讨论】：

如果像 neo4j 这样的图形数据库更适合某些查询，那么您可以添加 neo4j 数据库，而不是使用相同的关系数据库来处理这些查询。这可以让事情变得更快...... 真的！ 正如 Greg Young 所说的“错误的模型会导致巨大的意外复杂性”
ES 不是关于存储事件的。这是关于通过应用事件来改变对象状态。没有 ES，CQRS 也能很好地工作。
@MikeSW “ES 不是关于存储事件。它是关于通过应用事件来改变对象状态。” - 实际上你错了，我的意思是事件溯源是一种存储机制，它的工作方式就像你和我都用不同的词描述的那样。 “而且 CQRS 在没有 ES 的情况下也能很好地工作。” - 没有人说别的。
"实现 EventSourcedAggregateRoot 接口的聚合根可以存储在事件源存储库中。这些存储库不存储聚合本身，而是存储聚合生成的一系列事件。基于这些事件，聚合的状态可以随时恢复。” - 来自Manual of the Axon Framework
"Axon 框架提供了一些存储库实现，可以使用事件溯源作为聚合的存储方法。这些存储库要求聚合实现 EventSourcedAggregateRoot 接口。与 Axon 中的大多数接口一样，我们也提供了一个或多个抽象的实现来帮助你。”