你以爲在做的是微服務？其實只是做了個比單體還糟糕的分佈式單體

昨晚睡覺前，順手擼了幾個羣聊的聊天記錄。發現一個很有意思的名詞“分佈式單體”，順藤摸瓜看了一下之前的聊天記錄，由於內容罵罵咧咧，我就不貼出來了。大致內容就是某公司在做微服務改造，但改的不倫不類，形式上像微服務，而本質上依然是單體，甚至連單體都不如。

這樣的改造現象，其實在國內還是蠻多見的。今天我們就來聊聊這個有趣的話題：分佈式單體。各位看官，看看你們公司是不是也犯了這樣的錯誤？

分佈式單體爲什麼不好

先思考一個問題：從單體改造到微服務的時候，你們是不是按這樣的步驟來的？

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

這樣一頓操作，我們把一個臃腫的單體應用變成了多個精煉的分佈式應用，似乎完美的實現了改造？但這樣就實現了微服務的核心目標了嗎？繼續思考下面的問題：

看似我們得到了很多好處，但我們的開發效率真的得到了提升嗎？雖然我們以前一個單體應用啓動要3分鐘，現在拆分後，一個項目啓動30秒，但每次開發調試要同時開好幾個項目同時啓動？這樣的開發體驗真的爽到了嗎？

看似完成了微服務改造，實則依然是個單體應用，只是從原本的集中式實現，變成是分佈式實現。原來我們只是做了一次無用功，真正的收益微乎其微。

而實際上，這樣的改造，除了收益不高之外，還帶出了更多的壞處。如果你們公司是這樣做的，有沒有發現，這樣做之後，好像系統故障的頻率更高了？穩定性似乎比單體應用還差？（如果沒有，那一定要感謝你們的運維團隊真的很給力，同時建議把這篇轉給運維團隊，採訪下這樣的改造是不是他們變得更累了？！）

爲什麼這樣的改造會導致系統更加不穩定呢？其實道理很簡單，原本我們在單體應用中，未拆分的遠程調用都是內部調用，這個內部調用所能引發的故障率是微乎其微的，而將這部分內容拆成了遠程調用後，每一個調用都增加了網絡IO的因素，每一次調用的故障率都增加了。那麼系統的整體故障率是隨着系統擁有多少同步遠程調用的數量增加而增加的。當運維團隊與開發水平沒有支持好這部分增加的複雜度時，那麼改造的系統，必然穩定性會比原來的單體應用更差。

所以，這樣改造的結果，不但沒有得到很多的收益，反而會帶來很多穩定性上的損失。

改造走樣的元兇

那麼爲什麼會造成上面所說的問題呢？我覺得主要有兩方面：

這個是最根本的問題，也是在改造過程中最常見的。這部分說實話是整個改造過程中最難的，因爲需要對業務有非常深入的認識，對系統設計的領域模型、用戶行爲有足夠的理解。在做拆分的時候，儘可能的減少同步遠程調用，取而代之的是走消息的異步交互，同時根據業務需要也可以做適當的數據冗餘。這樣就能保證，每個被拆分後的微服務之間可以獲得更低耦合度。

因爲更低的耦合度，我們才能在不做任何優化的情況下，獲得更少的分佈式所帶來的穩定性損失。對於後面要講的第2點的工作量也就越少。同時，對於真正的獨立開發、部署、運行也成爲可能。

在很多團隊裡，因爲業務需求多與人員配置少的矛盾之下，開發人員很容易出現對遠程調用不做足夠的保護機制，比如：接口提供方的限流策略（保護自己不被別人搞死），接口調用方的降級策略（保護業務更高的可用性），接口調用方的熔斷策略（保護自己不被別人拖死）。只有認真對待每一個分佈式環境下的依賴點，那麼才能解決因爲分佈式改造所牽連出的諸多問題。

但要做好這一點的核心，還是對第一點的把握，只有在領域模型上做更合理的拆分規劃，才能支持開發人員做好這個點，不然隨意的拆分，一大堆接口調用壓給本就壓力很大的開發人員，那這部分的開發質量肯定很難保障了，自然而然的系統穩定性就開始隨着接口複雜度的增加而不斷下降了。最後，開發人員就會開始來我們羣裡吐槽了...甚至大家也開始懷疑微服務根本帶不來效率的提升！

最後，思考一下，你們的微服務改造有出現這裡我說的情況嗎？還是有其他不一樣的問題呢？歡迎留言區說說你們的問題，聊聊你的觀點！