架构模式 CQRS

本文我们聊聊 CQRS 这种架构模式。

CQRS 是用来解决什么问题的？

我们先看一个场景。

系统中的数据模型是按照实体以及关系进行设计的是吧。

image

例如电商系统，包含订单、用户、商品等等数据。

数据的变更操作、查询操作，都是基于这一套数据模型的。

但是，实际场景下的查询需求是多种多样。

例如这3类人群：

• 商家

• 买家用户

• 电商运营人员

他们的数据视角是不同的，各自的关注角度不同，需要查询的数据就完全不同。

但数据模型是一套啊，怎么办？

是不是就需要做数据关联、构建临时数据集合等等复杂的操作啊。

基于一种数据模型，来实现 N 种视角的查询，既别扭又麻烦。

CQRS 是怎么解决的呢？

CQRS 的全称是：

Command Query Responsibility Segregation

意思是 命令查询职责隔离。

命令是指 插入、修改、删除，就是更改数据的动作。

隔离之后，结构就变成了这样：

image

所以，CQRS 会有两个数据模型，一个命令模型，一个查询模型（可以有多个）。

命令模型的数据变更后，需要同步给查询模型。

这样做的核心目的就是：

让数据查询可以放飞自我。

各种复杂的查询操作再也不用基于单一死板的存储结构了。

命令模型数据同步过来之后，查询模型可以根据自己的想法来重新组织数据结构，从而实现想怎么查就怎么查，简单高效。

这样就解决了以前单一数据模型带来的查询尴尬场面。

这看起来不就是变成2个微服务吗？

并不是的，微服务的划分是基于业务领域的，不同的领域才划分为不同的微服务。

但 CQRS 中的命令模型、查询模型，它们还是属于同一领域的，查询模型不能脱离命令模型，它们是紧耦合的。

所以 CQRS 并不是两个独立的微服务。

那么 CQRS 如何同步数据呢？

这是没有限定的，你可以使用同步更新。

image

也可以异步更新，例如使用 MQ。

image

这种方式用的比较多，因为它的可靠性、扩展性都很好，只是会有短暂的数据不一致。

CQRS 看起来很像缓存啊？

是有些类似，但查询模型并不是单纯的用来提升查询性能的数据镜像。

查询模型的本质是用于创建多样化的数据展现形式。每一种形式适用于某类用户的需求。

CQRS 的查询模型可以使用不同的技术实现，例如有些使用关系数据库，有些使用 Redis ……

CQRS 把数据变更、查询分离之后，为查询带来了最大化的自由，同时呢，也大幅提升了这两方面的工作效率，相较于之前整合在一起，分开后负载压力肯定会减轻。这也是 CQRS 带来的性能优势。

CQRS 有什么不足？

凡事都有两面性，很明显，CQRS带来了复杂性。

之前一体的时候，只有一个数据模型，一套技术。

使用 CQRS 之后，至少就要有 2 个模型，使用的技术也会增加。

还要保持数据的同步，开发维护的任务自然更重了。

还有数据一致性的问题，如果使用同步方式，一致性强，但跨数据源的实时同步可不容易，写入性能必然下降，失败的概率也会增加。

如果使用异步方式，那就要考虑数据延迟问题，在需要立即看到变化结果的场景就不能使用了。

小结一下，CQRS 把数据的变更和查询拆开了，有各自的数据模型。

命令模型负责数据的变更，并把最新数据同步给命令模型。

命令模型根据自己的想法来安排数据，想怎么用就怎么用。

好处是可以让查询更加自由，更快的满足多变的业务需求。

坏处是增加了架构的复杂度，还有数据同步带来的问题。

我们可以根据自己的实际情况来抉择。

推荐阅读

OAuth2 图解

轻松理解 Kubernetes 的核心概念

开发者必须要了解的架构技术趋势：Service Mesh