淺聊微服務化的時機問題（業務/技術、組織）

微服務架構發展到現在，其技術棧已經非常成熟，而且門檻越來越低，大家的接受度越來越高，掌握微服務開發，已經成了新生代工程師們的标配技能。但同時我們也要看到，很多公司在實施微服務時，仍然會出現各式各樣的問題，純技術問題這裡不再讨論，更多的是了解和判斷上的問題(當然，肯定都是Leader們的鍋)，我嘗試從業務/技術、組織這兩個方面來闡述下我的一些思考和淺見。

插播解釋下，我為什麼把【業務/技術】看成一類問題，原因就在于：産品微服務化的目的是為了業務的發展，技術本質上是業務倒逼才需要發展的，這應該成為大家的共識，否則微服務化的方向可能就錯了。

我認為：微服務化的時機，取決于業務群組織的發展情況。

1. 業務發展到一定規模，會給系統帶來更大的壓力，進而持續影響性能、穩定性、資源利用、平台化、産品疊代速度等問題。下面先從這幾個問題開始說起，大家會看到，拆分時機不在于“是否影響”，而在于“如何影響”及“影響程度”，不要被幾個簡單的詞彙蒙蔽了，凡是都有正方面，最終要靠大家自己判斷。

性能方面，主要是指單體本身由于資源受限而産生的性能瓶頸，垂直拆分+水準擴充可以将壓力分散出去，這個是拆分驅動力之一。我們同時也要知道，在單體資源不受限的情況下，實際上性能可能會更好，因為它省去了程序間通信的開銷。并且，很多性能問題不是出現在代碼層，而是資料層，比如單表太膨脹、（多表）查詢太瘋狂等等，這個是使用單純的微服務架構解決不了的，此時應該首先引入對資料層的重構，比如分庫分表。當然，這也是不容易的。依我看來，分庫這個動作本身就包含了對服務拆分的思考，因為在微服務的定義裡面，其重要特征之一就是資料獨立自治，是以在分庫設計階段，其實就已經要開始做微服務的規劃了。無論怎樣，在單體中先做資料層的拆分優化，總比直接上全套微服務方案要穩妥很多。而一旦系統承載突破了單體本身的能力極限，再去實施微服務化，會簡單很多。

穩定性方面，單體的問題在于當一個執行個體挂了之後，沒有後續執行個體補上，而且一旦挂了，整個服務都不可用。而微服務剛好可以解決這個問題。但是，微服務的穩定性很多時候也會出問題，比如說當依賴層次過多，中途一旦有故障産生，或者網絡有明顯抖動，整個服務的穩定性也會大打折扣。

資源利用方面，這一塊容易讓人忽略。在系統中，有的功能是耗記憶體，有的耗硬碟，有的耗CPU，假如放在一個大單體裡面，即使能做到一定的水準擴充，也不能個性化定制伺服器環境，造成資源浪費。假如這些服務能夠拆開，那麼可以分别使用記憶體型、高性能磁盤型（比如SSD）、高性能多核型機器，各盡其用。總體來講，拆分是能帶來資源利用上的收益的，隻不過，假如僅僅為了這點收益就要做拆分，很明顯也是不合理。

平台化方面，在業務早期并不是個問題（雖然大家都号稱平台），但是假如産品持續發展，它就會開始有對外輸出、賦能的能力及動力，比如說，有一天某外部合作方希望能借助你的某API做資料或流量上的合作，此時你能否快速提供安全可靠的OpenAPI？這個是單體系統無法（而且不能）提供的，其實可以作為拆分的重要依據之一。

産品疊代速度方面，在很長一段時間内，單體的開發速度肯定高于微服務的開發速度，隻不過當産品變得越來越大了之後，再繼續堆新功能就會比較麻煩，原因有二：工程代碼的臃腫、開發人員的增多，這會導緻項目管理很難進行，牽一發而動全身，産品疊代速度自然跟不上（Bug也會更多）。而拆分成微服務，理想情況下，每個服務都有維護更新者，大家增減功能或者bugfix時都不用戰戰兢兢如履薄冰了。不過，事情都有兩面性，微服務架構必然伴随着組織架構的調整，每個微服務都最好有獨立團隊，這在實際操作中會利弊都會存在，下面會提到。

