以前的文章討論過《互聯網架構，究竟為啥要做服務化？》，隨著數據量、并發量、業務復雜度的增長，互聯網架構會出現以下問題：

• 代碼到處拷貝

• 底層復雜性擴散

• 基礎庫（so/jar/dll）耦合

• SQL質量得不到保障，業務相互影響

• 數據庫耦合

“服務化”是一個很好的解決上述痛點的方案。

那么問題來了，微服務架構多“微”才合適？

行業內有這樣四類常見實踐。

實踐一：統一服務層

這是最粗獷的玩法，所有基礎數據，都通過一個統一的服務來進行訪問。

在業務不是特別復雜的時候，這不失為一個快速分層的方案，一旦業務變得復雜，服務層會變得非常重，成為耦合焦點。

以微信場景為例，假設通過一個通用的服務層來訪問基礎數據。

則只有一個統一的服務層，用戶信息，好友信息，群組信息，消息信息都通過這個服務層來訪問。

實踐二：一個子業務一個服務

如果所有的數據訪問都通過一個服務層來訪問，那么一行代碼出故障，就將影響整個服務，所以更合理的做法是在服務層進行拆分。

服務層架構如何細分？

垂直拆分是個好的方案，將子業務分拆，那么微信的服務化架構或許會變成下面的樣子：

• 用戶相關的子業務，訪問user服務

• 好友相關的子業務，訪問friend服務

• 群組相關的子業務，訪問group服務

• 消息相關的子業務，訪問msg服務

這樣的話，一個服務出問題也不會影響其他服務，與此同時，數據層也按照業務垂直拆分開了。

服務粒度變細之后，出現一個新的問題，業務與服務的連接關系變復雜了，有什么好的優化方案么？

常見的，加入一個高可用服務分發層（Service Mesh不就是這么干的么），并在協議設計時加入服務號，可以減少蜘蛛網狀的依賴關系：

• 調用方依賴分發層，傳入服務號

• 分發層依賴服務層，通過服務號參數分發

實踐三：一個數據庫對應一個服務

數據訪問服務最初是從DAO/ORM的數據訪問需求過來的，所以有些公司也有一個數據庫一個服務的玩法。

一個子業務對應一個服務的玩法如下圖：

• 服務層，整個群業務是一個服務

• 存儲層，實際可能對應了群信息、群成員、群消息等多個數據表

拆分成一個數據庫一個服務，則架構會變成下面的樣子：

群信息庫，群成員庫，群消息庫之間也解耦開，不會相互影響。

實踐四，一個接口對應一個服務

微服務架構中，更極端的，甚至一個接口對應一個微服務。

這樣的話，架構就從：

進化為：

• 修改群信息服務

• 增加群信息服務

• 獲取群信息服務

多個服務操縱同一個數據庫，任何接口服務出問題，都不會影響其他接口服務。使用這種方案的，一般與開發語言特性結合比較緊密，例如golang。

上文中談到的服務化與微服務，不同粒度的服務化各有什么優劣呢？

總的來說，細粒度拆分的優點有：

• 服務都能夠獨立部署

• 擴容和縮容方便，有利于提高資源利用率

• 拆得越細，耦合相對會減小

• 拆得越細，容錯相對會更好，一個服務出問題不影響其他服務

• 擴展性更好

細粒度拆分的不足也很明顯：

• 拆得越細，系統越復雜

• 系統之間的依賴關系也更復雜

• 運維復雜度提升

• 監控更加復雜

• 出問題時定位問題更難

互聯公司，以“子業務”作為微服務粒度是最常用，訂單服務，用戶服務，支付服務等等。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的微服务架构，多“微”才合适？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。