這是一個或許對你有用的開源項(xiàng)目
國產(chǎn) Star 破 10w+ 的開源項(xiàng)目,前端包括管理后臺 + 微信小程序,后端支持單體和微服務(wù)架構(gòu)。
功能涵蓋 RBAC 權(quán)限、SaaS 多租戶、數(shù)據(jù)權(quán)限、商城、支付、工作流、大屏報(bào)表、微信公眾號等等功能:
Boot 地址:https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 地址:https://gitee.com/zhijiantianya/yudao-cloud
視頻教程:https://doc.iocoder.cn
分布式單體為什么不好
改造走樣的元兇
1. 領(lǐng)域拆分的不合理,引出了過多的同步遠(yuǎn)程調(diào)用
2. 簡單粗暴的實(shí)現(xiàn),缺少分布式的保護(hù)機(jī)制
昨晚睡覺前,順手?jǐn)]了幾個群聊的聊天記錄。發(fā)現(xiàn)一個很有意思的名詞“分布式單體 ”,順藤摸瓜看了一下之前的聊天記錄,由于內(nèi)容罵罵咧咧,我就不貼出來了。大致內(nèi)容就是某公司在做微服務(wù)改造,但改的不倫不類,形式上像微服務(wù),而本質(zhì)上依然是單體,甚至連單體都不如。
這樣的改造現(xiàn)象,其實(shí)在國內(nèi)還是蠻多見的。今天我們就來聊聊這個有趣的話題:分布式單體 。各位看官,看看你們公司是不是也犯了這樣的錯誤?
分布式單體為什么不好
先思考一個問題:從單體改造到微服務(wù)的時候,你們是不是按這樣的步驟來的?
確定業(yè)務(wù)領(lǐng)域,拆分存儲,定義各微服務(wù)的邊界
改造代碼邏輯,將原來的內(nèi)部service調(diào)用改成dubbo或feign這樣的遠(yuǎn)程調(diào)用
通過這樣的改造,我們得到了很多好處,比如:
代碼庫分開了,減少了麻煩的解決代碼沖突的困擾
CI/CD分開了,每個拆分后的服務(wù)都可以獨(dú)立開發(fā)、部署、運(yùn)行
數(shù)據(jù)庫分開了,獨(dú)立運(yùn)行,不同業(yè)務(wù)模塊不會互相影響
這樣一頓操作,我們把一個臃腫的單體應(yīng)用變成了多個精煉的分布式應(yīng)用,似乎完美的實(shí)現(xiàn)了改造?但這樣就實(shí)現(xiàn)了微服務(wù)的核心目標(biāo)了嗎?繼續(xù)思考下面的問題:
代碼庫是分開了,但每個服務(wù)都在獨(dú)立迭代嗎?是不是每個需求都要協(xié)調(diào)一大堆同步接口?
CI/CD是分開了,但每次發(fā)布都是自由的嗎?是不是每次功能的發(fā)布都拖上了一大推的服務(wù)要一起發(fā)布?
數(shù)據(jù)庫是分開了,但似乎有個服務(wù)掛了,依然導(dǎo)致很多功能就都不正常了?
看似我們得到了很多好處,但我們的開發(fā)效率真的得到了提升嗎?雖然我們以前一個單體應(yīng)用啟動要3分鐘,現(xiàn)在拆分后,一個項(xiàng)目啟動30秒,但每次開發(fā)調(diào)試要同時開好幾個項(xiàng)目同時啟動?這樣的開發(fā)體驗(yàn)真的爽到了嗎?
看似完成了微服務(wù)改造,實(shí)則依然是個單體應(yīng)用,只是從原本的集中式實(shí)現(xiàn),變成是分布式實(shí)現(xiàn)。原來我們只是做了一次無用功,真正的收益微乎其微。
而實(shí)際上,這樣的改造,除了收益不高之外,還帶出了更多的壞處。如果你們公司是這樣做的,有沒有發(fā)現(xiàn),這樣做之后,好像系統(tǒng)故障的頻率更高了?穩(wěn)定性似乎比單體應(yīng)用還差?(如果沒有,那一定要感謝你們的運(yùn)維團(tuán)隊(duì)真的很給力,同時建議把這篇轉(zhuǎn)給運(yùn)維團(tuán)隊(duì),采訪下這樣的改造是不是他們變得更累了?!)
為什么這樣的改造會導(dǎo)致系統(tǒng)更加不穩(wěn)定呢?其實(shí)道理很簡單,原本我們在單體應(yīng)用中,未拆分的遠(yuǎn)程調(diào)用都是內(nèi)部調(diào)用,這個內(nèi)部調(diào)用所能引發(fā)的故障率是微乎其微的,而將這部分內(nèi)容拆成了遠(yuǎn)程調(diào)用后,每一個調(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ù)雜度時,那么改造的系統(tǒng),必然穩(wěn)定性會比原來的單體應(yīng)用更差。
所以,這樣改造的結(jié)果,不但沒有得到很多的收益,反而會帶來很多穩(wěn)定性上的損失。
基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
項(xiàng)目地址:https://github.com/YunaiV/ruoyi-vue-pro
視頻教程:https://doc.iocoder.cn/video/
改造走樣的元兇
那么為什么會造成上面所說的問題呢?我覺得主要有兩方面:
1. 領(lǐng)域拆分的不合理,引出了過多的同步遠(yuǎn)程調(diào)用
這個是最根本的問題,也是在改造過程中最常見的。這部分說實(shí)話是整個改造過程中最難的,因?yàn)樾枰獙I(yè)務(wù)有非常深入的認(rèn)識,對系統(tǒng)設(shè)計(jì)的領(lǐng)域模型、用戶行為有足夠的理解。在做拆分的時候,盡可能的減少同步遠(yuǎn)程調(diào)用,取而代之的是走消息的異步交互,同時根據(jù)業(yè)務(wù)需要也可以做適當(dāng)?shù)臄?shù)據(jù)冗余。這樣就能保證,每個被拆分后的微服務(wù)之間可以獲得更低耦合度。
因?yàn)楦偷鸟詈隙?,我們才能在不做任何?yōu)化的情況下,獲得更少的分布式所帶來的穩(wěn)定性損失。對于后面要將的第2點(diǎn)的工作量也就越少。同時,對于真正的獨(dú)立開發(fā)、部署、運(yùn)行也成為可能。
2. 簡單粗暴的實(shí)現(xiàn),缺少分布式的保護(hù)機(jī)制
在很多團(tuán)隊(duì)里,因?yàn)闃I(yè)務(wù)需求多與人員配置少的矛盾之下,開發(fā)人員很容易出現(xiàn)對遠(yuǎn)程調(diào)用不做足夠的保護(hù)機(jī)制,比如:接口提供方的限流策略(保護(hù)自己不被別人搞死),接口調(diào)用方的降級策略(保護(hù)業(yè)務(wù)更高的可用性),接口調(diào)用方的熔斷策略(保護(hù)自己不被別人拖死)。只有認(rèn)真對待每一個分布式環(huán)境下的依賴點(diǎn),那么才能解決因?yàn)榉植际礁脑焖鶢窟B出的諸多問題。
但要做好這一點(diǎn)的核心,還是對第一點(diǎn)的把握,只有在領(lǐng)域模型上做更合理的拆分規(guī)劃,才能支持開發(fā)人員做好這個點(diǎn),不然隨意的拆分,一大堆接口調(diào)用壓給本就壓力很大的開發(fā)人員,那這部分的開發(fā)質(zhì)量肯定很難保障了,自然而然的系統(tǒng)穩(wěn)定性就開始隨著接口復(fù)雜度的增加而不斷下降了。最后,開發(fā)人員就會開始來我們?nèi)豪锿虏哿?..甚至大家也開始懷疑微服務(wù)根本帶不來效率的提升!
最后,思考一下,你們的微服務(wù)改造有出現(xiàn)這里我說的情況嗎?還是有其他不一樣的問題呢?歡迎留言區(qū)說說你們的問題,聊聊你的觀點(diǎn)!
-
分布式
+關(guān)注
關(guān)注
1文章
824瀏覽量
74396 -
模型
+關(guān)注
關(guān)注
1文章
3032瀏覽量
48366 -
微服務(wù)
+關(guān)注
關(guān)注
0文章
126瀏覽量
7303
原文標(biāo)題:你以為在做的是微服務(wù)?不!你只是做了個比單體還糟糕的分布式單體!
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論