读服务+写服务分离架构,我坚决反对!

开发 开发工具 架构
大家都知道,数据库可以读写分离,为了职责更清新,架构设计上,服务能否读写分离呢?

[[407635]]

系统分层架构有一个迭代和演进的过程,早期,系统二层架构如下:

(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)数据库,缓存私有,无耦合;

总的来说,个人的意见是:

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

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

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

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

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2021-07-01 10:13:51

缓存数据存储服务化架构

2017-12-26 16:18:00

架构服务化读写分离

2018-01-01 05:23:13

服务化读写分离架构

2021-12-10 06:07:56

电脑360病毒

2014-05-19 15:59:35

2023-07-28 09:23:24

微服务架构

2021-03-19 09:37:30

运营商外交部中国联通

2020-09-04 15:20:10

印度APPTikTok

2023-08-02 08:51:46

服务架构分层架构

2012-08-22 09:32:54

面试面试题

2018-08-01 14:20:11

微服务架构人工智能

2024-01-19 11:57:42

2023-07-12 08:30:52

服务架构事件驱动架构

2023-07-26 08:51:08

大数据服务架构

2019-09-17 11:18:09

SQLMySQLJava

2020-10-19 09:51:18

MYSQL知识数据库

2021-06-22 05:34:21

比特币区块链加密货币

2018-01-15 05:54:45

数据库读写分离互联网

2018-01-09 18:46:44

数据库架构读写分离

2012-10-18 10:11:48

IBMdw
点赞
收藏

51CTO技术栈公众号