微服务到底解决了什么问题?

2018年11月21日11:23:30 1 7,586 views
摘要

微服务架构 的话题非常之火,很多朋友都在说怎么做service服务化?
解答“怎么做”之前,先得了解“为什么做”“。
我们做技术千万不能是这种思路,别人都在做,所以我们也要搞`。

并不是所有的业务都适合 服务化,互联网高可用架构,到底为什么要服务化?

一、service服务简介

服务 Service 是什么?
简单来说, 服务就是为满足他人的需求所做的事情, 一个服务就是一个独立的功能单元, 比如上菜服务, 结帐服务, 泊车服务.

但这个服务员既要上菜, 又要结账, 还要代客泊车, 这个服务员会很累, 很烦, 也很容易出错, 比较好的做法是不同的服务由不同的服务员提供, 各司其职, 一个人不要负责太多职责.

所以, 服务化就这样诞生了,而微服务 Micro Service, 意谓一种微小的服务, 崇尚小而美, 避免大而全.

微服务特点:
- 分而治之以降低复杂性
- 分而用之以提高可重用性
- 分而做之以提高开发效率

二、服务化之前,高可用架构是什么样的?

2.1 互联网的典型高可用架构如下:

微服务到底解决了什么问题?
1. 客户端:APP,H5,小程序,PC浏览器;
2. 后端入口:高可用的反向代理nginx集群;
3. 站点应用:高可用的web-server集群;
4. 后端存储:高可用db集群;

2.2 经典业务交互流程图

通过上面的架构图,我们需要了解业务是如何交互的,其中典型的web-server集群是通过DAO/ORM等技术来访问数据库。

DAO:data access object 数据访问对象,用来跟数据库打交道的服务层
ORM: object relation mapping. 对象关系映射。通过映射搞关系框架与数据库交互。

简略交互图入下:
微服务到底解决了什么问题?

可以看到,最初是没有服务层的,此时架构会碰到什么典型痛点呢?

2.3 架构痛点一:代码到处拷贝

举一个最常见的业务例子,用户数据访问,绝大部分公司都有一个数据库存储用户数据,各个业务都有访问用户数据的需求。
微服务到底解决了什么问题?
在有用户服务之前,各个业务线都是自己通过DAO写SQL访问user库来存取用户数据,这无形中就导致了代码的拷贝,增加了负担。

2.4 架构痛点二:复杂性扩散

随着并发量的越来越高,用户数据的访问数据库成了瓶颈,需要加入缓存降低数据库的读压力,于是架构中引入了缓存,如果没有统一的服务层,各个业务线都需要关注缓存的引入导致的复杂性
微服务到底解决了什么问题?

对于写请求,所有业务线都要升级代码:
(1)先淘汰cache;
(2)再写db;

对于读请求,所有业务线也都要升级代码:
(1)先读cache,命中则返回;
(2)没命中则读db;
(3)再把数据放入cache;
这个复杂性是典型的“业务无关”的复杂性,业务方需要被迫升级

2.5 数据架构水平拆分、分库分表

随着数据量的越来越大,数据库需要进行水平拆分,于是架构中又引入了分库分表,如果没有统一的服务层,各个业务线都需要关注分库分表的引入导致的复杂性
微服务到底解决了什么问题?
这个复杂性也是典型的“业务无关”的复杂性,业务方需要被迫升级
典型的耦合,还包括bug的修改,发现一个bug,多个地方都需要修改。

2.6 架构痛点三:库的复用与耦合

服务化并不是唯一的解决上述痛点的方法,抽象出统一的“库”是最先容易想到的解决(1)代码拷贝;(2)复杂性扩散;的方法。

抽象出一个user.so,负责整个用户数据的存取,从而避免代码的拷贝。至于复杂性,也只有user.so这一个地方需要关注了。

解决了的问题,会引入的问题,库的版本维护会导致业务线之间的耦合
问题1:
业务线A将user.so由版本1升级至版本2,如果不兼容业务线B的代码,会导致B业务出现问题。
问题2:
业务线A如果通知了业务线B升级,则是的业务线B会无故做一些“自身业务无关”的升级,非常郁闷。当然,如果各个业务线都是拷贝了一份代码则不存在这个问题。

2.7 架构痛点四:SQL质量无法保障,业务相互影响

微服务到底解决了什么问题?
业务线通过DAO访问数据库,本质上SQL语句还是各个业务线拼装的,资深的工程师写出高质量的SQL,经验没有这么丰富的工程师可能会写出一些低效的SQL。

假如业务线A写了一个全表扫描的SQL,导致数据库的CPU100%,影响的不只是一个业务线,而是所有的业务线都会受影响。
逗哥想说:运维工程序员又要背锅了。

2.8 架构痛点五:疯狂的DB耦合

微服务到底解决了什么问题?
业务线需要访问user数据并且还会结合自己的业务访问自己的数据。
逗哥说:user_biz表,也是用uid做主键。(uid用户ID)
典型的,通过join数据表来实现各自业务线的一些业务逻辑。
问题:
业务线A的table-user与table-A耦合在了一起,业务线B的table-user与table-B耦合在了一起,业务线C的table-user与table-C耦合在了一起,结果就是:table-user,table-A,table-B,table-C都耦合在了一起。
如果后期数据量增大,那么业务ABC将无法垂直拆分,后续的问题可想而知,数据量会越来越大。

2.9 架构痛点六 引用服务化

架构中引用服务化后,形成高可用服务化集群,实现高可用分层结构,对业务线响应用户的数据进行存取
微服务到底解决了什么问题?

引入服务层有什么好处,到底解决什么问题呢?

好处一:调用方便
有服务层之前,业务方访问用户数据,需要通过DAO拼装SQL访问。

有服务层之后,业务方通过RPC访问用户数据,就像调用一个本地函数一样,非常之爽:
User = UserService::GetUserById(uid);
传入一个uid,得到一个User实体,就像调用本地函数一样,不需要关心序列化,网络传输,后端执行,范序列化等复杂性。

好处二:复用性,防止代码拷贝
所有user数据的存取,都通过user-service来进行,代码只此一份,不存在拷贝。

升级1点所有都生效,bug修改一处所有都修改。
好处三:专注性,屏蔽底层复杂度
微服务到底解决了什么问题?
在没有服务层之前,所有业务线都需要关注缓存、分库分表这些细节。
微服务到底解决了什么问题?
在有了服务层之后,只有服务层需要专注关注底层的复杂性了,向上游屏蔽了细节。
好处四:SQL质量得到保障
微服务到底解决了什么问题?
原来是业务访问代码,然后拼接sql访问数据库。
微服务到底解决了什么问题?
有了服务层之后,所有的SQL都是服务层提供的,业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话,可以由更资深的工程师维护,而不是像原来SQL难以收口,难以控制。

好处五:数据库解耦
微服务到底解决了什么问题?
原来各个业务的数据库都混在一个大库里,相互join,难以拆分
微服务到底解决了什么问题?
服务化之后,底层的数据库被隔离开了,可以很方便的拆分出来,进行扩容

好处六:提供有限接口,无限性能
在服务化之前,各业务线上游想怎么操纵数据库都行,遇到了性能瓶颈,各业务线容易扯皮,相互推诿。

服务化之后,服务只提供有限的通用接口,理论上服务集群能够提供无限性能,性能出现瓶颈,服务层一处集中优化。

好处七:思想提升

服务化不能解决所有问题,如果没有碰到这些问题,架构未必需要服务化。

一切脱离业务的架构设计,都是耍流氓。
希望通过此篇,让大家对架构痛点有所了解,更多精彩:逗哥架构师之路

  • QQ精品交流群
  • weinxin
  • 微信公众号
  • weinxin
admin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

    • avatar 请输入您的QQ号 0

      感谢分享