前情提要：互聯網架構為什么要做服務化?

一、互聯網架構為什么要進行服務化-總結

上一篇和大伙交流了一下，隨著數據量、并發量、業務復雜度的增長，互聯網架構會出現以下問題：

(1)代碼到處拷貝

(2)底層復雜性擴散

(3)基礎庫(so/jar/dll)耦合

(4)SQL質量得不到保障，業務相互影響

(5)數據庫耦合

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

不少評論也提出了不少有建設性的觀點，匯總出來分享給大伙：

@田衛 同學提到：

服務化之后，可能會引發分布式事務的問題，“沒人愿意引入分布式事務，當基于業務水平拆分的時候，要業務專家介入，合理拆分服務化，以后就服務內高內聚，事務可以保證，對于夸服務調用，通過補償等手段，只要最終一致性就行，畢竟連現在的銀行轉賬都不是強一致性。”

如@田衛所說，分布式事務是業界沒有徹底解決的難題，任何架構設計都是一個折衷，吞吐量?時延?一致性?哪個是主要矛盾，優先解決哪個問題。大數據、高并發、業務復雜性是主要矛盾的時候，或許“最終一致性”是一個替代“事務”更好的，或者說業務能夠接受的方案。

@侯滇滇 同學提到：

多了一層服務層，架構實際上是更復雜了，需要引入一系列機制對服務進行管理，RPC服務化中需要注意：

(1)RPC服務超時，服務調用者應有一些應對策略，比如重發

(2)關鍵服務例如支付，要注意冪等性，因為重發會導致重復操作

(3)多服務要考慮并發操作，相當單服務的鎖機制比如JAVA中的synchronized

@黃明 同學提到：

服務化之后，隨著規模的擴大，一定要考慮“服務治理”，否則服務之間的依賴關系會亂成麻

二、互聯網微服務架構多“微”才適合

大家也都認可，隨著數據量、流量、業務復雜度的提升，服務化架構是架構演進中的必由之路，今天要討論的話題是：微服務架構多“微”才合適?

【粗粒度：一個服務層】

 

 

最粗獷的玩法，所有基礎數據的訪問，都通過一個service訪問，在業務不是特別復雜的時候還好，一旦業務變復雜了，這個service層會變得非常重，成為耦合點之一，以微信場景為例，假設有一個通用的服務層來訪問基礎數據，這個服務層可能是這樣的：

 

 

有一個統一的service層，用戶信息，好友信息，群組信息，消息信息都通過這個service層來走。

細節：微信單對單消息是一個寫多讀少的業務，故沒有緩存。

【一個子業務一個service】

如果所有的信息存儲都在一個service里，那么一個地方出bug，就將影響整個業務，所以更合理的做法是在服務層進行細分，架構如何細分?垂直拆分是個好的方案，將子業務一個個拆出來，那么微信的服務化架構或許會變成這個樣子：

 

 

(1)用戶相關的子業務有user-service

(2)好友相關的子業務有friend-service

(3)群組相關的子業務有group-service

(4)消息相關的子業務有msg-service

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

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

 

 

常見的，加入一個高可用服務分發層集群，并在協議設計時加入服務號，可以減少蜘蛛網狀的依賴關系：

(1)調用方依賴分發層，傳入服務號

(2)分發層依賴服務層，通過服務號參數分發

【一個數據庫對應一個service】

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

一個子業務對應一個service的玩法是：

 

 

(1)服務層，整個群業務是一個service

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

拆分成一個數據表一個service，則架構會變成這樣：

 

 

群信息表，群成員表，群消息表等各個數據表之間也解耦開了，不會相互影響了。

【一個接口對應一個service】

微服務架構中更極端的，甚至一個接口對應一個微服務，這樣的話，架構就從：

 

 

演化為：

(1)修改群信息服務

 

(2)增加群信息服務

(3)獲取群信息服務

多個服務操縱同一個數據表，使用同一片緩存，每個接口出問題，都不會影響其他接口。

三、粒度粗細的優劣

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

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

(1)服務都能夠獨立部署

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

(3)拆得越細，耦合相對會減小

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

(5)擴展性更好

(6)…

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

(1)拆得越細，系統越復雜

(2)系統之間的依賴關系也更復雜

(3)運維復雜度提升

(4)監控更加復雜

(5)出問題時定位問題更難

(6)…

關于微服務架構的“粒度”問題，以及各粒度的優劣，大伙有什么好的看法，歡迎補充，建設性的意見將在后續文中和大伙share。

四、結束的話

聊了許多，有網友問，筆者對待服務化以及微服務粒度的看法，個人覺得，以“子業務系統”粒度作為微服務的單位是比較合適的：

 

 

末了，討論完微服務架構的粒度，后續文章和大家聊一聊微服務的***實踐，需要什么樣的框架、組件、技術能夠將服務化在較短的時間內開展起來，下面和大伙再聊。

文章轉載自微信公眾號“架構師之路”