聊聊這個(gè)有趣的話題：分布式單體

這是一個(gè)或許對(duì)你有用的開源項(xiàng)目

國(guó)產(chǎn) Star 破 10w+ 的開源項(xiàng)目，前端包括管理后臺(tái) + 微信小程序，后端支持單體和微服務(wù)架構(gòu)。

功能涵蓋 RBAC 權(quán)限、SaaS 多租戶、數(shù)據(jù)權(quán)限、商城、支付、工作流、大屏報(bào)表、微信公眾號(hào)等等功能：

Boot 地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

Cloud 地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn

分布式單體為什么不好

改造走樣的元兇

1. 領(lǐng)域拆分的不合理，引出了過(guò)多的同步遠(yuǎn)程調(diào)用

2. 簡(jiǎn)單粗暴的實(shí)現(xiàn)，缺少分布式的保護(hù)機(jī)制

昨晚睡覺(jué)前，順手?jǐn)]了幾個(gè)群聊的聊天記錄。發(fā)現(xiàn)一個(gè)很有意思的名詞“分布式單體 ”，順藤摸瓜看了一下之前的聊天記錄，由于內(nèi)容罵罵咧咧，我就不貼出來(lái)了。大致內(nèi)容就是某公司在做微服務(wù)改造，但改的不倫不類，形式上像微服務(wù)，而本質(zhì)上依然是單體，甚至連單體都不如。

這樣的改造現(xiàn)象，其實(shí)在國(guó)內(nèi)還是蠻多見的。今天我們就來(lái)聊聊這個(gè)有趣的話題：分布式單體 。各位看官，看看你們公司是不是也犯了這樣的錯(cuò)誤？

分布式單體為什么不好

先思考一個(gè)問(wèn)題：從單體改造到微服務(wù)的時(shí)候，你們是不是按這樣的步驟來(lái)的？

確定業(yè)務(wù)領(lǐng)域，拆分存儲(chǔ)，定義各微服務(wù)的邊界

改造代碼邏輯，將原來(lái)的內(nèi)部service調(diào)用改成dubbo或feign這樣的遠(yuǎn)程調(diào)用

通過(guò)這樣的改造，我們得到了很多好處，比如：

代碼庫(kù)分開了，減少了麻煩的解決代碼沖突的困擾

CI/CD分開了，每個(gè)拆分后的服務(wù)都可以獨(dú)立開發(fā)、部署、運(yùn)行

數(shù)據(jù)庫(kù)分開了，獨(dú)立運(yùn)行，不同業(yè)務(wù)模塊不會(huì)互相影響

這樣一頓操作，我們把一個(gè)臃腫的單體應(yīng)用變成了多個(gè)精煉的分布式應(yīng)用，似乎完美的實(shí)現(xiàn)了改造？但這樣就實(shí)現(xiàn)了微服務(wù)的核心目標(biāo)了嗎？繼續(xù)思考下面的問(wèn)題：

代碼庫(kù)是分開了，但每個(gè)服務(wù)都在獨(dú)立迭代嗎？是不是每個(gè)需求都要協(xié)調(diào)一大堆同步接口？

CI/CD是分開了，但每次發(fā)布都是自由的嗎？是不是每次功能的發(fā)布都拖上了一大推的服務(wù)要一起發(fā)布？

數(shù)據(jù)庫(kù)是分開了，但似乎有個(gè)服務(wù)掛了，依然導(dǎo)致很多功能就都不正常了？

看似我們得到了很多好處，但我們的開發(fā)效率真的得到了提升嗎？雖然我們以前一個(gè)單體應(yīng)用啟動(dòng)要3分鐘，現(xiàn)在拆分后，一個(gè)項(xiàng)目啟動(dòng)30秒，但每次開發(fā)調(diào)試要同時(shí)開好幾個(gè)項(xiàng)目同時(shí)啟動(dòng)？這樣的開發(fā)體驗(yàn)真的爽到了嗎？

看似完成了微服務(wù)改造，實(shí)則依然是個(gè)單體應(yīng)用，只是從原本的集中式實(shí)現(xiàn)，變成是分布式實(shí)現(xiàn)。原來(lái)我們只是做了一次無(wú)用功，真正的收益微乎其微。

而實(shí)際上，這樣的改造，除了收益不高之外，還帶出了更多的壞處。如果你們公司是這樣做的，有沒(méi)有發(fā)現(xiàn)，這樣做之后，好像系統(tǒng)故障的頻率更高了？穩(wěn)定性似乎比單體應(yīng)用還差？（如果沒(méi)有，那一定要感謝你們的運(yùn)維團(tuán)隊(duì)真的很給力，同時(shí)建議把這篇轉(zhuǎn)給運(yùn)維團(tuán)隊(duì)，采訪下這樣的改造是不是他們變得更累了？！）

