互联网 分层架构的本质 ，是 数据的移动 。

互联网分层架构演进的核心原则：

• 让 上游 更 高效的获取与处理数据 ， 复用

• 让 下游 能 屏蔽数据的获取细节 ， 封装

这些在上一篇《 互联网分层架构的本质 》中有详尽的描述，在实际系统架构演进过程中，如何利用这两个原则，对系统逐步进行分层抽象呢？咱们先从后端系统开始讲解。

本文主要解答两个问题：

• 后端架构， 什么时候进行DAO层的抽象

• 后端架构， 什么时候进行数据服务层的抽象

核心问题一：什么时候进行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大头部业务，都需要访问用户数据

• 58到家有月嫂、保姆、丽人、速运、平台等多个业务，也都需要访问用户数据

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

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

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

通过抽象数据服务层：

• web-server层