以前的文章讨論過《網際網路架構，究竟為啥要做服務化？》，随着資料量、并發量、業務複雜度的增長，網際網路架構會出現以下問題：
- 代碼到處拷貝
- 底層複雜性擴散
- 基礎庫（so/jar/dll）耦合
- SQL品質得不到保障，業務互相影響
- 資料庫耦合
“服務化”是一個很好的解決上述痛點的方案。
那麼問題來了，微服務架構多“微”才合适？
行業内有這樣四類常見實踐。
實踐一：統一服務層
這是最粗犷的玩法，所有基礎資料，都通過一個統一的服務來進行通路。
在業務不是特别複雜的時候，這不失為一個快速分層的方案，一旦業務變得複雜，服務層會變得非常重，成為耦合焦點。
以微信場景為例，假設通過一個通用的服務層來通路基礎資料。
則隻有一個統一的服務層，使用者資訊，好友資訊，群組資訊，消息資訊都通過這個服務層來通路。
實踐二：一個子業務一個服務
如果所有的資料通路都通過一個服務層來通路，那麼一行代碼出故障，就将影響整個服務，是以更合理的做法是在服務層進行拆分。
服務層架構如何細分？
垂直拆分是個好的方案，将子業務分拆，那麼微信的服務化架構或許會變成下面的樣子：
- 使用者相關的子業務，通路user服務
- 好友相關的子業務，通路friend服務
- 群組相關的子業務，通路group服務
- 消息相關的子業務，通路msg服務
這樣的話，一個服務出問題也不會影響其他服務，與此同時，資料層也按照業務垂直拆分開了。
服務粒度變細之後，出現一個新的問題，業務與服務的連接配接關系變複雜了，有什麼好的優化方案麼？
常見的，加入一個高可用服務分發層（Service Mesh不就是這麼幹的麼），并在協定設計時加入服務号，可以減少蜘蛛網狀的依賴關系：
- 調用方依賴分發層，傳入服務号
- 分發層依賴服務層，通過服務号參數分發
實踐三：一個資料庫對應一個服務
資料通路服務最初是從DAO/ORM的資料通路需求過來的，是以有些公司也有一個資料庫一個服務的玩法。
一個子業務對應一個服務的玩法如下圖：
服務層，整個群業務是一個服務
存儲層，實際可能對應了群資訊、群成員、群消息等多個資料表
拆分成一個資料庫一個服務，則架構會變成下面的樣子：
群資訊庫，群成員庫，群消息庫之間也解耦開，不會互相影響。
實踐四，一個接口對應一個服務
微服務架構中，更極端的，甚至一個接口對應一個微服務。
這樣的話，架構就從：
進化為：
- 修改群資訊服務
- 增加群資訊服務
- 擷取群資訊服務
多個服務操縱同一個資料庫，任何接口服務出問題，都不會影響其他接口服務。使用這種方案的，一般與開發語言特性結合比較緊密，例如golang。
上文中談到的服務化與微服務，不同粒度的服務化各有什麼優劣呢？
總的來說，細粒度拆分的優點有：
- 服務都能夠獨立部署
- 擴容和縮容友善，有利于提高資源使用率
- 拆得越細，耦合相對會減小
- 拆得越細，容錯相對會更好，一個服務出問題不影響其他服務
- 擴充性更好
細粒度拆分的不足也很明顯：
- 拆得越細，系統越複雜
- 系統之間的依賴關系也更複雜
- 運維複雜度提升
- 監控更加複雜
- 出問題時定位問題更難
互聯公司，以“子業務”作為微服務粒度是最常用，訂單服務，使用者服務，支付服務等等。
架構師之路-分享技術思路