微服務(wù)架構(gòu)多“微”才合適？

前情提要：互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化？

一、互聯(lián)網(wǎng)架構(gòu)為什么要進(jìn)行服務(wù)化-總結(jié)

---

上一篇和大伙交流了一下，隨著數(shù)據(jù)量、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長，互聯(lián)網(wǎng)架構(gòu)會出現(xiàn)以下問題：

（1）代碼到處拷貝

（2）底層復(fù)雜性擴(kuò)散

（3）基礎(chǔ)庫（so/jar/dll）耦合

（4）SQL質(zhì)量得不到保障，業(yè)務(wù)相互影響

（5）數(shù)據(jù)庫耦合

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

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

@田衛(wèi) 同學(xué)提到：

服務(wù)化之后，可能會引發(fā)分布式事務(wù)的問題，“沒人愿意引入分布式事務(wù)，當(dāng)基于業(yè)務(wù)水平拆分的時候，要業(yè)務(wù)專家介入，合理拆分服務(wù)化，以后就服務(wù)內(nèi)高內(nèi)聚，事務(wù)可以保證，對于夸服務(wù)調(diào)用，通過補償?shù)仁侄危灰罱K一致性就行，畢竟連現(xiàn)在的銀行轉(zhuǎn)賬都不是強一致性?！?/span>

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

@侯滇滇 同學(xué)提到：

多了一層服務(wù)層，架構(gòu)實際上是更復(fù)雜了，需要引入一系列機制對服務(wù)進(jìn)行管理，RPC服務(wù)化中需要注意：

（1）RPC服務(wù)超時，服務(wù)調(diào)用者應(yīng)有一些應(yīng)對策略，比如重發(fā)

（2）關(guān)鍵服務(wù)例如支付，要注意冪等性，因為重發(fā)會導(dǎo)致重復(fù)操作

（3）多服務(wù)要考慮并發(fā)操作，相當(dāng)單服務(wù)的鎖機制比如JAVA中的synchronized

@黃明 同學(xué)提到：

服務(wù)化之后，隨著規(guī)模的擴(kuò)大，一定要考慮“服務(wù)治理”，否則服務(wù)之間的依賴關(guān)系會亂成麻

二、互聯(lián)網(wǎng)微服務(wù)架構(gòu)多“微”才適合

---

大家也都認(rèn)可，隨著數(shù)據(jù)量、流量、業(yè)務(wù)復(fù)雜度的提升，服務(wù)化架構(gòu)是架構(gòu)演進(jìn)中的必由之路，今天要討論的話題是：微服務(wù)架構(gòu)多“微”才合適？

【粗粒度：一個服務(wù)層】

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

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

細(xì)節(jié)：微信單對單消息是一個寫多讀少的業(yè)務(wù)，故沒有緩存。

【一個子業(yè)務(wù)一個service】

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

（1）用戶相關(guān)的子業(yè)務(wù)有user-service

（2）好友相關(guān)的子業(yè)務(wù)有friend-service

（3）群組相關(guān)的子業(yè)務(wù)有g(shù)roup-service

（4）消息相關(guān)的子業(yè)務(wù)有msg-service

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

服務(wù)粒度變細(xì)之后，出現(xiàn)一個新的問題，業(yè)務(wù)與服務(wù)的連接關(guān)系變復(fù)雜了，有什么好的優(yōu)化方案么？

常見的，加入一個高可用服務(wù)分發(fā)層集群，并在協(xié)議設(shè)計時加入服務(wù)號，可以減少蜘蛛網(wǎng)狀的依賴關(guān)系：

（1）調(diào)用方依賴分發(fā)層，傳入服務(wù)號

（2）分發(fā)層依賴服務(wù)層，通過服務(wù)號參數(shù)分發(fā)

【一個數(shù)據(jù)庫對應(yīng)一個service】

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

一個子業(yè)務(wù)對應(yīng)一個service的玩法是：

（1）服務(wù)層，整個群業(yè)務(wù)是一個service

（2）存儲層，實際可能對應(yīng)了群信息、群成員、群消息等多個數(shù)據(jù)表

拆分成一個數(shù)據(jù)表一個service，則架構(gòu)會變成這樣：

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

【一個接口對應(yīng)一個service】

微服務(wù)架構(gòu)中更極端的，甚至一個接口對應(yīng)一個微服務(wù)，這樣的話，架構(gòu)就從：

演化為：

（1）修改群信息服務(wù)

（2）增加群信息服務(wù)

（3）獲取群信息服務(wù)

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

三、粒度粗細(xì)的優(yōu)劣

---

上文中談到的服務(wù)化與微服務(wù)，不同粒度的服務(wù)化各有什么優(yōu)劣呢？

總的來說，細(xì)粒度拆分的優(yōu)點有：

（1）服務(wù)都能夠獨立部署

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

（3）拆得越細(xì)，耦合相對會減小

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

（5）擴(kuò)展性更好

（6）…

細(xì)粒度拆分的不足也很明顯：

（1）拆得越細(xì)，系統(tǒng)越復(fù)雜

（2）系統(tǒng)之間的依賴關(guān)系也更復(fù)雜

（3）運維復(fù)雜度提升

（4）監(jiān)控更加復(fù)雜

（5）出問題時定位問題更難

（6）…

關(guān)于微服務(wù)架構(gòu)的“粒度”問題，以及各粒度的優(yōu)劣，大伙有什么好的看法，歡迎補充，建設(shè)性的意見將在后續(xù)文中和大伙share。

四、結(jié)束的話

---

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

末了，討論完微服務(wù)架構(gòu)的粒度，后續(xù)文章和大家聊一聊微服務(wù)的最佳實踐，需要什么樣的框架、組件、技術(shù)能夠?qū)⒎?wù)化在較短的時間內(nèi)開展起來，下周和大伙再聊。