微服務要涼了？
這裏是Z哥的個人公衆號
每週五11：45 按時送達
當然了，也會時不時加個餐～
我的第「147」篇原創敬上
大家好，我是Z哥。
如果你是做技術的話，不知道是否有注意到，從19年下半年開始，一些技術媒體開始報道一些公司在“去微服務”（最早應該是InfoQ在2019年8月23日發的一篇）。
近期這類信息被報道的頻繁度進一步增加。 這不，最近陸續又有一些國外公司宣佈退出微服務架構的迭代路線，逐漸將一些小粒度的服務進行合併成一個更大粒度的服務，甚至還發明瞭一個新的名詞——「 宏服務（macroservices） 」。其中不乏像Uber這樣的體量的大公司。
當然了，可能你會覺得服務的合併就像員工的“合併”一樣，Uber這不是正在節約成本裁員麼。服務合併也好比是“裁員”，當然對降低成本有好處。
理是這麼個理，但是這恰恰也說明了我們需要重新審視一下微服務的價值，到底對系統是不是真的適用？還是之前錢太多，多招點人、多燒掉點錢？
對於微服務本身的立場，我在之前的《 istio迴歸「單體應用」對我們的啓發 》已經聊過了，這裏就不多說了。這次我主要想通過最新想到的一種方式來幫你判斷當下的服務化拆分是否合理。
首先，你可以問自己兩個問題先。這兩個問題也代表了兩個不同的維度，後面會將這兩個維度組合起來看。
問題1：當前系統拆分的服務顆粒度是小、大還是中等？
爲了避免糾結到底是小還是大，所以多放了一箇中等的選項。畢竟「中等」是中國文化博大精深的「中庸思想」的體現，還是很符合我們國情的。
那麼具體怎麼判斷呢？我的建議是，你分析一下當前系統中的所有功能操作，如果大部分操作都只經過三個（含）以下的服務即可完成，顆粒度算大。六個（含）以下算中等，九個（含）以上算小）
問題2：每個月產生的bug中有多少比例是技術性的問題導致的。比如，所依賴的後端服務不穩定導致的bug這種就算。代碼邏輯寫錯了、代碼寫的不嚴謹這類不管是不是微服務都會發生的情況就不算。
最終，如果技術原因導致的bug佔總數小於等於10%，那麼還不錯，大於10%小於等於20%算中等，大於20%算嚴重。大家應該都明白，技術性問題的佔比越大，越意味着技術不但沒有起到支撐業務、推動業務的作用，反而在幫倒忙。
然後，我們將這兩個維度組合起來形成這樣的一個象限圖。
你可以對照一下，如果當前系統處於綠色區間，那麼說明你們團隊目前可以比較好的hold住當前系統，可以保持不變。如果當前的系統處於黃色的區間，那麼得小心了，隨着規模的繼續發展或者時間的推移會有大概率進入紅色的區間。一旦進入紅色區間，其實微服務起到的反而是拖累作用了，不管原因是什麼。
可能你會有2個疑問，爲什麼右下角空了一塊出來，以及爲什麼顆粒度小的情況下沒有黃色。
我來一個一個解答。
首先，右下角空出來的那塊意味着，如果你的系統顆粒度還是比較大的，但是技術性的bug卻很多。只能說項目本身質量太差了，需補補底子，這與個微不微服務已經關係不大了。提升一下運維能力、架構設計能力等等，
其次，爲什麼「10%～20%」+「顆粒度小」是綠色。我自己做架構設計相關的工作有4、5年，作爲過來人的經驗，如果一個操作背後依賴9個以上的服務，其實項目的穩定性是非常難保證的。要麼索性就失控了，每天要忙着救火；要麼就是整個團隊的平均水平不錯，沒什麼明顯的短板而且人員數量也比較充足。
因爲每多一個服務，複雜度不是累加的，是指數級的增加。所以在這個層次，技術性的bug有所提高是正常的。但也正因爲如此，一旦bug的數量超過某個閾值，系統的穩定性會快速走低，會隔三差五的出問題。
當然，以上的觀點與我所參與的項目、團隊有比較大的相關性。所以具體的數值可能比較主觀，但是思路上還是值得你參考的。
好了，總結一下。
這篇呢，Z哥和你分享了我對系統微服務拆分的是否合理的一個新的觀點，通過兩個維度來判斷， 顆粒度大小和技術性bug的佔比 。通過這兩個維度所組合而成的不同情況，可以判斷當下的微服務做的如何。
希望對你有所啓發。
技術再好，切勿貪杯。如果宏服務的風颳起來，不知道還會有多少企業去追呢？
推薦閱讀：
原創不易，如果你覺得這篇文章還不錯，就「 在看 」或者「 分享 」一下吧。鼓勵我的創作 ：）
如果你有關於軟件架構、分佈式系統、產品、運營的困惑
可以試試點擊「 閱讀原文 」
