首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥 热搜 🔥
1
百度
2
今日热点
3
微信公众平台
4
贴吧
5
opgg
6
dnf私服
7
百度贴吧
8
知乎
9
dnf公益服
10
百度傻逼
分类
社会
娱乐
国际
人权
科技
经济
其它
首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥
热搜
🔥
1
百度
2
今日热点
3
微信公众平台
4
贴吧
5
opgg
6
dnf私服
7
百度贴吧
8
知乎
9
dnf公益服
10
百度傻逼
分类
社会
娱乐
国际
人权
科技
经济
其它
白石洲拆迁后,那些上学奔波的孩子都去哪儿了?
一个医保局长之死
给宠物做保姆的中国留学生
本以为吴京大儿子叫“吴所谓”够随意了,听到二儿子名字,真服了
法院4.2元拍卖一瓶雪碧,限自提!被执行人回应:没有更多可供执行财产
生成图片,分享到微信朋友圈
查看原文
其他
为什么微服务并不是越早越好?
Original
58沈剑
架构师之路
2022-07-22
收录于合集
#分层
5 个
#架构
78 个
#互联网
48 个
#微服务
16 个
#数据库
31 个
微服务架构,是分层架构演进过程中很重要的一环,那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。
什么时候进行DAO层的分层抽象?
最开始,分层架构长什么样?
一个业务系统最初的分层架构如上:
(1)web-server层
从db层获取数据并进行加工处理;
(2)db层
存储数据;
此时,web-server层如何获取底层的数据呢?
web-server层获取数据的一段伪代码如上,不用纠结代码的细节,也不用纠结不同编程语言与不同数据库驱动的差异,其获取数据的过程大致为:
(1)创建一个与数据库的
连接
,初始化资源;
(2)根据业务拼装一个
SQL语句;
(3)通过连接执行SQL语句,并获得
结果集;
(4)通过
游标
遍历结果集,取出每行数据,亦可从每行数据中取出属性数据;
(5)关闭数据库连接,回收资源;
如果业务不复杂,这段代码写1次2次还可以,但如果业务越来越复杂,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。
如何让数据的获取更加高效快捷呢?
通过技术手段能够实现:
(1)表
与类的映射;
(2)属性
与成员的映射;
(3)SQL
与函数的映射;
绝大部分公司正在用的ORM,DAO等技术,就是一种分层抽象,可以提高数据获取的效率,屏蔽连接,游标,结果集这些复杂性。
于是,分层架构就演进了。
当
手写代码从DB中获取数据,成为通用痛点的时候,
就
应该分层抽象出DAO层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。
然后呢?
抽象出DAO层之后,系统架构并不会一成不变:
(1)随着
业务越来越复杂
,业务系统会不断进行垂直拆分;
(2)随着
数据量越来越大
,数据库会进行水平切分;
(3)随着
读并发的越来越大
,会增加缓存降低数据库的压力;
于是系统架构变成了这个样子:
业务系统垂直拆分
,
数据库水平切分
,
缓存
这些都是常见的架构优化手段。
此时,web-server层如何获取底层的数据呢?
根据楼主的经验,以用户数据为例,流程一般是这样的:
(1)先查缓存
:先用uid尝试从缓存获取数据,如果cache hit,数据获取成功,返回User实体,流程结束;
(2)确定路由
:如果cache miss,先查询路由配置,确定uid落在哪个数据库实例的哪个库上;
(3)查询DB
:通过DAO从对应库获取uid对应的数据实体User;
(4)插入缓存
:将kv(uid, User)放入缓存,以便下次缓存查询数据能够命中缓存;
如果业务不复杂,这段代码写1次2次还可以,但如果业务越来越复杂,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。
特别的,业务垂直拆分成非常多的子系统之后:
(1)一旦底层有稍许变化,所有上游的系统都需要升级修改;
(2)子系统之间很可能出现代码拷贝;
(3)一旦拷贝代码,出现一个bug,多个子系统都需要升级修改;
不相信业务会垂直拆分成多个子系统?举两个例子:
(1)58同城有招聘、房产、二手、二手车、黄页等5大头部业务,都需要访问用户数据;
(2)到家集团有月嫂、保姆、快狗打车、蓝服等多个业务,也都需要访问用户数据;
如果
每个子系统都需要关注缓存,分库,读写分离的复杂性
,调用层会疯掉的。
如何让数据的获取更加高效快捷呢?
服务化,数据服务层的抽象势在必行。
通过抽象数据服务层:
(1)web-server层
可以通过RPC接口,像调用本地函数一样调用远端的数据;
(2)数据服务层
,只有这一处需要关注缓存,分库,读写分离这些复杂性;
于是,分层架构就又演进了。
当
业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候,
就
应该抽象出数据服务层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。
那微服务是不是越早越好呢?
互联网分层架构是一个很有意思的问题,服务化的引入,并不是越早越好:
(1)请求处理时间可能会增加;
(2)运维可能会更加复杂;
(3)定位问题可能会更加麻烦;
千万别鲁莽的在“微服务”大流之下,草率的进行微服务改造,看似“高大上架构”的背后,隐藏着更多并未接触过的“大坑”。还是那句话,架构和业务的特点和阶段有关:
一切脱离业务的架构设计,都是耍流氓
。
相关推荐
:
《
InnoDB并发如此高,原因竟然在这?
》
《
InnoDB索引,终于懂了
》
《
InnoDB,调试死锁的方法!
》
您可能也对以下帖子感兴趣
{{{title}}}
文章有问题?点此查看未经处理的缓存