读服务+写服务分离架构，我坚决反对！

系统分层架构有一个迭代和演进的读服过程，早期，服务分离反对系统二层架构如下：

(1)上游是架构坚决业务应用;

(2)下游是数据库;

随着架构的演进，可能要抽取出微服务，读服系统三层架构如下：

(1)上游仍是服务分离反对业务应用;

(2)中间是微服务层，提供RPC接口;

(3)下游是架构坚决数据库;

大家都知道，数据库可以读写分离，读服为了职责更清新，服务分离反对架构设计上，架构坚决服务能否读写分离呢?读服

如上图，服务化读写分离之后：

(1)业务方通过RPC分别调用读服务和写服务;

(2)服务层分为读服务与写服务;

(3)底层是服务分离反对高可用的数据库集群;

当然，也有可能读服务与写服务读写的架构坚决是不同的数据库，如上图：

(1)写服务访问写库;

(2)读服务访问读库;

写库与读库是读服一个主从同步的集群。

那么，服务分离反对问题来了：

(1)你遇到过这种读服务+写服务分离的架构坚决架构设计么?

(2)这种架构设计好还是不好，为什么?

楼主支持这种读写服务分离的架构设计么?

先说结论，我旗帜鲜明的服务器租用反对服务区分读写分离。

为什么反对呢?

大大小小的理由，有这么五点。

第一点：对于调用方而言，调用同一个基础服务，要访问其RPC接口，究竟调用读服务，还是写服务，容易困惑。

第二点：对于同一个基础服务，服务数量翻倍了，运维更加复杂。

画外音：总的来说，上面两点还可以忍。

第三点：一般来说，服务拆分，是按照“子业务”维度进行拆分，而不是按照“读写”维度进行拆分，这是模块化设计的基本准则。

画外音：这一点，是原则性问题。

第四点：完全打破了“服务化数据库私有”的微服务初衷。

画外音：数据访问，应该收口。服务器托管

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

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

第五点：没法很好的添加缓存。

画外音：这一点很致命。

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

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

(1)先访问缓存，如果命中，直接返回;

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

额，然后，香港云服务器这个架构中，这个方案是不可行的。因为，写服务修改数据库时，缓存中的数据没有办法得到淘汰!!!

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

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

画外音：缓存访问，应该收口。

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

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

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

如上图：

(1)缓存私有，只有读服务操纵缓存;

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

这种设计：

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

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

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

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

(1)调用方不蒙圈，不纠结;

(2)好维护;

(3)数据库，缓存私有，无耦合;

总的来说，个人的意见是：

互联网微服务架构，建议按照“子业务”进行微服务拆分，而不应该按照“读写”来进行微服务拆分，避免过度设计。

以上仅为个人架构经验，希望逻辑是清晰的，供大伙参考，欢迎共同探讨。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

很赞哦!（7）