微服務(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ù)雜度的增長(zhǎng),互聯(lián)網(wǎng)架構(gòu)會(huì)出現(xiàn)以下問題:
(1)代碼到處拷貝
(2)底層復(fù)雜性擴(kuò)散
(3)基礎(chǔ)庫(kù)(so/jar/dll)耦合
(4)SQL質(zhì)量得不到保障,業(yè)務(wù)相互影響
(5)數(shù)據(jù)庫(kù)耦合
“服務(wù)化”是一個(gè)很好的解決上述痛點(diǎn)的方案。
不少評(píng)論也提出了不少有建設(shè)性的觀點(diǎn),匯總出來分享給大伙:
@田衛(wèi) 同學(xué)提到:
服務(wù)化之后,可能會(huì)引發(fā)分布式事務(wù)的問題,“沒人愿意引入分布式事務(wù),當(dāng)基于業(yè)務(wù)水平拆分的時(shí)候,要業(yè)務(wù)專家介入,合理拆分服務(wù)化,以后就服務(wù)內(nèi)高內(nèi)聚,事務(wù)可以保證,對(duì)于夸服務(wù)調(diào)用,通過補(bǔ)償?shù)仁侄?,只要最終一致性就行,畢竟連現(xiàn)在的銀行轉(zhuǎn)賬都不是強(qiáng)一致性。”
如@田衛(wèi)所說,分布式事務(wù)是業(yè)界沒有徹底解決的難題,任何架構(gòu)設(shè)計(jì)都是一個(gè)折衷,吞吐量?時(shí)延?一致性?哪個(gè)是主要矛盾,優(yōu)先解決哪個(gè)問題。大數(shù)據(jù)、高并發(fā)、業(yè)務(wù)復(fù)雜性是主要矛盾的時(shí)候,或許“最終一致性”是一個(gè)替代“事務(wù)”更好的,或者說業(yè)務(wù)能夠接受的方案。
@侯滇滇 同學(xué)提到:
多了一層服務(wù)層,架構(gòu)實(shí)際上是更復(fù)雜了,需要引入一系列機(jī)制對(duì)服務(wù)進(jìn)行管理,RPC服務(wù)化中需要注意:
(1)RPC服務(wù)超時(shí),服務(wù)調(diào)用者應(yīng)有一些應(yīng)對(duì)策略,比如重發(fā)
(2)關(guān)鍵服務(wù)例如支付,要注意冪等性,因?yàn)橹匕l(fā)會(huì)導(dǎo)致重復(fù)操作
(3)多服務(wù)要考慮并發(fā)操作,相當(dāng)單服務(wù)的鎖機(jī)制比如JAVA中的synchronized
@黃明 同學(xué)提到:
服務(wù)化之后,隨著規(guī)模的擴(kuò)大,一定要考慮“服務(wù)治理”,否則服務(wù)之間的依賴關(guān)系會(huì)亂成麻
二、互聯(lián)網(wǎng)微服務(wù)架構(gòu)多“微”才適合
大家也都認(rèn)可,隨著數(shù)據(jù)量、流量、業(yè)務(wù)復(fù)雜度的提升,服務(wù)化架構(gòu)是架構(gòu)演進(jìn)中的必由之路,今天要討論的話題是:微服務(wù)架構(gòu)多“微”才合適?
【粗粒度:一個(gè)服務(wù)層】

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

有一個(gè)統(tǒng)一的service層,用戶信息,好友信息,群組信息,消息信息都通過這個(gè)service層來走。
細(xì)節(jié):微信單對(duì)單消息是一個(gè)寫多讀少的業(yè)務(wù),故沒有緩存。
【一個(gè)子業(yè)務(wù)一個(gè)service】
如果所有的信息存儲(chǔ)都在一個(gè)service里,那么一個(gè)地方出bug,就將影響整個(gè)業(yè)務(wù),所以更合理的做法是在服務(wù)層進(jìn)行細(xì)分,架構(gòu)如何細(xì)分?垂直拆分是個(gè)好的方案,將子業(yè)務(wù)一個(gè)個(gè)拆出來,那么微信的服務(wù)化架構(gòu)或許會(huì)變成這個(gè)樣子:

