建站
咨詢
售后
建站咨詢
新聞中心
微服務(wù)架構(gòu)，是分層架構(gòu)演進(jìn)過程中很重要的一環(huán)，那微服務(wù)是不是越早越好呢?今天和大家一起聊聊這一個問題。
創(chuàng)新互聯(lián)從2013年創(chuàng)立，先為奉新等服務(wù)建站，奉新等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為奉新企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
什么時候進(jìn)行DAO層的分層抽象?
最開始，分層架構(gòu)長什么樣?
一個業(yè)務(wù)系統(tǒng)最初的分層架構(gòu)如上：
- web-server層從db層獲取數(shù)據(jù)并進(jìn)行加工處理;
- db層存儲數(shù)據(jù);
此時，web-server層如何獲取底層的數(shù)據(jù)呢?
web-server層獲取數(shù)據(jù)的一段偽代碼如上，不用糾結(jié)代碼的細(xì)節(jié)，也不用糾結(jié)不同編程語言與不同數(shù)據(jù)庫驅(qū)動的差異，其獲取數(shù)據(jù)的過程大致為：
- 創(chuàng)建一個與數(shù)據(jù)庫的連接，初始化資源;
- 根據(jù)業(yè)務(wù)拼裝一個SQL語句;
- 通過連接執(zhí)行SQL語句，并獲得結(jié)果集;
- 通過游標(biāo)遍歷結(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ù)手段能夠?qū)崿F(xiàn)：
- 表與類的映射;
- 屬性與成員的映射;
- SQL與函數(shù)的映射;
絕大部分公司正在用的ORM，DAO等技術(shù)，就是一種分層抽象，可以提高數(shù)據(jù)獲取的效率，屏蔽連接，游標(biāo)，結(jié)果集這些復(fù)雜性。
于是，分層架構(gòu)就演進(jìn)了。
當(dāng)手寫代碼從DB中獲取數(shù)據(jù)，成為通用痛點(diǎn)的時候，就應(yīng)該分層抽象出DAO層，簡化數(shù)據(jù)獲取過程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復(fù)雜性。
然后呢?
抽象出DAO層之后，系統(tǒng)架構(gòu)并不會一成不變：
- 隨著業(yè)務(wù)越來越復(fù)雜，業(yè)務(wù)系統(tǒng)會不斷進(jìn)行垂直拆分;
- 隨著數(shù)據(jù)量越來越大，數(shù)據(jù)庫會進(jìn)行水平切分;
- 隨著讀并發(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ù);
- 到家集團(tuán)有月嫂、保姆、快狗打車、藍(lán)服等多個業(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)用遠(yuǎn)端的數(shù)據(jù);
- 數(shù)據(jù)服務(wù)層，只有這一處需要關(guān)注緩存，分庫，讀寫分離這些復(fù)雜性;
于是，分層架構(gòu)就又演進(jìn)了。
當(dāng)業(yè)務(wù)越來越復(fù)雜，垂直拆分的系統(tǒng)越來越多，數(shù)據(jù)庫實施了水平切分，數(shù)據(jù)層實施了緩存加速之后，底層數(shù)據(jù)獲取復(fù)雜性成為通用痛點(diǎn)的時候，就應(yīng)該抽象出數(shù)據(jù)服務(wù)層，簡化數(shù)據(jù)獲取過程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復(fù)雜性。
那微服務(wù)是不是越早越好呢?
互聯(lián)網(wǎng)分層架構(gòu)是一個很有意思的問題，服務(wù)化的引入，并不是越早越好：
- 請求處理時間可能會增加;
- 運(yùn)維可能會更加復(fù)雜;
- 定位問題可能會更加麻煩;
千萬別魯莽的在“微服務(wù)”大流之下，草率的進(jìn)行微服務(wù)改造，看似“高大上架構(gòu)”的背后，隱藏著更多并未接觸過的“大坑”。還是那句話，架構(gòu)和業(yè)務(wù)的特點(diǎn)和階段有關(guān)：一切脫離業(yè)務(wù)的架構(gòu)設(shè)計，都是耍流氓。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
戳這里，看該作者更多好文
新聞名稱：為什么微服務(wù)并不是越早越好？
鏈接地址：http://www.5511xx.com/article/cosehdc.html