2. 團隊（組織）發展到一定規模，人效管理模式會産生變化，需要解決協作效率的問題。

首先要明确的是，當一個産品不斷發展時，我們一般會假設研發人員的數量也會有相應增長，當一個大團隊面對一個大産品時，肯定會有很多分工，否則管理起來會比較麻煩，協作效率也會變低。一般情況下，我們仍然會按照職能子部門的方式來劃分團隊，比如産品部、運維部、測試部、架構部，分的再細一點，可能還有前端組、APP組等等，然後再劃分一個跨職能的項目開發組。假如隻有一個産品，這種職能型組織是可以良好運作的，每個工程師做雙向彙報：職能Leader和項目組Leader，考核由職能Leader來做。但假如涉及到多個産品線的，職能Leader的管理複雜度就會很大了（跨多個項目），此時管理權、考核權交給項目組Leader會更好點，那前者要架空嗎？依我看來，前者完全可以作為某專業方向的考核官，甚至是學學現在很多公司在做的“技術委員會”，負責專業方向的職級晉升，為了展現“技術服務于産品業務”的理念，它們的考評需要依賴項目組Leader的意見。

說了這麼多，和微服務的拆分時機有什麼關系呢？原因是微服務架構帶來的組織架構，也有上面的問題，一個項目組或者産品線團隊，某種程度上和一個微服務小團隊并沒有太大的不同。

大部分時候，我們拆分微服務的時機以系統/技術為主，重點解決系統本身的問題，但實際上【團隊（組織）的管理模式能否進行有效調整】也是非常重要的。人員/組織結構跟不上，微服務化之後的管理也會顯得力不從心。一個合理的微服務團隊應該是包括開發、測試、運維為一體的綜合性小團隊（兩個披薩原則），假如微服務過多，要考慮人員是否足夠應付每個服務的管理工作。而且由于大家習慣了職能部門的管理方式（比如研發、測試、運維屬于研發線子部門），可能一時半會兒不一定能轉型到微服務小團隊上來。

上面列出了團隊（組織）在産品發展過程中，可能會遇到的一些問題，此時我們要拷問下自己：團隊是否已經到達了轉型的節點，目前是否有能力迅速完成轉型？

是以綜合來講，業務發展的帶來的系統/技術問題，以及組織發展帶來的管理問題，是我們是否應該真正馬上推進微服務化的重要參考依據（時機）。這裡要說明的是：上面任何一個單獨的【問題】，都不能完全構成實施微服務化的依據，筆者在這裡隻是羅列出了大家需要參考的點，也同時指明了某些問題背後，事情存在的兩面性，最終需要大家自己斟酌。很多時候，你認為是技術問題，實際上并不一定是！

最後，來點真誠的勸告：新系統最好從單體開始，不過可以預先做點微服務的準備工作。

對于大部分中小系統來講，單體仍然是第一選擇，原因在于：新系統在業務邏輯上往往存在很多不确定性，過早的讨論服務的拆分不利于系統的快速上線，假如在業務邏輯沒有完全清晰的情況下貿然拆分，甚至會帶來很多不必要的麻煩，比如業務邏輯變化導緻功能重構。而假如趟過了一遍單體并成功上線後，你會對如何進行拆分有了更好的判斷，剩下的，就看你對這個遺留單體系統的改造信心了(笑)。

當然，做事情不能全憑信心，即使我們在最初選擇單體架構，也仍然可以做很多微服務的準備工作。比如說，在涉及到應用内的共享變量時，優先使用獨立的緩存系統，而不是用靜态變量，在涉及到對公共資源的鎖機制時，優先使用分布式鎖，而不是代碼級别的synchronized/lock。這樣，該單體可以在一定程度上進行水準擴充。當需要真的的進行服務拆分時，這些業務邏輯也可以盡可能的複用代碼（比如拷貝它們進入它該存在的服務裡面）。