你覺得在作的是微服務？不！你只是作了個比單體還糟糕的分佈式單體！

昨晚睡覺前，順手擼了幾個羣聊的聊天記錄。發現一個頗有意思的名詞「分佈式單體」，順藤摸瓜看了一下以前的聊天記錄，因爲內容罵罵咧咧，我就不貼出來了。。。大體內容就是某公司在作微服務改造，但改的不三不四，形式上像微服務，而本質上依然是單體，甚至連單體都不如。

這樣的改造現象，其實在國內仍是蠻多見的。下面就來聊聊這個有趣的話題：分佈式單體。各位看官，看看大家公司是否是也犯了這樣的錯誤？

分佈式單體爲何很差

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

1. 肯定業務領域，拆分存儲，定義各微服務的邊界
2. 改造代碼邏輯，將原來的內部service調用改爲dubbo或feign這樣的遠程調用

經過這樣的改造，咱們獲得了不少好處，好比：

1. 代碼庫分開了，減小了麻煩的解決代碼衝突的困擾
2. CI/CD分開了，每一個拆分後的服務均可以獨立開發、部署、運行
3. 數據庫分開了，獨立運行，不一樣業務模塊不會互相影響

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

1. 代碼庫是分開了，但每一個服務都在獨立迭代嗎？是否是每一個需求都要協調一大堆同步接口？
2. CI/CD是分開了，但每次發佈都是自由的嗎？是否是每次功能的發佈都拖上了一大推的服務要一塊兒發佈？
3. 數據庫是分開了，但彷佛有個服務掛了，依然致使不少功能就都不正常了？

看似咱們獲得了不少好處，但咱們的開發效率真的獲得了提高嗎？雖然咱們之前一個單體應用啓動要3分鐘，如今拆分後，一個項目啓動30秒，但每次開發調試要同時開好幾個項目同時啓動？這樣的開發體驗真的爽到了嗎？

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

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

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

因此，這樣改造的結果，不但沒有獲得不少的收益，反而會帶來不少穩定性上的損失。本文首發不三不四的微服務改造：分佈式單體 ，禁止未經受權轉載。

改造走樣的元兇

那麼爲何會形成上面所說的問題呢？我以爲主要有兩方面：

1. 領域拆分的不合理，引出了過多的同步遠程調用

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

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

2. 簡單粗暴的實現，缺乏分佈式的保護機制

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

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

最後，思考一下：大家的微服務改造有出現這裏我說的狀況嗎？仍是有其餘不同的問題呢？加入咱們的Spring技術交流羣，聊聊你的觀點！

推薦閱讀

• 微服務（Microservices）中文版
• 《微服務》九大特性重讀筆記
• 雲原生應用的12要素