出处在《服务读写分离(读服务，写服务)，是否可行?》中解释。在互联网架构设计上，数据库是可以读写分离的。服务能不能读写分离？以下是两种常见的“服务读写分离”架构：1.简单的服务读写分离如上图所示。售后服务：业务方通过RPC分别调用读服务和写服务。服务层分为读服务和写服务。底层是高可用的数据库集群。,服务和数据库同时读写和分离读写服务读写不同的数据库，如上图所示：写服务访问写数据库读服务访问读数据库写数据库和读取数据库是一个同步集群。这样的建筑设计好不好，网友们纷纷议论纷纷。有兴趣的同学可以看看《服务读写分离(读服务，写服务)，是否可行?》的评论。在此，我分享一下个人的看法。3、先说结论。楼主明确反对服务中的读写分离。4、小原因调用者很容易混淆同一个基础服务，某个RPC接口，到底是读服务还是写服务。同样的基础服务，服务数量增加了一倍，运维更加复杂。5、强理由一般来说，Vertical拆分是按照“子服务”的维度拆分，而不是“读写”的维度拆分，这是模块化设计的基本原则。1、完全打破了微服务“为私有数据库服务”的初衷。由于相同的数据库资源访问，两个服务耦合在一起。当数据库资源发生变化时（例如：ip变化、域名变化、表结构变化、层级切分变化等），有两个依赖点需要修改。但是一个好的设计，当有变化的时候，只需要修改一个（低耦合，高内聚）。这一点在前段时间的“耦合”系列文章中多次提到：《小小的IP，大大的耦合》《小小的公共库，大大的耦合》《服务化了，耦合却更加严重了》2。做不好加缓存大多数互联网服务都是读多写少的业务。数据库读取最有可能成为瓶颈。提高读取性能的常用方法是增加缓存。如上图所示，在读服务的下游添加了一个缓存。当有读请求访问时：先访问缓存，如果是***，如果缓存不是***直接返回，访问数据库，下次再把数据放入缓存即可最大化量，那么，在这个架构下，这个方案是不可行的。因为，当写服务修改数据库时，缓存中的数据是无法清除的！！！OK，有朋友说在写数据库之前，可以通过写服务来消除缓存：即读服务和写服务都可以操作缓存。嗯，这样的设计违背了“面向服务的缓存私有”的微服务初衷。由于访问相同的缓存资源，两个服务耦合在一起。当缓存资源发生变化时，有两个依赖点需要修改。此外，如果两个服务访问同一个数据库和缓存，为什么不将它们合并为一个服务呢？如果硬要拆分成两个服务，你自己玩不玩吗？OK，另外一个朋友说写服务可以发送消息来消除缓存：如上图：缓存是私有的，只有当读服务操作缓存数据库，有写请求发生时，写服务才会向MQ发送消息，读取服务消除了缓存。这种设计：读服务去掉了缓存，本质上是一个写请求。是不是很奇怪？引入了MQ组件，带来了更大的一致性风险。如果读服务和写服务是一个进程不是更好吗，为什么非要跨进程通信呢？因此，一个服务更好：调用者没有歧义，不费力维护数据库，私有缓存，无耦合。服务拆分以避免过度设计。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
