互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)，是數(shù)據(jù)的移動,。

互聯(lián)網(wǎng)分層架構(gòu)演進的核心原則：

• 讓上游更高效的獲取與處理數(shù)據(jù),，復(fù)用

• 讓下游能屏蔽數(shù)據(jù)的獲取細節(jié),，封裝

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

本文主要解答兩個問題：

• 后端架構(gòu),，什么時候進行DAO層的抽象

• 后端架構(gòu),，什么時候進行數(shù)據(jù)服務(wù)層的抽象

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

一個業(yè)務(wù)系統(tǒng)最初的后端結(jié)構(gòu)如上：

• web-server層從db層獲取數(shù)據(jù)并進行加工處理

• db層存儲數(shù)據(jù)

此時，web-server層如何獲取底層的數(shù)據(jù)呢,？

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

• 創(chuàng)建一個與數(shù)據(jù)庫的連接,，初始化資源

• 根據(jù)業(yè)務(wù)拼裝一個SQL語句

• 通過連接執(zhí)行SQL語句，并獲得結(jié)果集

• 通過游標遍歷結(jié)果集,，取出每行數(shù)據(jù),，亦可從每行數(shù)據(jù)中取出屬性數(shù)據(jù)

• 關(guān)閉數(shù)據(jù)庫連接,，回收資源

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

如何讓數(shù)據(jù)的獲取更加高效快捷呢,？

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

• 表與類的映射

• 屬性與成員的映射

• SQL與函數(shù)的映射

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

結(jié)論

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

核心問題二：什么時候要進行數(shù)據(jù)服務(wù)層的抽象

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

• 隨著業(yè)務(wù)越來越復(fù)雜,，業(yè)務(wù)系統(tǒng)會不斷進行垂直拆分

• 隨著數(shù)據(jù)量越來越大,，數(shù)據(jù)庫會進行水平切分

• 隨著讀并發(fā)的越來越大，會增加緩存降低數(shù)據(jù)庫的壓力

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

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

此時,，web-server層如何獲取底層的數(shù)據(jù)呢,？

根據(jù)樓主的經(jīng)驗，以用戶數(shù)據(jù)為例,，流程一般是這樣的：

• 先查緩存：先用uid嘗試從緩存獲取數(shù)據(jù),，如果cache hit，數(shù)據(jù)獲取成功,，返回User實體,，流程結(jié)束

• 確定路由：如果cache miss，先查詢路由配置,，確定uid落在哪個數(shù)據(jù)庫實例的哪個庫上

• 查詢DB：通過DAO從對應(yīng)庫獲取uid對應(yīng)的數(shù)據(jù)實體User

• 插入緩存：將kv(uid, User)放入緩存,，以便下次緩存查詢數(shù)據(jù)能夠命中緩存

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

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

• 一旦底層有稍許變化，所有上游的系統(tǒng)都需要升級修改

• 子系統(tǒng)之間很可能出現(xiàn)代碼拷貝

• 一旦拷貝代碼,，出現(xiàn)一個bug,，多個子系統(tǒng)都需要升級修改

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

• 58同城有招聘、房產(chǎn),、二手,、二手車、黃頁等5大頭部業(yè)務(wù),，都需要訪問用戶數(shù)據(jù)

• 58到家有月嫂,、保姆、麗人,、速運,、平臺等多個業(yè)務(wù)，也都需要訪問用戶數(shù)據(jù)

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

如何讓數(shù)據(jù)的獲取更加高效快捷呢,？

服務(wù)化,，數(shù)據(jù)服務(wù)層的抽象勢在必行,。

通過抽象數(shù)據(jù)服務(wù)層：

• web-server層可以通過RPC接口，像調(diào)用本地函數(shù)一樣調(diào)用遠端的數(shù)據(jù)

• 數(shù)據(jù)服務(wù)層,，只有這一處需要關(guān)注緩存,，分庫，讀寫分離這些復(fù)雜性

服務(wù)化這里就不展開,，更詳細的可參考《互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化,？》。 

結(jié)論

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

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

• 請求處理時間可能會增加

• 運維可能會更加復(fù)雜

• 定位問題可能會更加麻煩

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

這一篇先到這里，分層架構(gòu),，還有很多內(nèi)容要和大家聊：

• 后端架構(gòu),，是否需要抽取中臺業(yè)務(wù)，什么時機抽取

• 后端架構(gòu),，是否需要前后端分離,，什么時機分離

• 前端架構(gòu)，如何進行分層實踐

末了,，再次強調(diào)下,，互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)，是數(shù)據(jù)的移動,。

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