简述 3 种 CQRS 架构模式 - 今日头条

本文由简悦 SimpRead 转码，原文地址 www.toutiao.com

1988 年，Bertrand Meyer 在面向对象的软件设计一书中设计了 CQS 原则。简单来说，这个原则是说程序应当要么修改系统，要么返回

关注点分离是一种有效整理架构思想的技巧，你应当把注意力集中在一个方面。

Edsger W. Dijkstra

命令 / 查询分离 (CQS)

1988 年，Bertrand Meyer 在面向对象的软件设计一书中设计了 CQS 原则。简单来说，这个原则是说程序应当要么修改系统（Command），要么返回查询结果 (Query)，软件中应当保持命令与查询的分离。

尽管 Martin Fowler 在他 2005 年的博客文章中也提到，这种分离并非总是可能的，一个很好的例子是返回一个刚插入的记录的 id。首先，你要把记录持久化（Command），其次，你要获得它新分配的 id（Query）。

CQRS 架构

CQRS 建议将应用程序层分为两个方面，即命令端（Command）和查询端（Query）。

查询端负责优化读取数据。从持久化获取数据，然后将它们映射到展现层表单，这些表单通常被标识为数据传输对象（DTO）。

命令端关注优化写入数据。命令执行各种用例，修改实体状态并将其持久化。

通过分离读写操作，我们提高了性能，并在系统中支持关注点分离原则。

本文介绍 3 种主要的 CQRS 架构实现。

单数据库 CQRS

单一数据库 CQRS 模式没有正式名称，Mattew Renze 在他的课程 Clean Architecture 中将其命名为单一数据库 CQRS，我也选择这个命名。

单数据库 CQRS

顾名思义，双方都在和一个数据库对话。Command 在域中执行用例，从而修改实体的状态，然后通过 ORM 如 Entity Framework Core 或 Hibernate 将实体保存到数据库中。

Query 直接通过数据访问层执行，数据访问层要么是使用各种 ORM，要么通过存储过程。

双数据库 CQRS

在 “双数据库” 方式中，我们需要两个数据库，一个用于写操作，一个用于读操作。命令端使用针对写操作优化的数据库。查询端使用针对读取操作优化的数据库。

双数据库 CQRS

命令每改变一个状态，修改后的数据就必须从写数据库推送到读数据库中，或者作为一个跨两个数据库的分布式事务，或者使用最终一致性模型。

这种架构给软件的查询端带来了数量级的性能提升，这是有利的，因为一般系统在读数据上花费的时间一般比写数据要更多。

事件源 (Event source) CQRS

最后一种是最复杂的 CQRS 架构。与前面两种方式相比，事件源存储数据的思路完全不同。

在事件源方法中，我们并不只存储实体的当前状态，而且将实体发生的每一个状态作为快照来存储。实体并不是以标准化数据的形式保存，而是通过事件的时间戳来保存它们的变更。

事件源 CQRS

事件源带有以下好处：

但在另一方面，这种方式实现很复杂，如果你不能从其中受益，那么用这个模式可能适得其反。

小结

CQRS 真正的威力在于可以对写和读操作进行不同的优化。 但在另一方面，系统会变得更加复杂，命令端和查询端代码不完全一致。并且由于存在多个数据库，管理更复杂，需要更繁琐的 ORM 映射。

文中链接：

英文原文：

本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式