别扯什么CQRS，服务做什么读写分离，就离谱！

admin管理员组

文章数量:1437376

别扯什么CQRS，服务做什么读写分离，就离谱！

《架构师之路：架构设计中的100个知识点》

58.服务要不要读写分离

有朋友问我说：服务要不要做读写分离？

我的态度旗帜鲜明：不要。

画外音：别扯什么CQRS。

什么是“服务读写分离”架构？

有两类最常见的。

第一类、单纯服务读写分离

图片

如上图，服务化之后：

1. 同一个基础服务，分为读服务与写服务；

2. 底层公用高可用的数据库集群；

第二类、服务和数据库同时读写分离

图片

读服务与写服务读写的是不同的数据库，如上图：

1. 写服务访问写库；

2. 读服务访问读库；

3. 写库与读库是一个主从同步的集群；

为什么我旗帜鲜明的反对服务区分读写分离？

原因1：上游容易困惑，运维更加复杂。

1. 调用方对同一个基础服务，某一个RPC接口，在读服务，还是写服务，容易困惑；

2. 对于同一个基础服务，服务数量翻倍了，运维更加复杂；

原因2：微服务不是这么拆分集群的。

1. 一般来说，垂直拆分，是按照“子业务”维度进行拆分，而不是按照“读写”维度进行拆分，这是模块化设计的基本准则；

2. 完全打破了“服务化数据库私有”的微服务初衷；

两个服务因为同一份数据库资源访问而耦合在一起，当数据库资源发生变化的时候（例如：ip变化，域名变化，表结构变化，水平切分变化等），有两个依赖点需要修改。

图片

而好的设计，有变化产生时，只有一个需要修改（低耦合，高内聚）。

原因3：根本没法很好的添加缓存。

大部分互联网业务是读多写少的业务，数据库读取最容易成为瓶颈，常见提升读性能的方式是，增加缓存。

图片

服务读写分离，怎么添加缓存？

如上图，读服务的下游增加一个缓存，当有读请求访问时：

1. 先访问缓存，如果命中，直接返回；

2. 如果缓存不命中，访问数据库，然后将数据放入缓存中，以便下一次能够命中；

初步看，没有问题。但是，写服务修改数据库时，缓存中的数据没有办法得到淘汰！

有朋友说，写数据库之前，可以由写服务来淘汰缓存：

图片

即，读服务与写服务都可以操作缓存。

这个设计，又违背了“服务化缓存私有”的微服务初衷，两个服务因为同一份缓存资源访问而耦合在一起，当缓存资源发生变化的时候，有两个依赖点需要修改。

况且，如果真的两个服务访问相同的数据库和缓存，为什么不合成一个服务呢？

图片

硬要拆成两个服务，不是自己玩自己么？

另外，有朋友说，可以由写服务发消息来淘汰缓存：

图片

如上图：

1. 缓存私有，只有读服务操纵缓存；

2. 数据库发生写请求时，写服务给MQ发消息，由读服务来淘汰缓存；

这种设计：

1. 读服务来淘汰缓存，本质是一个写请求，不是很奇怪么？

2. 引入了一个MQ组件，引入更大的一致性风险

3. 读服务和写服务如果是一个进程，岂不是更好么，干嘛硬要跨进程通信呢？

所以，还是一个服务更好：

图片

1. 调用方无二义性，不纠结；

2. 好维护；

3. 数据库，缓存私有，无耦合；

稍作总结：互联网微服务架构，应该按照“子业务”进行微服务拆分，而不应该按照“读写”来进行微服务拆分。

以上仅为个人架构经验，供大伙参考，欢迎共同探讨。

知其然，知其所以然。

思路比结论更重要。

==全文完==

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-26，如有侵权请联系 cloudcommunity@tencent 删除数据库缓存微服务cqrs服务

本文标签： 别扯什么CQRS，服务做什么读写分离，就离谱！