微服务应按「子业务」垂直拆分，而不是按「读写」拆分——旗帜鲜明反对服务读写分离
《数据库架构与实践》第 22 篇：服务层读写分离为什么离谱。
有朋友问我说：服务要不要做读写分离？
我的态度旗帜鲜明：不要。
别扯什么CQRS。
什么是“服务读写分离”架构？
有两类最常见的。
单纯服务读写分离
如上图，服务化之后：
1. 同一个基础服务，分为读服务与写服务；
2. 底层公用高可用的数据库集群；
服务和数据库同时读写分离
读服务与写服务读写的是不同的数据库，如上图：
1. 写服务访问写库；
2. 读服务访问读库；
3. 写库与读库是一个主从同步的集群；
为什么我旗帜鲜明的反对服务区分读写分离？
上游容易困惑，运维更加复杂
1. 调用方对同一个基础服务，某一个RPC接口，在读服务，还是写服务，容易困惑；
2. 对于同一个基础服务，服务数量翻倍了，运维更加复杂；
微服务不是这么拆分集群的
1. 一般来说，垂直拆分，是按照“子业务”维度进行拆分，而不是按照“读写”维度进行拆分，这是模块化设计的基本准则；
2. 完全打破了“服务化数据库私有”的微服务初衷；
两个服务因为同一份数据库资源访问而耦合在一起，当数据库资源发生变化的时候（例如：ip变化，域名变化，表结构变化，水平切分变化等），有两个依赖点需要修改。
而好的设计，有变化产生时，只有一个需要修改（低耦合，高内聚）。
根本没法很好的添加缓存
大部分互联网业务是读多写少的业务，数据库读取最容易成为瓶颈，常见提升读性能的方式是，增加缓存。
服务读写分离，怎么添加缓存？
如上图，读服务的下游增加一个缓存，当有读请求访问时：
1. 先访问缓存，如果命中，直接返回；
2. 如果缓存不命中，访问数据库，然后将数据放入缓存中，以便下一次能够命中；
初步看，没有问题。但是，写服务修改数据库时，缓存中的数据没有办法得到淘汰！
有朋友说，写数据库之前，可以由写服务来淘汰缓存：
即，读服务与写服务都可以操作缓存。
这个设计，又违背了“服务化缓存私有”的微服务初衷，两个服务因为同一份缓存资源访问而耦合在一起，当缓存资源发生变化的时候，有两个依赖点需要修改。
况且，如果真的两个服务访问相同的数据库和缓存，为什么不合成一个服务呢？
硬要拆成两个服务，不是自己玩自己么？
另外，有朋友说，可以由写服务发消息来淘汰缓存：
如上图：
1. 缓存私有，只有读服务操纵缓存；
2. 数据库发生写请求时，写服务给MQ发消息，由读服务来淘汰缓存；
这种设计：
1. 读服务来淘汰缓存，本质是一个写请求，不是很奇怪么？
2. 引入了一个MQ组件，引入更大的一致性风险
3. 读服务和写服务如果是一个进程，岂不是更好么，干嘛硬要跨进程通信呢？
所以，还是一个服务更好：
1. 调用方无二义性，不纠结；
2. 好维护；
3. 数据库，缓存私有，无耦合；
稍作总结：互联网微服务架构，应该按照“子业务”进行微服务拆分，而不应该按照“读写”来进行微服务拆分。
以上仅为个人架构经验，供大伙参考，欢迎共同探讨。
检验一下
检索练习 · 两类架构
文中「服务读写分离」的两类常见架构是？
检索练习 · 拆分准则
作者反对服务读写分离的核心准则：微服务垂直拆分应按什么维度进行？
检索练习 · 缓存困境
服务读写分离后在读服务下游加缓存，会出什么根本问题？
检索练习 · 最终结论
文中说「还是一个服务更好」，理由是哪三条？
服务层别做读写分离，那数据库层的读写分离怎么落地？看看 MySQL 官方的中间件——第 23 篇《MySQL 官方中间件 mysql-proxy 怎么玩？》。
知其然，知其所以然。思路比结论更重要。