隨著數(shù)據(jù)量、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長，互聯(lián)網(wǎng)架構(gòu)會出現(xiàn)以下問題：

創(chuàng)新互聯(lián)主要從事成都做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)工布江達(dá),10多年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

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

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

那么問題來了，微服務(wù)架構(gòu)多“微”才合適?

行業(yè)內(nèi)有這樣四類常見實踐。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實踐三：一個數(shù)據(jù)庫對應(yīng)一個服務(wù)

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

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

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

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

群信息庫，群成員庫，群消息庫之間也解耦開，不會相互影響。

實踐四，一個接口對應(yīng)一個服務(wù)

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

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

進化為：

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

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

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

總的來說，細(xì)粒度拆分的優(yōu)點有：

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

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

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

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

當(dāng)前標(biāo)題：微服務(wù)架構(gòu)，多“微”才合適？
文章位置：http://uogjgqi.cn/article/dhegehs.html