别扯什么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. 数据库，缓存私有，无耦合；

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

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

知其然，知其所以然。

思路比结论更重要。

==全文完==