啊，業務層是否也須要服務化？

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

• 互聯網分層架構的本質，是數據的移動

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

 

《分層架構：何時抽象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接口調用

 

結論：

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

 

最後再強調兩點：

• 是否須要抽象通用業務服務，和業務複雜性，以及業務發展階段有關，不可一律而論

• 須要抽象什麼通用業務服務，和具體業務相關

 

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