微服務(wù)架構(gòu)，是分層架構(gòu)演進(jìn)過(guò)程中很重要的一環(huán)，那微服務(wù)是不是越早越好呢？今天和大家一起聊聊這一個(gè)問(wèn)題。

什么時(shí)候進(jìn)行DAO層的分層抽象？

最開(kāi)始，分層架構(gòu)長(zhǎng)什么樣?

一個(gè)業(yè)務(wù)系統(tǒng)最初的分層架構(gòu)如上：

（1）web-server層從db層獲取數(shù)據(jù)并進(jìn)行加工處理；

（2）db層存儲(chǔ)數(shù)據(jù)；

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

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

（1）創(chuàng)建一個(gè)與數(shù)據(jù)庫(kù)的連接，初始化資源；

（2）根據(jù)業(yè)務(wù)拼裝一個(gè)SQL語(yǔ)句；

（3）通過(guò)連接執(zhí)行SQL語(yǔ)句，并獲得結(jié)果集；

（4）通過(guò)游標(biāo)遍歷結(jié)果集，取出每行數(shù)據(jù)，亦可從每行數(shù)據(jù)中取出屬性數(shù)據(jù)；

（5）關(guān)閉數(shù)據(jù)庫(kù)連接，回收資源；

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

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

通過(guò)技術(shù)手段能夠?qū)崿F(xiàn)：

（1）表與類的映射；

（2）屬性與成員的映射；

（3）SQL與函數(shù)的映射；

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

于是，分層架構(gòu)就演進(jìn)了。

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

然后呢？

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

（1）隨著業(yè)務(wù)越來(lái)越復(fù)雜，業(yè)務(wù)系統(tǒng)會(huì)不斷進(jìn)行垂直拆分；

（2）隨著數(shù)據(jù)量越來(lái)越大，數(shù)據(jù)庫(kù)會(huì)進(jìn)行水平切分；

（3）隨著讀并發(fā)的越來(lái)越大，會(huì)增加緩存降低數(shù)據(jù)庫(kù)的壓力；

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

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

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

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

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

（2）確定路由：如果cache miss，先查詢路由配置，確定uid落在哪個(gè)數(shù)據(jù)庫(kù)實(shí)例的哪個(gè)庫(kù)上；

（3）查詢DB：通過(guò)DAO從對(duì)應(yīng)庫(kù)獲取uid對(duì)應(yīng)的數(shù)據(jù)實(shí)體User；

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

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

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

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

（3）一旦拷貝代碼，出現(xiàn)一個(gè)bug，多個(gè)子系統(tǒng)都需要升級(jí)修改；

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

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

（2）到家集團(tuán)有月嫂、保姆、快狗打車、藍(lán)服等多個(gè)業(yè)務(wù)，也都需要訪問(wèn)用戶數(shù)據(jù)；

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

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

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

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

（1）web-server層可以通過(guò)RPC接口，像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的數(shù)據(jù)；

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

于是，分層架構(gòu)就又演進(jìn)了。

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

那微服務(wù)是不是越早越好呢？

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

（1）請(qǐng)求處理時(shí)間可能會(huì)增加；

（2）運(yùn)維可能會(huì)更加復(fù)雜；

（3）定位問(wèn)題可能會(huì)更加麻煩；

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

相關(guān)推薦：

《InnoDB并發(fā)如此高，原因竟然在這？》

《InnoDB索引，終于懂了》

《InnoDB，調(diào)試死鎖的方法！》

為什么微服務(wù)并不是越早越好？

什么時(shí)候進(jìn)行DAO層的分層抽象？

然后呢？

為什么微服務(wù)并不是越早越好？

什么時(shí)候進(jìn)行DAO層的分層抽象？

然后呢？