转载

互联网架构为什么要做服务化？

近期参加一些业界的技术大会， “ 微服务架构 ” 的话题非常之火，也在一些场合聊过服务化架构实践，最近几期文章期望用通俗易懂的语言聊聊了个人对服务化以及微服务架构的理解，希望能给大伙一些启示。如果有遗漏，也欢迎大家补充。

一、互联网高可用架构，为什么要服务化？

【服务化之前高可用架构】

在服务化之前，互联网的高可用架构大致是这样一个架构：

互联网架构为什么要做服务化？（ 1 ）用户端是浏览器 browser ， APP 客户端

（ 2 ）后端入口是高可用的 nginx 集群，用于做反向代理

（ 3 ）中间核心是高可用的 web-server 集群，研发工程师主要编码工作就是在这一层

（ 4 ）后端存储是高可用的 db 集群，数据存储在这一层

互联网架构为什么要做服务化？更典型的， web-server 层是通过 DAO/ORM 等技术来访问数据库的。

可以看到，最初都是没有服务层的，此时架构会碰到一些什么痛点呢？

【架构痛点一：代码到处拷贝】

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

互联网架构为什么要做服务化？在有用户服务之前，各个业务线都是自己通过 DAO 写 SQL 访问 user 库来存取用户数据，这无形中就导致了代码的拷贝。

【架构痛点二：复杂性扩散】

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

互联网架构为什么要做服务化？对于用户数据的写请求，所有业务线都要升级代码：

（ 1 ）先淘汰 cache

（ 2 ）再写数据

对于用户数据的读请求，所有业务线也都要升级代码：

（ 1 ）先读 cache ，命中则返回

（ 2 ）没命中则读数据库

（ 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 数据，还会结合自己的业务访问自己的数据：

互联网架构为什么要做服务化？典型的，通过 join 数据表来实现各自业务线的一些业务逻辑。

这样的话，业务线 A 的 table-user 与 table-A 耦合在了一起，业务线 B 的 table-user 与 table-B 耦合在了一起，业务线 C 的 table-user 与 table-C 耦合在了一起，结果就是： table-user ， table-A ， table-B ， table-C 都耦合在了一起。