互联网架构发展的过程中，当业务复杂度剧增，数据量剧增，吞吐量剧增的时候，就会出现一些技术痛点，下边几个都是最常见的：

痛点一：代码到处拷贝

举一个最常见的业务的例子：用户数据的访问。

绝大部分公司都有一个数据库用来存储用户数据，而各个业务都有访问用户数据的需求。

各个业务线都是自己通过 DAO（Data Access Object）写 SQL 访问 user 库来存取用户数据，这无形中就导致了代码的拷贝。

抽象出一个服务层之后，有统一的一份代码，那么就解决了代码复用的问题。同时业务方通过 RPC 访问用户数据，就像调用一个本地函数一样，比如使用

User = UserService::GetUserById(uid);

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

痛点二：复杂性扩散

这个内容主要讲一下下边两个点：

 1、缓存导致的复杂性

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

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

1、先淘汰 cache

2、再写数据

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

1、先读 cache，命中则返回

2、没命中则读数据库

3、再把数据放入 cache

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

 2、分库分表导致的复杂性

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

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

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

痛点三：库的复用与耦合

服务化并不是唯一解决上述两个痛点的方法，另一种方法是抽象出统一的“库”。比如抽象出一个 user.so，负责整个用户数据的存取，从而避免代码的拷贝。至于复杂性，现在也只剩下 user.so 这一个地方需要关注了。

但是这时候会引入新的问题：库的版本维护与业务线之间代码的耦合。

比如业务线 A 将 user.so 由版本 1 升级至版本 2，如果不兼容业务线 B 的代码，那就会导致 B 业务出现问题；业务线 A 如果通知了业务线 B 升级，这时的业务线 B 就会去升级，但这是与它“自身业务无关”的升级。

痛点四：SQL 质量得不到保障，业务相互影响

本质上 SQL 语句还是各个业务线拼装的，资深的工程师写出高质量的 SQL 没啥问题，经验没有这么丰富的工程师可能会写出一些低效的 SQL。业务线通过 DAO 访问数据库，假如业务线 A 写了一个全表扫描的 SQL，导致数据库的 CPU100%，影响的不只是这一个业务线，而是 所有的业务线。

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

痛点五：疯狂的 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 都耦合在了一起。

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

像上边说的，服务层就是在这样的情况下被抽象出来的。概括起来，它就是用来统一完成一部分数据访问或者子业务逻辑。这就是指服务化。

而从这个角度来看，微服务本质上就是指粒度比较细的服务化的实施。

具体到 58 到家 /58 速运

就像上边说的，随着业务越来越复杂，数据量越来越大，并发量越来越大，58 到家因为经历了这些阶段，所以系统架构走上了微服务之路。

具体来说，15 年的时候，58 到家的架构碰到了类似的种种问题：

• 垂直业务扩展，家政、丽人、速运、平台，一些相似的业务代码拷贝越来越严重

• 数据量、并发量提升，底层架构复杂性不断向上游扩散，所有调用方都需要关注缓存、分库、存储引擎等，效率逐步降低

• jar 包耦合，多个系统依赖一个公用的 jar 包，一个业务升级导致兼容性问题，影响其他业务

• 数据库耦合，多个业务公用一个数据库，相互耦合，相互影响

• SQL 质量低，业务相互耦合，一个业务撰写了一个低质量的 SQL，导致其他业务受影响

其实我们也不是一开始就直接采用微服务架构，这个也是经过了不同阶段而演进出来的。

简单地说，58 到家刚开始的时候，我们先 找到通用痛点，抽象出通用数据访问与子业务，然后将它们 下沉成微服务。

更具体地，早期 58 到家是抽象出用户中心，订单中心，支付中心等来构建微服务的。

我们从 58 速运的角度来讲，刚开始 58 到家是大一统阶段，就是系统没有进行业务拆分的时候，因为刚开始业务量也小，所以它还是可行的。

后来整个系统拆分成了站点、数据库、缓存这三个部分。

接着我们进行了垂直拆分，将平台、家政、丽人、速运这些业务拆分开来。

然后就具体到速运这一块进行服务化架构。

而最近我们还在演进这样一个架构，我们知道速运这一块其实它本身也有多个业务形态，有对小 C 的，有对小 B 的。小 C 是搬家服务，小 B 是货的服务，大 B 是优配服务。原来这三块它们都是耦合在一起的，现在也在进行拆分。

这其实也就是架构演进过程中必然会出现的，而具体再讨论下去，其实就是在做一些微服务架构上的事情了。

上边这些说的都是业务的垂直拆分，下边看一下我们的系统分层情况是怎么样的。

我们现在的系统分成了四层，如下：

• 第一层：站点平台

• 第二层：业务服务层。把基础数据通用的东西往上抽，就像上边说的，比如它解决代码拷备的痛点，不能让代码拷来拷去，所以把这份代码抽象成一个服务。解决库的耦合，如果之前没有服务化，可能用代码库，用 jar 包、DLL、SO 库来解决代码拷备这个问题，一个库，多个服务依赖，那库的版本升级，影响范围很大，可能多个服务因为一个库的原因耦合在一起。上边说的这些就是发生在这个层上，它解决的是底层复杂性屏蔽的问题。如果没有服务层，那么 牵一发而动全身。

• 第三层：基础数据服务层。不包含复杂的业务逻辑，只是数据访问的代理，对数据库层的 CRUD。原来设计为相对简单的“DAO 层”。

• 第四层：数据层。数据层包括缓存和 DB。

最开始的时候是没有业务服务层的，业务应用分别直接访问数据库，导致大量耦合；架构演进到第二个阶段的时候，我们抽象出一些通用的 业务无关 的基础服务，例如地理位置服务、经纬度服务、短网址服务、短信服务等；到了第三个阶段，我们抽象出一些 通用业务 的服务，例如 passport 服务、订单中心服务、支付中心服务等；未来，我们会进一步去抽象更多的通用业务服务。总之，整个微服务架构演进的思路就是：“共性 + 通用痛点”抽象下沉。

需要关注的问题