昨晚睡覺前，順手擼了幾個群聊的聊天記錄，發現一個很有意思的名詞“分布式單體”，順藤摸瓜看了一下之前的聊天記錄，由于內容罵罵咧咧，我就不貼出來了，，，大致內容就是某公司在做微服務改造，但改的不倫不類，形式上像微服務，而本質上依然是單體，甚至連單體都不如，
這樣的改造現象，其實在國內還是蠻多見的，下面就來聊聊這個有趣的話題：分布式單體，各位看官，看看你們公司是不是也犯了這樣的錯誤？
分布式單體為什么不好
先思考一個問題：從單體改造到微服務的時候，你們是不是按這樣的步驟來的？
- 確定業務領域，拆分存盤，定義各微服務的邊界
- 改造代碼邏輯，將原來的內部service呼叫改成dubbo或feign這樣的遠程呼叫
通過這樣的改造，我們得到了很多好處，比如：
- 代碼庫分開了，減少了麻煩的解決代碼沖突的困擾
- CI/CD分開了，每個拆分后的服務都可以獨立開發、部署、運行
- 資料庫分開了，獨立運行，不同業務模塊不會互相影響
這樣一頓操作，我們把一個臃腫的單體應用變成了多個精煉的分布式應用，似乎完美的實作了改造？但這樣就實作了微服務的核心目標了嗎？繼續思考下面的問題：
- 代碼庫是分開了，但每個服務都在獨立迭代嗎？是不是每個需求都要協調一大堆同步介面？
- CI/CD是分開了，但每次發布都是自由的嗎？是不是每次功能的發布都拖上了一大推的服務要一起發布？
- 資料庫是分開了，但似乎有個服務掛了，依然導致很多功能就都不正常了？
看似我們得到了很多好處，但我們的開發效率真的得到了提升嗎？雖然我們以前一個單體應用啟動要3分鐘，現在拆分后，一個專案啟動30秒，但每次開發除錯要同時開好幾個專案同時啟動？這樣的開發體驗真的爽到了嗎？
看似完成了微服務改造，實則依然是個單體應用，只是從原本的集中式實作，變成是分布式實作，原來我們只是做了一次無用功，真正的收益微乎其微，
而實際上，這樣的改造，除了收益不高之外，實際上還帶出了更多的壞處，如果你們公司是這樣做的，有沒有發現，這樣做之后，好像系統故障的頻率更高了？穩定性似乎比單體應用還差？（如果沒有，那一定要感謝你們的運維團隊真的很給力，同時建議把這篇轉給運維團隊，采訪下這樣的改造是不是他們變得更累了？！）
為什么這樣的改造會導致系統更加不穩定呢？其實道理很簡單，原本我們在單體應用中，未拆分的遠程呼叫都是內部呼叫，這個內部呼叫所能引發的故障率是微乎其微的，而將這部分內容拆成了遠程呼叫后，每一個呼叫都增加了網路IO的因素，每一次呼叫的故障率都增加了，那么系統的整體故障率是隨著系統擁有多少同步遠程呼叫的數量增加而增加的，當運維團隊與開發水平沒有沒有支持好這部分增加的復雜度的時候，那么改造的系統，必然的穩定性會比原來的單體應用更差，
所以，這樣改造的結果，不但沒有得到很多的收益，反而會帶來很多穩定性上的損失，本文首發不倫不類的微服務改造：分布式單體 ，禁止未經授權轉載，
改造走樣的元兇
那么為什么會造成上面所說的問題呢？我覺得主要有兩方面：
- 領域拆分的不合理，引出了過多的同步遠程呼叫
這個是最根本的問題，也是在改造程序中最常見的，這部分說實話是整個改造程序中最難的，因為需要對業務有非常深入的認識，對系統設計的領域模型、用戶行為有足夠的理解，在做拆分的時候，盡可能的減少同步遠程呼叫，取而代之的是走訊息的異步互動，同時根據業務需要也可以做適當的資料冗余，這樣就能保證，每個被拆分后的微服務之間可以獲得更低耦合度，
因為更低的耦合度，我們才能在不做任何優化的情況下，獲得更少的分布式所帶來的穩定性損失，對于后面要將的第2點的作業量也就越少，同時，對于真正的獨立開發、部署、運行也成為可能，
- 簡單粗暴的實作，缺少分布式的保護機制
在很多團隊里，因為業務需求多與人員配置少的矛盾之下下，開發人員很容易出現對遠程呼叫不做足夠的保護機制，比如：介面提供方的限流策略（保護自己不被別人搞死），介面呼叫方的降級策略（保護業務更高的可用性），介面呼叫方的熔斷策略（保護自己不被別人拖死），只有認真對待每一個分布式環境下的依賴點，那么才能解決因為分布式改造所牽連出的諸多問題，
但要做好這一點的核心，還是對第一點的把握，只有在領域模型上做更合理的拆分規劃，才能支持開發人員做好這個點，不然隨意的拆分，一大堆介面呼叫壓給本就壓力很大的開發人員，那這部分的開發質量是很難保障了，自然而然的系統穩定性就開始隨著介面復雜度的增加而不斷下降了，最后，開發人員就會開始來我們群里吐槽了...甚至大家也開始懷疑微服務根本帶不來效率的提升！
最后，思考一下：你們的微服務改造有出現這里我說的情況嗎？還是有其他不一樣的問題呢？加入我們的Spring技術交流群，聊聊你的觀點！
推薦閱讀
- 微服務（Microservices）中文版
- 《微服務》九大特性重讀筆記
- 云原生應用的12要素
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/270928.html
標籤：架構設計
上一篇：Java資料持久層