如何更好地在一个网站上阅读: CQRS还是不CQRS？

Question

我为之工作的公司正在重写一个遗留的web应用程序，我们正在评估更好的体系结构，以完成任务。

业务领域非常简单:实体很少，关系很少，业务规则也很简单。

我们期望并发写入的数量较少，但需要大量的读取:预期的读工作负载要比预期的写工作负载大得多。

web应用程序的目的是允许少数编辑创建名为blog的实体，这些实体由posts组成。有不同类型的帖子:文字帖子、照片、youtube视频链接、twitter帖子链接等等。

预期的工作流程是，一个编辑，它跟踪一个体育活动事件，负责编辑一个专门的博客，这基本上是一个事件的帖子流:编辑为事件的每一个有趣的事实创建一个帖子。主要关注的是，每个帖子都能尽快提供给移动和网络客户端，以便世界各地的人们都能关注这一事件。

我们评估了两种可能的架构：

• 具有两个不同数据库的CQRS体系结构，一个用于命令堆栈，另一个用于查询堆栈
• 一个支持写和读的域模型和一个数据库的简单体系结构

CQRS方法的主要优点是可以通过使用一些专用的读取模型，以优化的方式将内容分发给客户端，以便从读取模型数据库中进行简单和快速的读取。通过这种方式，读写侧可以独立缩放，利用上面突出显示的写和读工作负载之间的差异。

单域模型方法的主要优点是结构简单得多。在这个场景中，来自编辑器的命令是同步处理的，当成功地处理命令时，编辑器知道它的工作保存在数据库中，并可供客户端使用。在写入模型和读取模型之间没有最终的一致性，不需要从后台UI用户(编辑器)的角度来处理读取模型的异步更新，也不需要涉及任务关键任务的任何类型的消息传递系统。

在我看来，考虑到我们的需求，最好的方法是使用单一域模型体系结构，并通过使用积极的缓存策略来扩展读取。我们的想法是使用Redis作为缓存，以限制数据库访问，并在每次我们使用流方式在数据库中编写内容时尝试更新缓存层(我们可能会使用Mongo，我们的第一个想法是利用变更流特征)。

您认为适当大小的数据库和使用redis的明智的缓存策略可以满足我们的读取需求吗？或者相反，在读取负载比写负载大得多的情况下，最好的方法是使用CQRS体系结构(即使代价是更大的总体复杂性)？

一些注释，以更好地澄清我的问题

• 我提到了Redis，作为智能分布式内存的一个例子，cache.The的总体思想是采用某种高效的缓存机制，以最小化对数据库的访问。
• 我知道在采用CQRS架构时也可以使用缓存机制(它们解决了不同的问题)。我强调了在单个数据库体系结构中使用缓存的情况，因为我认为在这种情况下，为了处理用于写入和读取的单个数据库的锁定和并发性，必须使用缓存。
• 在这个问题中，我打算将CQRS作为一个整体有界上下文的体系结构方法(如解释的这里)，而不是像Bertrand (请看这里)最初提出的那样作为一个设计原则。
• 我们认为CQRS是一种可能的体系结构，因为它是一个很好的选择，当您想要独立地缩放写和读边，并且您想让非规范化的数据准备用一个查询来读取(这样读取是快速和高效的)。同时，我们已经经历了CQRS所带来的复杂性，我们不确定在这个领域是否值得付出努力。
• 我问题的目标是从更有经验的人那里获得一些技巧和反馈(基于现实世界的项目)，这些人与能够在阅读方面进行有效扩展的问题有关。

Answer 1

在显示和编辑博客条目的情况下，将编辑和阅读职责分开的概念是非常有意义的：

• 单独的微服务使每个微服务都能适当地扩展。
• 它们之间唯一需要理解的是如何持久化数据。

在那里，您可以决定在它们之间需要哪些基础设施部件。从成本/性能的角度来看，您不会比云blob存储更好。当然，blob存储无助于搜索和查询，但是它可以非常快地提供资源，而且您不需要做任何特殊的事情来扩展它。

如果您将所有呈现卸载到客户端(即单个Page )，则只需来回传递数据。这使得您的搜索/查询功能可能更好地由ElasticSearch或Apache提供。异步任务可以处理更新搜索引擎，进一步解耦的事情。

尽管如此，随着互联网规模的建立，你想要最小化争论的焦点，如果可能的话，什么也不分享。如果您觉得自己仍然需要Redis缓存，那么您可以更好地理解它需要包含在哪里。

类似的底线：

• 首先考虑一下体系结构以及如何解决您的问题。
• 如果可以的话，不要分享。
• 没有简单的答案。我不知道你在做什么，为什么你选择了技术栈，在我的回答中你必须更有意义。

我认为CQRS和Redis正在解决两个不同的问题，并不一定是相互排斥的概念。限制可伸缩性的主要问题是当您必须共享东西时，所以尽量减少围绕共享修复的争用。我不会告诉你，CQRS对于你的应用是正确还是错误的，只是你在比较苹果和卡车。它们是非常不同的东西。

命令查询责任隔离(CQRS)有它的用途，并且在重点突出的应用程序中工作良好。但是，这是代码的设计模式。

你的另一个建议是一个建筑决定。虽然体系结构对可用的或相关的设计模式有很大的影响，但决策与设计是正交的。

底线

• 了解您的设计参数(您需要支持互联网规模吗？)
• 了解你的瓶颈(是什么阻碍你实现你的目标？)
• 了解决策的成本(运行成本是多少，转换成本是多少？)

您的团队需要在需要解决的问题上达成一致，并且当您正在考虑替代方案时，要做出相同类型的替代方案。例如，我们应该使用Redis、ElasticSearch还是只使用简单的云blob存储？这些都是等效的架构决策的例子，它们本身并不是相互排斥的。