不少公司，都實施了微服務架構，底層抽象出不少基礎數據服務。
（2）基礎數據服務經過DAO，從db/cache獲取數據；
除了基礎
數據的訪問須要服務化，業務層是否須要服務化？若是須要，什麼時機進行服務化？這是本文要討論的兩個問題。
（1）隨着業務愈來愈複雜，業務會不斷進行垂直拆分；
畫外音：以58同城爲例，有招聘、房產、二手、二手車、黃頁等多個業務。
（2）隨着數據愈來愈複雜，基礎數據服務也會愈來愈多；
畫外音，例如：用戶服務，訂單服務，搜索服務，推薦服務等。
因而系統架構變成了上圖這個樣子，業務垂直拆分，有若干個基礎數據服務：
（1）垂直業務要經過多個RPC接口訪問不一樣的基礎數據服務，服務共享是服務化的特徵；
（2）每一個基礎數據服務訪問本身的數據存儲，數據私有也是服務化的特徵；
（2）業務站點層與基礎數據服務層之間的鏈接關係錯綜複雜，變成了蜘蛛網；
再舉一個更具體的例子，58同城列表頁站點如何獲取底層的數據？
（1）首先調用商業基礎服務，獲取商業廣告帖子數據，用於頂部置頂/精準的廣告帖子展現；
（2）再調用搜索基礎服務，獲取天然搜索帖子數據，用於中間天然搜索帖子展現；
（3）再調用推薦基礎服務，獲取推薦帖子數據，用於底部推薦帖子展現；
（4）再調用用戶基礎服務，獲取用戶數據，用於右側用戶信息展現；
若是隻有一個列表頁這麼寫還行，但若是有招聘、房產、二手、二手車、黃頁等多個業務，都這麼獲取共性數據，而只有少部分個性數據，每次都這麼一個個調用基礎服務，有大量冗餘、重複、每次必寫的代碼。
特別的，不一樣業務上游列表頁都依賴於底層若干相同服務：
（1）一旦一個服務RPC接口有稍許變化，全部上游的系統都須要升級修改；
（3）一旦拷貝代碼，出現一個bug，多個子系統都須要升級修改；
經過抽象通用業務服務層，例如58同城「通用列表服務」：
（1）業務站點層，能夠經過RPC接口，像調用本地函數同樣，調用通用業務服務，一次性獲取全部通用數據；
（2）通用業務服務，也能夠經過屢次調用基礎數據服務提供的RPC接口，分別獲取數據，底層數據獲取的複雜性，全都屏蔽在了此處；
（1）複雜的從基礎服務獲取數據代碼，只有在通用業務服務處寫了一次，沒有代碼拷貝；
（2）底層基礎數據服務接口發生變化，只有通用業務服務一處須要升級修改；
（3）若是有bug，無論是底層基礎數據服務的bug，仍是通用業務服務的bug，都只有一處須要升級修改；
（4）業務站點層獲取數據更便捷，獲取全部數據，只需一個RPC接口調用；
因而，當業務愈來愈複雜，垂直拆分的系統愈來愈多，基礎數據服務愈來愈多，底層數據獲取複雜性成爲通用痛點的時候，就應該抽象出通用業務服務，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性。
（1）是否須要抽象通用業務服務，和業務複雜性，以及業務發展階段有關，不可一律而論；
畫外音：若是沒有多個業務線，大機率基礎服務就夠用。
畫外音：帖子列表業務服務，帖子詳情業務服務，是58同城特有的；而基礎服務，例如用戶，訂單，支付等基礎服務，基本上各個公司是相似的。
本文分享自微信公衆號 - 架構師之路（road5858）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。微信
