《互聯網分層架構的本質》簡述了兩個觀點：

• 互聯網分層架構的本質，是數據的移動
• 互聯網分層架構演進的核心原則：是讓上游更高效的獲取與處理數據，讓下游能屏蔽數據的獲取細節

《分層架構：什么時候抽象DAO層，什么時候抽象數據服務層》中的觀點是：

• 當手寫代碼從DB中獲取數據，成為通用痛點的時候，就應該抽象出DAO層，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性
• 當業務越來越復雜，垂直拆分的系統越來越多，數據庫實施了水平切分，數據層實施了緩存加速之后，底層數據獲取復雜性成為通用痛點的時候，就應該抽象出數據服務層，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性

文本將要解答的問題是：

• 基礎數據的訪問需要服務化，業務層是否需要服務化
• 如果需要服務化，什么時候服務化

基礎數據的訪問服務化之后，一個業務系統的后端架構如上：

• web-server通過RPC接口，從基礎數據service獲取數據
• 基礎數據service通過DAO，從db/cache獲取數據
• db/cache存儲數據

隨著時間的推移，系統架構并不會一成不變：

• 隨著業務越來越復雜，業務會不斷進行垂直拆分
• 隨著數據越來越復雜，基礎數據service也會越來越多

于是系統架構變成了上圖這個樣子，業務垂直拆分，有若干個基礎數據服務：

• 垂直業務要通過多個RPC接口訪問不同的基礎數據service，service共有是服務化的特征
• 每個基礎數據service訪問自己的數據存儲，數據私有也是服務化的特征

這個架構圖中的依賴關系是不是看上去很別扭?

• 基礎數據service與存儲層之前連接關系很清晰
• 業務web-server層與基礎數據service層之間的連接關系錯綜復雜，變成了蜘蛛網

再舉一個更具體的例子，58同城列表頁web-server如何獲取底層的數據?

• 首先調用商業基礎service，獲取商業廣告帖子數據，用于頂部置頂/精準的廣告帖子展示
• 再調用搜索基礎service，獲取自然搜索帖子數據，用于中部自然搜索帖子展示
• 再調用推薦基礎service，獲取推薦帖子數據，用于底部推薦帖子展示
• 再調用用戶基礎service，獲取用戶數據，用于右側用戶信息展示
• …

如果只有一個列表頁這么寫還行，但如果有招聘、房產、二手、二手車、黃頁…等多個大部分是共性數據，少部分是個性數據的列表頁，每次都這么獲取數據，就略顯低效了，有大量冗余、重復、每次必寫的代碼。

特別的，不同業務上游列表頁都依賴于底層若干相同服務：

• 一旦一個服務RPC接口有稍許變化，所有上游的系統都需要升級修改
• 子系統之間很可能出現代碼拷貝
• 一旦拷貝代碼，出現一個bug，多個子系統都需要升級修改

如何讓數據的獲取更加高效快捷呢?

業務服務化，通用業務服務層的抽象勢在必行。

通過抽象通用業務服務層，例如58同城“通用列表服務”：

• web-server層，可以通過RPC接口，像調用本地函數一樣，調用通用業務service，一次性獲取所有通用數據
• 通用業務service，也可以通過多次調用基礎數據service提供的RPC接口，分別獲取數據，底層數據獲取的復雜性，全都屏蔽在了此處

是不是連接關系也看起來更清晰?

這樣的好處是：

• 復雜的從基礎服務獲取數據代碼，只有在通用業務service處寫了一次，沒有代碼拷貝
• 底層基礎數據service接口發生變化，只有通用業務service一處需要升級修改
• 如果有bug，不管是底層基礎數據service的bug，還是通用業務service的bug，都只有一處需要升級修改
• 業務web-server獲取數據更便捷，獲取所有數據，只需一個RPC接口調用

結論：

當業務越來越復雜，垂直拆分的系統越來越多，基礎數據服務越來越多，底層數據獲取復雜性成為通用痛點的時候，就應該抽象出通用業務服務，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性。

最后再強調兩點：

• 是否需要抽象通用業務服務，和業務復雜性，以及業務發展階段有關，不可一概而論
• 需要抽象什么通用業務服務，和具體業務相關

任何脫離業務的架構設計，都是耍流氓。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文