昨晚睡覺前磨澡，順手擼了幾個群聊的聊天記錄碗啄。發(fā)現(xiàn)一個很有意思的名詞“分布式單體”，順藤摸瓜看了一下之前的聊天記錄钱贯，由于內(nèi)容罵罵咧咧挫掏，我就不貼出來了。秩命。尉共。大致內(nèi)容就是某公司在做微服務(wù)改造褒傅，但改的不倫不類，形式上像微服務(wù)袄友，而本質(zhì)上依然是單體殿托，甚至連單體都不如。
這樣的改造現(xiàn)象剧蚣，其實在國內(nèi)還是蠻多見的支竹。下面就來聊聊這個有趣的話題：分布式單體。各位看官鸠按，看看你們公司是不是也犯了這樣的錯誤礼搁？
分布式單體為什么不好
先思考一個問題：從單體改造到微服務(wù)的時候，你們是不是按這樣的步驟來的目尖？
- 確定業(yè)務(wù)領(lǐng)域馒吴，拆分存儲，定義各微服務(wù)的邊界
- 改造代碼邏輯瑟曲，將原來的內(nèi)部service調(diào)用改成dubbo或feign這樣的遠程調(diào)用
通過這樣的改造饮戳，我們得到了很多好處，比如：
- 代碼庫分開了洞拨，減少了麻煩的解決代碼沖突的困擾
- CI/CD分開了扯罐，每個拆分后的服務(wù)都可以獨立開發(fā)、部署烦衣、運行
- 數(shù)據(jù)庫分開了歹河，獨立運行，不同業(yè)務(wù)模塊不會互相影響
這樣一頓操作琉挖，我們把一個臃腫的單體應(yīng)用變成了多個精煉的分布式應(yīng)用启泣，似乎完美的實現(xiàn)了改造？但這樣就實現(xiàn)了微服務(wù)的核心目標了嗎示辈？繼續(xù)思考下面的問題：
- 代碼庫是分開了寥茫，但每個服務(wù)都在獨立迭代嗎？是不是每個需求都要協(xié)調(diào)一大堆同步接口矾麻？
- CI/CD是分開了纱耻，但每次發(fā)布都是自由的嗎？是不是每次功能的發(fā)布都拖上了一大推的服務(wù)要一起發(fā)布险耀？
- 數(shù)據(jù)庫是分開了弄喘，但似乎有個服務(wù)掛了，依然導(dǎo)致很多功能就都不正常了甩牺？
看似我們得到了很多好處蘑志，但我們的開發(fā)效率真的得到了提升嗎？雖然我們以前一個單體應(yīng)用啟動要3分鐘，現(xiàn)在拆分后急但，一個項目啟動30分鐘澎媒，但每次開發(fā)調(diào)試要同時開好幾個項目同時啟動？這樣的開發(fā)體驗真的爽到了嗎波桩？
看似完成了微服務(wù)改造戒努，實則依然是個單體應(yīng)用，只是從原本的集中式實現(xiàn)镐躲，變成是分布式實現(xiàn)储玫。原來我們只是做了一次無用功，真正的收益微乎其微萤皂。
而實際上撒穷，這樣的改造，除了收益不高之外裆熙，實際上還帶出了更多的壞處桥滨。如果你們公司是這樣做的，有沒有發(fā)現(xiàn)弛车，這樣做之后，好像系統(tǒng)故障的頻率更高了蒲每？穩(wěn)定性似乎比單體應(yīng)用還差纷跛？（如果沒有，那一定要感謝你們的運維團隊真的很給力邀杏，同時建議把這篇轉(zhuǎn)給運維團隊贫奠，采訪下這樣的改造是不是他們變得更累了？Ｍ）
為什么這樣的改造會導(dǎo)致系統(tǒng)更加不穩(wěn)定呢唤崭？其實道理很簡單，原本我們在單體應(yīng)用中脖律，未拆分的遠程調(diào)用都是內(nèi)部調(diào)用谢肾，這個內(nèi)部調(diào)用所能引發(fā)的故障率是微乎其微的，而將這部分內(nèi)容拆成了遠程調(diào)用后小泉，每一個調(diào)用都增加了網(wǎng)絡(luò)IO的因素芦疏，每一次調(diào)用的故障率都增加了。那么系統(tǒng)的整體故障率是隨著系統(tǒng)擁有多少同步遠程調(diào)用的數(shù)量增加而增加的微姊。當運維團隊與開發(fā)水平?jīng)]有沒有支持好這部分增加的復(fù)雜度的時候酸茴，那么改造的系統(tǒng)，必然的穩(wěn)定性會比原來的單體應(yīng)用更差兢交。
所以薪捍，這樣改造的結(jié)果，不但沒有得到很多的收益，反而會帶來很多穩(wěn)定性上的損失酪穿。本文首發(fā)不倫不類的微服務(wù)改造：分布式單體 凳干，禁止未經(jīng)授權(quán)轉(zhuǎn)載。
改造走樣的元兇
那么為什么會造成上面所說的問題呢昆稿？我覺得主要有兩方面：
- 領(lǐng)域拆分的不合理纺座，引出了過多的同步遠程調(diào)用
這個是最根本的問題，也是在改造過程中最常見的溉潭。這部分說實話是整個改造過程中最難的净响，因為需要對業(yè)務(wù)有非常深入的認識，對系統(tǒng)設(shè)計的領(lǐng)域模型喳瓣、用戶行為有足夠的理解馋贤。在做拆分的時候，盡可能的減少同步遠程調(diào)用畏陕，取而代之的是走消息的異步交互配乓，同時根據(jù)業(yè)務(wù)需要也可以做適當?shù)臄?shù)據(jù)冗余。這樣就能保證惠毁，每個被拆分后的微服務(wù)之間可以獲得更低耦合度犹芹。
因為更低的耦合度，我們才能在不做任何優(yōu)化的情況下鞠绰，獲得更少的分布式所帶來的穩(wěn)定性損失腰埂。對于后面要將的第2點的工作量也就越少。同時蜈膨，對于真正的獨立開發(fā)屿笼、部署、運行也成為可能翁巍。
- 簡單粗暴的實現(xiàn)驴一，缺少分布式的保護機制
在很多團隊里，因為業(yè)務(wù)需求多與人員配置少的矛盾之下下灶壶，開發(fā)人員很容易出現(xiàn)對遠程調(diào)用不做足夠的保護機制肝断，比如：接口提供方的限流策略（保護自己不被別人搞死），接口調(diào)用方的降級策略（保護業(yè)務(wù)更高的可用性）驰凛，接口調(diào)用方的熔斷策略（保護自己不被別人拖死）孝情。只有認真對待每一個分布式環(huán)境下的依賴點，那么才能解決因為分布式改造所牽連出的諸多問題洒嗤。
但要做好這一點的核心箫荡，還是對第一點的把握，只有在領(lǐng)域模型上做更合理的拆分規(guī)劃渔隶，才能支持開發(fā)人員做好這個點羔挡，不然隨意的拆分洁奈，一大堆接口調(diào)用壓給本就壓力很大的開發(fā)人員，那這部分的開發(fā)質(zhì)量是很難保障了绞灼，自然而然的系統(tǒng)穩(wěn)定性就開始隨著接口復(fù)雜度的增加而不斷下降了利术。最后，開發(fā)人員就會開始來我們?nèi)豪锿虏哿?..甚至大家也開始懷疑微服務(wù)根本帶不來效率的提升低矮！
最后印叁，思考一下：你們的微服務(wù)改在有出現(xiàn)這里我說的情況嗎？還是有其他不一樣的問題呢军掂？加入我們的Spring技術(shù)交流群轮蜕，聊聊你的觀點！
推薦閱讀
歡迎關(guān)注我的公眾號：程序猿DD蝗锥，獲得獨家整理的免費學(xué)習資源助力你的Java學(xué)習之路跃洛！另每周贈書不停哦～
