服务读写不分离架构

1. 单纯服务读写分离

如上图，服务化之后：

业务方通过RPC分别调用读服务和写服务

服务层分为读服务与写服务

底层是高可用的数据库集群

2. 服务和数据库同时读写分离

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

写服务访问写库

读服务访问读库

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

3. 反对服务区分读写分离

[b]1. 小理由:[/b]

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

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

[b]2. 强理由:[/b]

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

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

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



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