為什么微服務并不是越早越好？
微服務架構，是分層架構演進過程中很重要的一環，那微服務是不是越早越好呢?今天和大家一起聊聊這一個問題。
什么時候進行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大頭部業務，都需要訪問用戶數據;
- 到家集團有月嫂、保姆、快狗打車、藍服等多個業務，也都需要訪問用戶數據;
如果每個子系統都需要關注緩存，分庫，讀寫分離的復雜性，調用層會瘋掉的。
如何讓數據的獲取更加高效快捷呢?
服務化，數據服務層的抽象勢在必行。
通過抽象數據服務層：
- web-server層可以通過RPC接口，像調用本地函數一樣調用遠端的數據;
- 數據服務層，只有這一處需要關注緩存，分庫，讀寫分離這些復雜性;
于是，分層架構就又演進了。
當業務越來越復雜，垂直拆分的系統越來越多，數據庫實施了水平切分，數據層實施了緩存加速之后，底層數據獲取復雜性成為通用痛點的時候，就應該抽象出數據服務層，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性。
那微服務是不是越早越好呢?
互聯網分層架構是一個很有意思的問題，服務化的引入，并不是越早越好：
- 請求處理時間可能會增加;
- 運維可能會更加復雜;
- 定位問題可能會更加麻煩;
千萬別魯莽的在“微服務”大流之下，草率的進行微服務改造，看似“高大上架構”的背后，隱藏著更多并未接觸過的“大坑”。還是那句話，架構和業務的特點和階段有關：一切脫離業務的架構設計，都是耍流氓。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
