本文咱们聊聊 CQRS 这种架构模式。
CQRS 是用来解决什么问题的？
咱们先看一个场景。
零碎中的数据模型是依照实体以及关系进行设计的是吧。
例如电商零碎，蕴含订单、用户、商品等等数据。
数据的变更操作、查问操作，都是基于这一套数据模型的。
然而，理论场景下的查问需要是多种多样。
例如这 3 类人群：
- 商家
- 买家用户
- 电商经营人员
他们的数据视角是不同的，各自的关注角度不同，须要查问的数据就齐全不同。
但数据模型是一套啊，怎么办？
是不是就须要做数据关联、构建长期数据汇合等等简单的操作啊。
基于一种数据模型，来实现 N 种视角的查问，既顺当又麻烦。
CQRS 是怎么解决的呢？
CQRS 的全称是：
Command Query Responsibility Segregation
意思是 命令查问职责隔离。
命令 是指 插入、批改、删除，就是更改数据的动作。
隔离之后，构造就变成了这样：
所以，CQRS 会有两个数据模型，一个命令模型，一个查问模型（能够有多个）。
命令模型的数据变更后，须要同步给查问模型。
这样做的外围目标就是：
让数据查问能够放飞自我。
各种简单的查问操作再也不必基于繁多死板的存储构造了。
命令模型数据同步过去之后，查问模型能够依据本人的想法来从新组织数据结构，从而实现想怎么查就怎么查，简略高效。
这样就解决了以前繁多数据模型带来的查问难堪局面。
这看起来不就是变成 2 个微服务吗？
并不是的，微服务的划分是基于业务畛域的，不同的畛域才划分为不同的微服务。
但 CQRS 中的命令模型、查问模型，它们还是属于同一畛域的，查问模型不能脱离命令模型，它们是紧耦合的。
所以 CQRS 并不是两个独立的微服务。
那么 CQRS 如何同步数据呢？
这是没有限定的，你能够应用同步更新。
也能够异步更新，例如应用 MQ。
这种形式用的比拟多，因为它的可靠性、扩展性都很好，只是会有短暂的数据不统一。
CQRS 看起来很像缓存啊？
是有些相似，但查问模型并不是单纯的用来晋升查问性能的数据镜像。
查问模型的实质是用于创立多样化的数据展示模式。每一种模式实用于某类用户的需要。
CQRS 的查问模型能够应用不同的技术实现，例如有些应用关系数据库，有些应用 Redis ……
CQRS 把数据变更、查问拆散之后，为查问带来了最大化的自在，同时呢，也大幅晋升了这两方面的工作效率，相较于之前整合在一起，离开后负载压力必定会加重。这也是 CQRS 带来的性能劣势。
CQRS 有什么有余？
凡事都有两面性，很显著，CQRS 带来了 复杂性。
之前一体的时候，只有一个数据模型，一套技术。
应用 CQRS 之后，至多就要有 2 个模型，应用的技术也会减少。
还要保持数据的同步，开发保护的工作天然更重了。
还有 数据一致性 的问题，如果应用同步形式，一致性强，但跨数据源的实时同步可不容易，写入性能必然降落，失败的概率也会减少。
如果应用异步形式，那就要思考数据提早问题，在须要立刻看到变动后果的场景就不能应用了。
小结一下，CQRS 把数据的变更和查问拆开了，有各自的数据模型。
命令模型负责数据的变更，并把最新数据同步给命令模型。
命令模型依据本人的想法来安顿数据，想怎么用就怎么用。
益处是能够让查问更加自在，更快的满足多变的业务需要。
害处是减少了架构的复杂度，还有数据同步带来的问题。
咱们能够依据本人的理论状况来抉择。
举荐浏览
OAuth2 图解
轻松了解 Kubernetes 的外围概念
开发者必须要理解的架构技术趋势：Service Mesh