《微服務(wù)架構(gòu)的六大好處》中提到，隨著數(shù)據(jù)量、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長(zhǎng)，互聯(lián)網(wǎng)架構(gòu)會(huì)出現(xiàn)以下問(wèn)題：

• 代碼到處拷貝；
• 底層復(fù)雜性擴(kuò)散；
• 基礎(chǔ)庫(kù)（so/jar/dll）耦合；
• SQL質(zhì)量得不到保障，業(yè)務(wù)相互影響；
• 數(shù)據(jù)庫(kù)耦合；

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

又有童鞋問(wèn)我說(shuō)，那微服務(wù)架構(gòu)多“微”才合適？

一般有這樣四類(lèi)實(shí)踐。

實(shí)踐一：統(tǒng)一服務(wù)層。

這是最粗獷的玩法，所有基礎(chǔ)數(shù)據(jù)，都通過(guò)一個(gè)統(tǒng)一的服務(wù)來(lái)進(jìn)行訪問(wèn)。

在業(yè)務(wù)不是特別復(fù)雜的時(shí)候，這不失為一個(gè)快速分層的方案，一旦業(yè)務(wù)變得復(fù)雜，服務(wù)層會(huì)變得非常重，成為耦合焦點(diǎn)。

以微信場(chǎng)景為例，假設(shè)通過(guò)一個(gè)通用的服務(wù)層來(lái)訪問(wèn)基礎(chǔ)數(shù)據(jù)。

則只有一個(gè)統(tǒng)一的服務(wù)層，用戶信息，好友信息，群組信息，消息信息都通過(guò)這個(gè)服務(wù)層來(lái)訪問(wèn)。

實(shí)踐二：一個(gè)子業(yè)務(wù)一個(gè)服務(wù)。

如果所有的數(shù)據(jù)訪問(wèn)都通過(guò)一個(gè)服務(wù)層來(lái)訪問(wèn)，那么一行代碼出故障，就將影響整個(gè)服務(wù)，所以更合理的做法是在服務(wù)層進(jìn)行拆分。

服務(wù)層架構(gòu)如何細(xì)分？

垂直拆分是個(gè)好的方案，將子業(yè)務(wù)分拆，那么微信的服務(wù)化架構(gòu)或許會(huì)變成下面的樣子：

• 用戶相關(guān)的子業(yè)務(wù)，訪問(wèn)user服務(wù)；
• 好友相關(guān)的子業(yè)務(wù)，訪問(wèn)friend服務(wù)；
• 群組相關(guān)的子業(yè)務(wù)，訪問(wèn)group服務(wù)；
• 消息相關(guān)的子業(yè)務(wù)，訪問(wèn)msg服務(wù)；

這樣的話，一個(gè)服務(wù)出問(wèn)題也不會(huì)影響其他服務(wù)，與此同時(shí)，數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開(kāi)了。

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

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

• 調(diào)用方依賴(lài)分發(fā)層，傳入服務(wù)號(hào)；
• 分發(fā)層依賴(lài)服務(wù)層，通過(guò)服務(wù)號(hào)參數(shù)分發(fā)；

實(shí)踐三：一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)服務(wù)。

數(shù)據(jù)訪問(wèn)服務(wù)最初是從DAO/ORM的數(shù)據(jù)訪問(wèn)需求過(guò)來(lái)的，所以有些公司也有一個(gè)數(shù)據(jù)庫(kù)一個(gè)服務(wù)的玩法。

一個(gè)子業(yè)務(wù)對(duì)應(yīng)一個(gè)服務(wù)的玩法如下圖：

• 服務(wù)層，整個(gè)群業(yè)務(wù)是一個(gè)服務(wù)；
• 存儲(chǔ)層，實(shí)際可能對(duì)應(yīng)了群信息、群成員、群消息等多個(gè)數(shù)據(jù)表；

拆分成一個(gè)數(shù)據(jù)庫(kù)一個(gè)服務(wù)，則架構(gòu)會(huì)變成下面的樣子：

群信息庫(kù)，群成員庫(kù)，群消息庫(kù)之間也解耦開(kāi)，不會(huì)相互影響。

實(shí)踐四，一個(gè)接口對(duì)應(yīng)一個(gè)服務(wù)。

微服務(wù)架構(gòu)中，更極端的，甚至一個(gè)接口對(duì)應(yīng)一個(gè)微服務(wù)。

這樣的話，架構(gòu)就從：

進(jìn)化為：

• 修改群信息服務(wù)；
• 增加群信息服務(wù)；
• 獲取群信息服務(wù)；

多個(gè)服務(wù)操縱同一個(gè)數(shù)據(jù)庫(kù)，任何接口服務(wù)出問(wèn)題，都不會(huì)影響其他接口服務(wù)。使用這種方案的，一般與開(kāi)發(fā)語(yǔ)言特性結(jié)合比較緊密，例如golang。

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

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

• 服務(wù)都能夠獨(dú)立部署；
• 擴(kuò)容和縮容方便，有利于提高資源利用率；
• 拆得越細(xì)，耦合相對(duì)會(huì)減小；
• 拆得越細(xì)，容錯(cuò)相對(duì)會(huì)更好，一個(gè)服務(wù)出問(wèn)題不影響其他服務(wù)；
• 擴(kuò)展性更好；

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

• 拆得越細(xì)，系統(tǒng)越復(fù)雜；
• 系統(tǒng)之間的依賴(lài)關(guān)系也更復(fù)雜；
• 運(yùn)維復(fù)雜度提升；
• 監(jiān)控更加復(fù)雜；
• 出問(wèn)題時(shí)定位問(wèn)題更難；

互聯(lián)公司，以“子業(yè)務(wù)”作為微服務(wù)粒度是最常用，訂單服務(wù)，用戶服務(wù)，支付服務(wù)等等。

知其然，知其所以然。

思路比結(jié)論更重要。