前情提要：互聯(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)會(huì)出現(xiàn)以下問題：

（1）代碼到處拷貝

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

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

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

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

“服務(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)一致性?！?/span>

如@田衛(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ù)有group-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ù)庫對(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)開展起來，下周和大伙再聊,。

==【完】==

回【無鎖】如何實(shí)現(xiàn)超高并發(fā)的無鎖緩存,？

回【消息】58到家通用實(shí)時(shí)消息平臺(tái)架構(gòu)細(xì)節(jié)

回【機(jī)房】從IDC到云端架構(gòu)遷移之路

回【設(shè)置】線程數(shù)究竟設(shè)多少合理

回【單點(diǎn)】單點(diǎn)系統(tǒng)架構(gòu)的可用性與性能優(yōu)化

回【事務(wù)】多庫多事務(wù)降低數(shù)據(jù)不一致概率

回【服務(wù)】互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化？

【小游戲：回大于10的整數(shù),，隨機(jī)返回好文,，猜猜怎么實(shí)現(xiàn)的】

歡迎討論，有問必答,。