一、互聯(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)以下問(wèn)題：

（1）代碼到處拷貝

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

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

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

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

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

服務(wù)化之后，可能會(huì)引發(fā)分布式事務(wù)的問(wèn)題，“沒(méi)人愿意引入分布式事務(wù)，當(dāng)基于業(yè)務(wù)水平拆分的時(shí)候，要業(yè)務(wù)專家介入，合理拆分服務(wù)化，以后就服務(wù)內(nèi)高內(nèi)聚，事務(wù)可以保證，對(duì)于夸服務(wù)調(diào)用，通過(guò)補(bǔ)償?shù)仁侄?，只要最終一致性就行，畢竟連現(xiàn)在的銀行轉(zhuǎn)賬都不是強(qiáng)一致性。”

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

多了一層服務(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

二、互聯(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ù)的訪問(wèn)，都通過(guò)一個(gè)service訪問(wèn)，在業(yè)務(wù)不是特別復(fù)雜的時(shí)候還好，一旦業(yè)務(wù)變復(fù)雜了，這個(gè)service層會(huì)變得非常重，成為耦合點(diǎn)之一，以微信場(chǎng)景為例，假設(shè)有一個(gè)通用的服務(wù)層來(lái)訪問(wèn)基礎(chǔ)數(shù)據(jù)，這個(gè)服務(wù)層可能是這樣的：

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

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

【一個(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è)拆出來(lái)，那么微信的服務(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出問(wèn)題也不會(huì)影響其他service，同時(shí)數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開了。

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

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

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

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

【一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)service】

數(shù)據(jù)訪問(wèn)service最初是從DAO/ORM的數(shù)據(jù)訪問(wèn)需求過(guò)來(lái)的，所以有些公司也有一個(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è)接口出問(wèn)題，都不會(huì)影響其他接口。

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

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

總的來(lái)說(shuō)，細(xì)粒度拆分的優(yōu)點(diǎn)有：

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

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

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

（4）拆得越細(xì)，容錯(cuò)相對(duì)會(huì)更好，一個(gè)服務(wù)出問(wèn)題不影響其他服務(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）出問(wèn)題時(shí)定位問(wèn)題更難

（6）…

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

四、結(jié)束的話

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

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