為什么這樣的改造會(huì)導(dǎo)致系統(tǒng)更加不穩(wěn)定呢？其實(shí)道理很簡(jiǎn)單，原本我們?cè)趩误w應(yīng)用中，未拆分的遠(yuǎn)程調(diào)用都是內(nèi)部調(diào)用，這個(gè)內(nèi)部調(diào)用所能引發(fā)的故障率是微乎其微的，而將這部分內(nèi)容拆成了遠(yuǎn)程調(diào)用后，每一個(gè)調(diào)用都增加了網(wǎng)絡(luò)IO的因素，每一次調(diào)用的故障率都增加了。那么系統(tǒng)的整體故障率是隨著系統(tǒng)擁有多少同步遠(yuǎn)程調(diào)用的數(shù)量增加而增加的。當(dāng)運(yùn)維團(tuán)隊(duì)與開發(fā)水平?jīng)]有支持好這部分增加的復(fù)雜度時(shí)，那么改造的系統(tǒng)，必然穩(wěn)定性會(huì)比原來(lái)的單體應(yīng)用更差。

所以，這樣改造的結(jié)果，不但沒(méi)有得到很多的收益，反而會(huì)帶來(lái)很多穩(wěn)定性上的損失。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

改造走樣的元兇

那么為什么會(huì)造成上面所說(shuō)的問(wèn)題呢？我覺(jué)得主要有兩方面：

1. 領(lǐng)域拆分的不合理，引出了過(guò)多的同步遠(yuǎn)程調(diào)用

這個(gè)是最根本的問(wèn)題，也是在改造過(guò)程中最常見的。這部分說(shuō)實(shí)話是整個(gè)改造過(guò)程中最難的，因?yàn)樾枰獙?duì)業(yè)務(wù)有非常深入的認(rèn)識(shí)，對(duì)系統(tǒng)設(shè)計(jì)的領(lǐng)域模型、用戶行為有足夠的理解。在做拆分的時(shí)候，盡可能的減少同步遠(yuǎn)程調(diào)用，取而代之的是走消息的異步交互，同時(shí)根據(jù)業(yè)務(wù)需要也可以做適當(dāng)?shù)臄?shù)據(jù)冗余。這樣就能保證，每個(gè)被拆分后的微服務(wù)之間可以獲得更低耦合度。

因?yàn)楦偷鸟詈隙龋覀儾拍茉诓蛔鋈魏蝺?yōu)化的情況下，獲得更少的分布式所帶來(lái)的穩(wěn)定性損失。對(duì)于后面要將的第2點(diǎn)的工作量也就越少。同時(shí)，對(duì)于真正的獨(dú)立開發(fā)、部署、運(yùn)行也成為可能。

2. 簡(jiǎn)單粗暴的實(shí)現(xiàn)，缺少分布式的保護(hù)機(jī)制

在很多團(tuán)隊(duì)里，因?yàn)闃I(yè)務(wù)需求多與人員配置少的矛盾之下，開發(fā)人員很容易出現(xiàn)對(duì)遠(yuǎn)程調(diào)用不做足夠的保護(hù)機(jī)制，比如：接口提供方的限流策略（保護(hù)自己不被別人搞死），接口調(diào)用方的降級(jí)策略（保護(hù)業(yè)務(wù)更高的可用性），接口調(diào)用方的熔斷策略（保護(hù)自己不被別人拖死）。只有認(rèn)真對(duì)待每一個(gè)分布式環(huán)境下的依賴點(diǎn)，那么才能解決因?yàn)榉植际礁脑焖鶢窟B出的諸多問(wèn)題。

但要做好這一點(diǎn)的核心，還是對(duì)第一點(diǎn)的把握，只有在領(lǐng)域模型上做更合理的拆分規(guī)劃，才能支持開發(fā)人員做好這個(gè)點(diǎn)，不然隨意的拆分，一大堆接口調(diào)用壓給本就壓力很大的開發(fā)人員，那這部分的開發(fā)質(zhì)量肯定很難保障了，自然而然的系統(tǒng)穩(wěn)定性就開始隨著接口復(fù)雜度的增加而不斷下降了。最后，開發(fā)人員就會(huì)開始來(lái)我們?nèi)豪锿虏哿?..甚至大家也開始懷疑微服務(wù)根本帶不來(lái)效率的提升！

最后，思考一下，你們的微服務(wù)改造有出現(xiàn)這里我說(shuō)的情況嗎？還是有其他不一樣的問(wèn)題呢？歡迎留言區(qū)說(shuō)說(shuō)你們的問(wèn)題，聊聊你的觀點(diǎn)！