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