(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
這樣的話,一個(gè)service出問題也不會(huì)影響其他service,同時(shí)數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開了。
服務(wù)粒度變細(xì)之后,出現(xiàn)一個(gè)新的問題,業(yè)務(wù)與服務(wù)的連接關(guān)系變復(fù)雜了,有什么好的優(yōu)化方案么?

常見的,加入一個(gè)高可用服務(wù)分發(fā)層集群,并在協(xié)議設(shè)計(jì)時(shí)加入服務(wù)號(hào),可以減少蜘蛛網(wǎng)狀的依賴關(guān)系:
(1)調(diào)用方依賴分發(fā)層,傳入服務(wù)號(hào)
(2)分發(fā)層依賴服務(wù)層,通過服務(wù)號(hào)參數(shù)分發(fā)
【一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)service】
數(shù)據(jù)訪問service最初是從DAO/ORM的數(shù)據(jù)訪問需求過來的,所以有些公司也有一個(gè)數(shù)據(jù)表一個(gè)service的玩法。
一個(gè)子業(yè)務(wù)對(duì)應(yīng)一個(gè)service的玩法是:

(1)服務(wù)層,整個(gè)群業(yè)務(wù)是一個(gè)service
(2)存儲(chǔ)層,實(shí)際可能對(duì)應(yīng)了群信息、群成員、群消息等多個(gè)數(shù)據(jù)表
拆分成一個(gè)數(shù)據(jù)表一個(gè)service,則架構(gòu)會(huì)變成這樣:

群信息表,群成員表,群消息表等各個(gè)數(shù)據(jù)表之間也解耦開了,不會(huì)相互影響了。
【一個(gè)接口對(duì)應(yīng)一個(gè)service】
微服務(wù)架構(gòu)中更極端的,甚至一個(gè)接口對(duì)應(yīng)一個(gè)微服務(wù),這樣的話,架構(gòu)就從:

演化為:

(1)修改群信息服務(wù)
(2)增加群信息服務(wù)
(3)獲取群信息服務(wù)
多個(gè)服務(wù)操縱同一個(gè)數(shù)據(jù)表,使用同一片緩存,每個(gè)接口出問題,都不會(huì)影響其他接口。
三、粒度粗細(xì)的優(yōu)劣
上文中談到的服務(wù)化與微服務(wù),不同粒度的服務(wù)化各有什么優(yōu)劣呢?
總的來說,細(xì)粒度拆分的優(yōu)點(diǎn)有:
(1)服務(wù)都能夠獨(dú)立部署
(2)擴(kuò)容和縮容方便,有利于提高資源利用率
(3)拆得越細(xì),耦合相對(duì)會(huì)減小
(4)拆得越細(xì),容錯(cuò)相對(duì)會(huì)更好,一個(gè)服務(wù)出問題不影響其他服務(wù)
(5)擴(kuò)展性更好
(6)…
細(xì)粒度拆分的不足也很明顯:
(1)拆得越細(xì),系統(tǒng)越復(fù)雜
(2)系統(tǒng)之間的依賴關(guān)系也更復(fù)雜
(3)運(yùn)維復(fù)雜度提升
(4)監(jiān)控更加復(fù)雜
(5)出問題時(shí)定位問題更難
(6)…
關(guān)于微服務(wù)架構(gòu)的“粒度”問題,以及各粒度的優(yōu)劣,大伙有什么好的看法,歡迎補(bǔ)充,建設(shè)性的意見將在后續(xù)文中和大伙share。
四、結(jié)束的話
聊了許多,有網(wǎng)友問,筆者對(duì)待服務(wù)化以及微服務(wù)粒度的看法,個(gè)人覺得,以“子業(yè)務(wù)系統(tǒng)”粒度作為微服務(wù)的單位是比較合適的:

末了,討論完微服務(wù)架構(gòu)的粒度,后續(xù)文章和大家聊一聊微服務(wù)的***實(shí)踐,需要什么樣的框架、組件、技術(shù)能夠?qū)⒎?wù)化在較短的時(shí)間內(nèi)開展起來,下面和大伙再聊。
文章轉(zhuǎn)載自微信公眾號(hào)“架構(gòu)師之路”