互聯(lián)網分層架構的本質，是數據的移動。

互聯(lián)網分層架構演進的核心原則：

• 讓上游更高效的獲取與處理數據，復用
• 讓下游能屏蔽數據的獲取細節(jié)，封裝

這些在上一篇《互聯(lián)網分層架構的本質》中有詳盡的描述，在實際系統(tǒng)架構演進過程中，如何利用這兩個原則，對系統(tǒng)逐步進行分層抽象呢?咱們先從后端系統(tǒng)開始講解。

本文主要解答兩個問題：

• 后端架構，什么時候進行DAO層的抽象
• 后端架構，什么時候進行數據服務層的抽象

核心問題一：什么時候進行DAO層的抽象

一個業(yè)務系統(tǒng)最初的后端結構如上：

• web-server層從db層獲取數據并進行加工處理
• db層存儲數據

此時，web-server層如何獲取底層的數據呢?

web-server層獲取數據的一段偽代碼如上，不用糾結代碼的細節(jié)，也不用糾結不同編程語言與不同數據庫驅動的差異，其獲取數據的過程大致為：

• 創(chuàng)建一個與數據庫的連接，初始化資源
• 根據業(yè)務拼裝一個SQL語句
• 通過連接執(zhí)行SQL語句，并獲得結果集
• 通過游標遍歷結果集，取出每行數據，亦可從每行數據中取出屬性數據
• 關閉數據庫連接，回收資源

如果業(yè)務不復雜，這段代碼寫1次2次還可以，但如果業(yè)務越來越復雜，每次都這么獲取數據，就略顯低效了，有大量冗余、重復、每次必寫的代碼。

如何讓數據的獲取更加高效快捷呢?

通過技術手段實現(xiàn)：

• 表與類的映射
• 屬性與成員的映射
• SQL與函數的映射

絕大部分公司正在用的ORM，DAO等技術，就是一種分層抽象，可以提高數據獲取的效率，屏蔽連接，游標，結果集這些復雜性。

結論

當手寫代碼從DB中獲取數據，成為通用痛點的時候，就應該抽象出DAO層，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性。

核心問題二：什么時候要進行數據服務層的抽象

抽象出DAO層之后，系統(tǒng)架構并不會一成不變：

• 隨著業(yè)務越來越復雜，業(yè)務系統(tǒng)會不斷進行垂直拆分
• 隨著數據量越來越大，數據庫會進行水平切分
• 隨著讀并發(fā)的越來越大，會增加緩存降低數據庫的壓力

于是系統(tǒng)架構變成了這個樣子：

業(yè)務系統(tǒng)垂直拆分，數據庫水平切分，緩存這些都是常見的架構優(yōu)化手段。

此時，web-server層如何獲取底層的數據呢?

根據樓主的經驗，以用戶數據為例，流程一般是這樣的：

• 先查緩存：先用uid嘗試從緩存獲取數據，如果cache hit，數據獲取成功，返回User實體，流程結束
• 確定路由：如果cache miss，先查詢路由配置，確定uid落在哪個數據庫實例的哪個庫上
• 查詢DB：通過DAO從對應庫獲取uid對應的數據實體User
• 插入緩存：將kv(uid, User)放入緩存，以便下次緩存查詢數據能夠命中緩存

如果業(yè)務不復雜，這段代碼寫1次2次還可以，但如果業(yè)務越來越復雜，每次都這么獲取數據，就略顯低效了，有大量冗余、重復、每次必寫的代碼。

特別的，業(yè)務垂直拆分成非常多的子系統(tǒng)之后：

• 一旦底層有稍許變化，所有上游的系統(tǒng)都需要升級修改
• 子系統(tǒng)之間很可能出現(xiàn)代碼拷貝
• 一旦拷貝代碼，出現(xiàn)一個bug，多個子系統(tǒng)都需要升級修改

不相信業(yè)務會垂直拆分成多個子系統(tǒng)?舉兩個例子：

• 58同城有招聘、房產、二手、二手車、黃頁等5大頭部業(yè)務，都需要訪問用戶數據
• 58到家有月嫂、保姆、麗人、速運、平臺等多個業(yè)務，也都需要訪問用戶數據

如果每個子系統(tǒng)都需要關注緩存，分庫，讀寫分離的復雜性，調用層會瘋掉的。

如何讓數據的獲取更加高效快捷呢?

服務化，數據服務層的抽象勢在必行。

通過抽象數據服務層：

• web-server層可以通過RPC接口，像調用本地函數一樣調用遠端的數據
• 數據服務層，只有這一處需要關注緩存，分庫，讀寫分離這些復雜性

服務化這里就不展開，更詳細的可參考《互聯(lián)網架構為什么要做服務化?》。

結論

當業(yè)務越來越復雜，垂直拆分的系統(tǒng)越來越多，數據庫實施了水平切分，數據層實施了緩存加速之后，底層數據獲取復雜性成為通用痛點的時候，就應該抽象出數據服務層，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性。

互聯(lián)網分層架構是一個很有意思的問題，服務化的引入，并不是越早越好：

• 請求處理時間可能會增加
• 運維可能會更加復雜
• 定位問題可能會更加麻煩

千萬別魯莽的在“微服務”大流之下，草率的進行微服務改造，看似“高大上架構”的背后，隱藏著更多并未接觸過的“大坑”。還是那句話，架構和業(yè)務的特點和階段有關：一切脫離業(yè)務的架構設計，都是耍流氓。

這一篇先到這里，分層架構，還有很多內容要和大家聊：

• 后端架構，是否需要抽取中臺業(yè)務，什么時機抽取
• 后端架構，是否需要前后端分離，什么時機分離
• 前端架構，如何進行分層實踐

末了，再次強調下，互聯(lián)網分層架構的本質，是數據的移動。

互聯(lián)網分層架構演進的核心原則，是讓上游更高效的獲取與處理數據，讓下游能屏蔽掉數據的復雜性獲取細節(jié)。

【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】

本文題目：互聯(lián)網分層架構之DAO與服務化
分享鏈接：http://uogjgqi.cn/article/dhghgcg.html