互联网架构,究竟为啥要做服务化?



转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com

AIQ 机器学习大数据 知乎专栏 点击关注

本文转载自 架构师之路 公众号

最近留言问“微服务”的朋友颇多,找历史文章又找不到,故重新优化发布,希望大家有收获,不要被“微服务大潮”误导。

“微服务架构”的话题非常之火,很多朋友都在小窗我,说怎么做服务化?解答“怎么做”之前,先得了解“为什么做”。

画外音:做技术千万不能是这种思路,“别人都在做,所以我们也要搞”。

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

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

在服务化之前,互联网的典型高可用架构如下:


(1)客户端,APP,H5,小程序,PC 浏览器;

(2)后端入口,高可用的反向代理 nginx 集群;

(3)站点应用,高可用的 web-server 集群;

(4)后端存储,高可用 db 集群;


更典型的,web-server 集群通过 DAO/ORM 等技术来访问数据库。

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

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

举一个最常见的业务例子,用户数据访问,绝大部分公司都有一个数据库存储用户数据,各个业务都有访问用户数据的需求。


在有用户服务之前,各个业务线都是自己通过 DAO 写 SQL 访问 user 库来存取用户数据,这无形中就导致了代码的拷贝。

架构痛点二:复杂性扩散

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


对于写请求,所有业务线都要升级代码:

(1)先淘汰 cache;

(2)再写 db;

对于读请求,所有业务线也都要升级代码:

(1)先读 cache,命中则返回;

(2)没命中则读 db;

(3)再把数据放入 cache;

这个复杂性是典型的“业务无关”的复杂性,业务方需要被迫升级。

随着数据量的越来越大,数据库需要进行水平拆分,于是架构中又引入了分库分表,如果没有统一的服务层,各个业务线都需要关注分库分表的引入导致的复杂性。


这个复杂性也是典型的“业务无关”的复杂性,业务方需要被迫升级。

典型的耦合,还包括 bug 的修改,发现一个 bug,多个地方都需要修改。

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

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

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

解决了旧的问题,会引入新的问题,库的版本维护会导致业务线之间的耦合。

业务线 A 将 user.so 由版本 1 升级至版本 2,如果不兼容业务线 B 的代码,会导致 B 业务出现问题。

业务线 A 如果通知了业务线 B 升级,则是的业务线 B 会无故做一些“自身业务无关”的升级,非常郁闷。当然,如果各个业务线都是拷贝了一份代码则不存在这个问题。

画外音:有时候拷贝代码也是有好处的。

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

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

假如业务线 A 写了一个全表扫描的 SQL,导致数据库的 CPU100%,影响的不只是一个业务线,而是所有的业务线都会受影响。

画外音:临时工程序员要背锅了。

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

业务线不只访问 user 数据,还会结合自己的业务访问自己的数据。

画外音:userbiz 表,也是用 uid 做主键。_

典型的,通过 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 的数据库是无法垂直拆分开的,必须使用一个大库(疯了,一个大库 300 多个业务表 =_=)。

架构痛点六:…

服务化后,高可用架构如何?

互联网高可用分层架构演进的过程中,引入了“服务层”。


以上文中的用户业务为例,引入了高可用 user-service,对业务线响应所用用户数据的存取。

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

好处一:调用方爽

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

有服务层之后,业务方通过 RPC 访问用户数据,就像调用一个本地函数一样,非常之爽:

User = UserService::GetUserById(uid);

传入一个 uid,得到一个 User 实体,就像调用本地函数一样,不需要关心序列化,网络传输,后端执行,网络传输,范序列化等复杂性。

好处二:复用性,防止代码拷贝

所有 user 数据的存取,都通过 user-service 来进行,代码只此一份,不存在拷贝。

升级一处升级,bug 修改一处修改。

好处三:专注性,屏蔽底层复杂度


在没有服务层之前,所有业务线都需要关注缓存、分库分表这些细节。


在有了服务层之后,只有服务层需要专注关注底层的复杂性了,向上游屏蔽了细节。

好处四:SQL 质量得到保障


原来是业务向上游直接拼接 SQL 访问数据库。


有了服务层之后,所有的 SQL 都是服务层提供的,业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话,可以由更资深的工程师维护,而不是像原来 SQL 难以收口,难以控制。

好处五:数据库解耦


原来各个业务的数据库都混在一个大库里,相互 join,难以拆分。


服务化之后,底层的数据库被隔离开了,可以很方便的拆分出来,进行扩容。

好处六:提供有限接口,无限性能

在服务化之前,各业务线上游想怎么操纵数据库都行,遇到了性能瓶颈,各业务线容易扯皮,相互推诿。

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

好处七:…

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

一切脱离业务的架构设计,都是耍流氓。

希望大家有收获。


更多高质资源 尽在AIQ 机器学习大数据 知乎专栏 点击关注

转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com