为什么微服务并不是越早越好?

开发 开发工具 架构
微服务架构,是分层架构演进过程中很重要的一环,那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。

微服务架构,是分层架构演进过程中很重要的一环,那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。

[[405190]]

什么时候进行DAO层的分层抽象?

最开始,分层架构长什么样?

一个业务系统最初的分层架构如上:

  • web-server层从db层获取数据并进行加工处理;
  • db层存储数据;

此时,web-server层如何获取底层的数据呢?

web-server层获取数据的一段伪代码如上,不用纠结代码的细节,也不用纠结不同编程语言与不同数据库驱动的差异,其获取数据的过程大致为:

  • 创建一个与数据库的连接,初始化资源;
  • 根据业务拼装一个SQL语句;
  • 通过连接执行SQL语句,并获得结果集;
  • 通过游标遍历结果集,取出每行数据,亦可从每行数据中取出属性数据;
  • 关闭数据库连接,回收资源;

如果业务不复杂,这段代码写1次2次还可以,但如果业务越来越复杂,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。

如何让数据的获取更加高效快捷呢?

通过技术手段能够实现:

  • 表与类的映射;
  • 属性与成员的映射;
  • SQL与函数的映射;

绝大部分公司正在用的ORM,DAO等技术,就是一种分层抽象,可以提高数据获取的效率,屏蔽连接,游标,结果集这些复杂性。

于是,分层架构就演进了。

当手写代码从DB中获取数据,成为通用痛点的时候,就应该分层抽象出DAO层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。

然后呢?

抽象出DAO层之后,系统架构并不会一成不变:

  • 随着业务越来越复杂,业务系统会不断进行垂直拆分;
  • 随着数据量越来越大,数据库会进行水平切分;
  • 随着读并发的越来越大,会增加缓存降低数据库的压力;

于是系统架构变成了这个样子:

业务系统垂直拆分,数据库水平切分,缓存这些都是常见的架构优化手段。

此时,web-server层如何获取底层的数据呢?

根据楼主的经验,以用户数据为例,流程一般是这样的:

  • 先查缓存:先用uid尝试从缓存获取数据,如果cache hit,数据获取成功,返回User实体,流程结束;
  • 确定路由:如果cache miss,先查询路由配置,确定uid落在哪个数据库实例的哪个库上;
  • 查询DB:通过DAO从对应库获取uid对应的数据实体User;
  • 插入缓存:将kv(uid, User)放入缓存,以便下次缓存查询数据能够命中缓存;

如果业务不复杂,这段代码写1次2次还可以,但如果业务越来越复杂,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。

特别的,业务垂直拆分成非常多的子系统之后:

  • 一旦底层有稍许变化,所有上游的系统都需要升级修改;
  • 子系统之间很可能出现代码拷贝;
  • 一旦拷贝代码,出现一个bug,多个子系统都需要升级修改;

不相信业务会垂直拆分成多个子系统?举两个例子:

  • 58同城有招聘、房产、二手、二手车、黄页等5大头部业务,都需要访问用户数据;
  • 到家集团有月嫂、保姆、快狗打车、蓝服等多个业务,也都需要访问用户数据;

如果每个子系统都需要关注缓存,分库,读写分离的复杂性,调用层会疯掉的。

如何让数据的获取更加高效快捷呢?

服务化,数据服务层的抽象势在必行。

通过抽象数据服务层:

  • web-server层可以通过RPC接口,像调用本地函数一样调用远端的数据;
  • 数据服务层,只有这一处需要关注缓存,分库,读写分离这些复杂性;

于是,分层架构就又演进了。

当业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候,就应该抽象出数据服务层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。

那微服务是不是越早越好呢?

互联网分层架构是一个很有意思的问题,服务化的引入,并不是越早越好:

  • 请求处理时间可能会增加;
  • 运维可能会更加复杂;
  • 定位问题可能会更加麻烦;

千万别鲁莽的在“微服务”大流之下,草率的进行微服务改造,看似“高大上架构”的背后,隐藏着更多并未接触过的“大坑”。还是那句话,架构和业务的特点和阶段有关:一切脱离业务的架构设计,都是耍流氓。

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

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

 

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

2020-10-18 12:36:06

Python开发函数

2022-03-13 23:19:04

元宇宙区块链数字货币

2017-12-15 14:00:11

物联网互联网IoT

2011-07-26 13:47:06

AndroidLinux

2015-12-17 11:04:00

云开支云计算

2020-11-04 10:23:21

云计算数字化转型IT基础设施

2011-07-28 09:45:59

云计算

2011-08-31 15:52:26

微软

2017-10-18 22:18:09

2023-06-25 20:07:57

云计算

2013-05-02 16:21:26

APP

2015-05-08 07:29:42

OpenStack云方案云服务成本

2010-06-10 14:49:07

协议转换器

2021-07-15 06:43:12

SQLSelect命令

2018-11-27 14:57:00

IPv6IPv4网络

2009-04-28 09:13:27

MySQLOracle收购

2013-08-16 09:34:31

VMwareOpenStack

2017-03-09 09:54:13

分析数据可视化

2012-07-31 16:31:56

云计算

2021-06-24 08:20:15

MySQL数据库索引
点赞
收藏

51CTO技术栈公众号