從單體應用走向服務化

以前講解了什麼是微服務：微服務的核心在於服務治理，微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分，每一個拆分出來的服務各自獨立打包部署，並交由小團隊進行開發和運維，從而極大地提升了應用交付的效率。

何時進行服務化拆分？拆分單體應用有哪些標準呢？

何時進行服務化拆分？

好比作社交 App，初期爲了快速上線，驗證可行性，能夠只開發首頁信息流、評論等基本功能。產品上線後，通過一段時間的運營，用戶開始逐步增多，可行性驗證經過，下一階段就須要進一步增長更多的新特性來吸引更多的目標用戶，好比再給這個社交 App 添加我的主頁顯示、消息通知等功能。

這個時候就須要大規模地擴張開發人員，以支撐多個功能的開發。若是這個時候繼續採用單體應用架構，多個功能模塊混雜在一塊兒開發、測試和部署的話，就會致使不一樣功能之間相互影響，一次打包部署須要全部的功能都測試 OK 才能上線。並且，多個功能模塊混部在一塊兒，對線上服務的穩定性也是個巨大的挑戰。

再例舉一個 58 到家的例子，隨着業務愈來愈複雜，數據量愈來愈大，併發量愈來愈大，15 年的時候，58 到家的架構碰到了種種問題：

• 垂直業務擴展，家政、麗人、速運、平臺，一些類似的業務代碼拷貝愈來愈嚴重
• 數據量、併發量提高，底層架構複雜性不斷向上遊擴散，全部調用方都須要關注緩存、分庫、存儲引擎等，效率逐步下降
• jar 包耦合，多個系統依賴一個公用的 jar 包，一個業務升級致使兼容性問題，影響其餘業務
• 數據庫耦合，多個業務公用一個數據庫，相互耦合，相互影響
• SQL 質量低，業務相互耦合，一個業務編寫了一個低質量的 SQL，致使其餘業務受影響

這個時候 58 到家開始進行服務化拆分，找到通用痛點，抽象出通用數據訪問與子業務，而後將它們下沉成微服務。

通常來講，一旦單體應用同時進行開發的人員超過 10 人，就會遇到上面的問題，這個時候就該考慮進行服務化拆分了。

服務化拆分的兩種姿式

那麼服務化拆分具體該如何實施呢？一個最有效的手段就是將不一樣的功能模塊服務化，獨立部署和運維。之前面提到的社交 App 爲例，能夠認爲首頁信息流是一個服務，評論是一個服務，消息通知是一個服務，我的主頁也是一個服務。

這種服務化拆分方式是縱向拆分，是從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分爲一個微服務，而功能相對比較獨立的業務適合單獨拆分爲一個微服務。

還有一種服務化拆分方式是橫向拆分，是從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其餘服務調用，且依賴的資源獨立不與其餘業務耦合。

之前面的社交 App 爲例，不管是首頁信息流、評論、消息箱仍是我的主頁，都須要顯示用戶的暱稱。若是把用戶的暱稱功能單獨部署成一個獨立的服務，那麼有什麼變動我只須要上線這個服務便可，其餘服務不受影響，開發和上線成本就大大下降了。

服務化拆分的前置條件

通常狀況下，業務系統引入新技術就必然會帶來架構的複雜度提高，在具體決策前，先要認識到新架構會帶來哪些新的問題，這些問題你和你的團隊是否可以解決？如何解決？是本身投入人力建設，仍是採用業界開源方案？

下面幾個問題，是從單體應用遷移到微服務架構時必將面臨也必須解決的。

• 服務如何定義：對於單體應用來講，不一樣功能模塊以前相互交互時，一般是以類庫的方式來提供各個模塊的功能。對於微服務來講，每一個服務都運行在各自的進程之中，經過接口向外界傳達信息。不管採用哪一種通信協議，是 HTTP 仍是 RPC，服務之間的調用都經過接口描述來約定，約定內容包括接口名、接口參數以及接口返回值。

• 服務如何發佈和訂閱：單體應用因爲部署在同一個 WAR 包裏，接口之間的調用屬於進程內的調用。而拆分爲微服務獨立部署後，就須要一個可以記錄每一個服務提供者的地址以供服務調用者查詢，也就是註冊中心（如 Zookeeper、Eureka、Consul 等）。

• 服務如何監控：對於一個服務，須要一種通用的監控方案，可以覆蓋業務埋點、數據收集、數據處理，最後到數據展現的全鏈路功能。

• 服務如何治理：拆分爲微服務後，服務的數量變多，依賴關係變複雜。好比一個服務的性能有問題時，依賴的服務也會受影響。能夠設定一個調用性能閾值，若是一段時間內一直超過閾值，那麼依賴服務的調用能夠直接返回，也就是熔斷。

• 故障如何定位：拆分爲微服務後，一次用戶調用可能依賴多個服務，每一個服務又部署在不一樣的節點上，若是用戶調用出現問題，須要一種解決方案可以將一次用戶請求進行標記，並在多個依賴的服務系統中繼續傳遞，以便串聯全部路徑，從而進行故障定位。

針對上述問題，必須有可行的解決方案以後，才能進行服務化拆分。

總結

不管是縱向拆分仍是橫向拆分，都是將單體應用龐雜的功能進行拆分，抽離成單獨的服務部署。

但並非功能拆分的越細越好，過分的拆分反而會讓服務數量膨脹變得難以管理，所以找到符合本身業務現狀和團隊人員技術水平的拆分粒度纔是可取的。

<center><img src="https://img2018.cnblogs.com/blog/1356806/201910/1356806-20191009000648748-355850292.png" /></center>

參考

https://time.geekbang.org/column/article/13891

https://www.infoq.cn/article/2017/09/Do-your-service-first

原文出處：https://www.cnblogs.com/wupeixuan/p/11657549.html