網際網路分層架構的本質，是資料的移動。
網際網路分層架構演進的核心原則：
- 讓上遊更高效的擷取與處理資料，複用
- 讓下遊能屏蔽資料的擷取細節，封裝
這些在上一篇《網際網路分層架構的本質》中有詳盡的描述，在實際系統架構演進過程中，如何利用這兩個原則，對系統逐漸進行分層抽象呢？咱們先從後端系統開始講解。
本文主要解答兩個問題：
- 後端架構，什麼時候進行DAO層的抽象
- 後端架構，什麼時候進行資料服務層的抽象
核心問題一：什麼時候進行DAO層的抽象
一個業務系統最初的後端結構如上：
- web-server層從db層擷取資料并進行加工處理
- db層存儲資料
此時，web-server層如何擷取底層的資料呢？
web-server層擷取資料的一段僞代碼如上，不用糾結代碼的細節，也不用糾結不同程式設計語言與不同資料庫驅動的差異，其擷取資料的過程大緻為：
- 建立一個與資料庫的連接配接，初始化資源
- 根據業務拼裝一個SQL語句
- 通過連接配接執行SQL語句，并獲得結果集
- 通過遊标周遊結果集，取出每行資料，亦可從每行資料中取出屬性資料
- 關閉資料庫連接配接，回收資源
如果業務不複雜，這段代碼寫1次2次還可以，但如果業務越來越複雜，每次都這麼擷取資料，就略顯低效了，有大量備援、重複、每次必寫的代碼。
如何讓資料的擷取更加高效快捷呢？
通過技術手段實作：
- 表與類的映射
- 屬性與成員的映射
- SQL與函數的映射
絕大部分公司正在用的ORM，DAO等技術，就是一種分層抽象，可以提高資料擷取的效率，屏蔽連接配接，遊标，結果集這些複雜性。
結論
當手寫代碼從DB中擷取資料，成為通用痛點的時候，就應該抽象出DAO層，簡化資料擷取過程，提高資料擷取效率，向上遊屏蔽底層的複雜性。
核心問題二：什麼時候要進行資料服務層的抽象
抽象出DAO層之後，系統架構并不會一成不變：
- 随着業務越來越複雜，業務系統會不斷進行垂直拆分
- 随着資料量越來越大，資料庫會進行水準切分
- 随着讀并發的越來越大，會增加緩存降低資料庫的壓力
于是系統架構變成了這個樣子：
業務系統垂直拆分，資料庫水準切分，緩存這些都是常見的架構優化手段。
根據樓主的經驗，以使用者資料為例，流程一般是這樣的：
- 先查緩存：先用uid嘗試從緩存擷取資料，如果cache hit，資料擷取成功，傳回User實體，流程結束
- 确定路由：如果cache miss，先查詢路由配置，确定uid落在哪個資料庫執行個體的哪個庫上
- 查詢DB：通過DAO從對應庫擷取uid對應的資料實體User
- 插入緩存：将kv(uid, User)放入緩存，以便下次緩存查詢資料能夠命中緩存
特别的，業務垂直拆分成非常多的子系統之後：
- 一旦底層有稍許變化，所有上遊的系統都需要更新修改
- 子系統之間很可能出現代碼拷貝
- 一旦拷貝代碼，出現一個bug，多個子系統都需要更新修改
不相信業務會垂直拆分成多個子系統？舉兩個例子：
- 58同城有招聘、房産、二手、二手車、黃頁等5大頭部業務，都需要通路使用者資料
- 58到家有月嫂、保姆、麗人、速運、平台等多個業務，也都需要通路使用者資料
- 如果每個子系統都需要關注緩存，分庫，讀寫分離的複雜性，調用層會瘋掉的。
服務化，資料服務層的抽象勢在必行。
通過抽象資料服務層：
- web-server層可以通過RPC接口，像調用本地函數一樣調用遠端的資料
- 資料服務層，隻有這一處需要關注緩存，分庫，讀寫分離這些複雜性
服務化這裡就不展開，更詳細的可參考《網際網路架構為什麼要做服務化？》。
當業務越來越複雜，垂直拆分的系統越來越多，資料庫實施了水準切分，資料層實施了緩存加速之後，底層資料擷取複雜性成為通用痛點的時候，就應該抽象出資料服務層，簡化資料擷取過程，提高資料擷取效率，向上遊屏蔽底層的複雜性。
網際網路分層架構是一個很有意思的問題，服務化的引入，并不是越早越好：
- c請求處理時間可能會增加
- 運維可能會更加複雜
- 定位問題可能會更加麻煩
千萬别魯莽的在“微服務”大流之下，草率的進行微服務改造，看似“高大上架構”的背後，隐藏着更多并未接觸過的“大坑”。還是那句話，架構和業務的特點和階段有關：一切脫離業務的架構設計，都是耍流氓。
這一篇先到這裡，分層架構，還有很多内容要和大家聊：
- 後端架構，是否需要抽取中台業務，什麼時機抽取
- 後端架構，是否需要前後端分離，什麼時機分離
- 前端架構，如何進行分層實踐
末了，再次強調下，網際網路分層架構的本質，是資料的移動。
網際網路分層架構演進的核心原則，是讓上遊更高效的擷取與處理資料，讓下遊能屏蔽掉資料的複雜性擷取細節。