面試官：微服務如何拆分？需要考慮什么因素？

候選人：一般按照功能拆分

面試官：還有嗎？

候選人：唔……

要拆分微服務，首先我們要了解微服務拆了會有什么問題？怎么合理拆服務？

拆分服務會帶來什么問題？

舉個電商系統下單扣庫存的例子。

對于單體應用，通訊在進程內部進行，下單方法調用扣庫存方法，有問題就回滾事務，利用數據庫同一個Session會話的ACID特性干活，保證數據的強一致性，即使在調用下單方法成功后應用崩潰，數據也不會提交到數據庫，不會產生臟數據。

而拆分成各個微服務后，代碼、數據庫進行了隔離，下單扣庫存邏輯變成了訂單服務通過RPC調用庫存服務，由于不受同一個數據庫Session會話控制，就必然會存在因業務處理失敗、應用崩潰、網絡通訊異常等一系列問題導致的數據不一致。

這是一個典型的復雜度轉移的例子——單體應用的代碼復雜度轉移到了微服務之間的通訊復雜度，整體的復雜度并沒有降低。

回到經典的分布式CAP定理：數據一致性、可用性、分區容錯性，三者取其二。

CAP是分布式系統中三個維度的“客戶承諾”：

• 一致性：要么我給你返回一個錯誤，要么我給你返回絕對一致的最新數據，強調數據正確

• 可用性：我一定會給你返回數據，不會給你返回錯誤，但不保證數據最新，強調的是服務不出錯

• 分區容錯性：我會一直運行，不管我的內部出現何種數據同步問題，強調的是不掛掉

為了解決數據一致性問題，業界又引入了各種一致性保障機制，比如BASE理論（基本可用、軟狀態、最終一致）、分布式事務DTP模型（XA協議、TCC協議）、JTA模型等等，根據對數據一致性的要求又劃分為強一致性、弱一致性、最終一致性的方案，在分布式系統中通過一系列措施來保證ACID。

在實際互聯網項目開發中，分布式事務不宜設計得太重，通常來說異步的場景使用事務性MQ來解決，比如RabbitMQ、Kafka、RocketMQ等；同步的場景使用業務狀態機來規避它們，比如訂單分正向銷售單、逆向售后單，單據有不同維度的狀態，比如支付狀態、退款狀態、物流狀態、開票狀態等等，對于出錯的環節進行客戶干預、系統告警或客服干預，暫時停留在異常節點，這里的“狀態”可以理解為BASE理論中的軟狀態。

說到底還是用BASE理論指導生產。

說那么多，我們通過拆分微服務，提高了系統的分區容錯性與可用性，卻犧牲了單體應用的一致性優勢，所以說，不要為了拆而拆，拆服務也需要合理“動機”，那什么樣的“動機”是合理的呢？

如何合理拆分微服務？

OK，了解了服務拆分帶來的問題后，我們拆服務就得更加嚴謹了，那怎么合理拆呢？

這里提供一些思路。

一、按單一職責拆

還是以我們的電商平臺舉例，一開始我們最核心的OMS訂單系統做了特別多事情，包括：用戶、下單、商品、庫存、出入庫、營銷……

隨著公司業務快速增長，OMS代碼激增，新增/修改一個功能就要影響幾乎整個鏈路，穩定性降低，也大大增加了風險，運維變得十分困難，這時不得不把各個模塊剝離出來，獨立成為UC用戶服務、PMS商品服務、CIS中央庫存服務、WMS出入庫服務、MCS營銷中心等等。

我們按照單一職責的劃分原則，每一個獨立的服務只提供該業務領域的核心功能，繼而每個獨立的服務演化出更為豐富的功能，數據庫也進行垂直拆分提供應用獨立訪問，并且每個服務提供雙節點保證高可用。

二、按團隊組織架構拆

這里必須提一提軟件架構設計中的第一定律——康威定律。

康威定律是馬爾文·康威1967年提出的：“設計系統的架構受制于產生這些設計的組織的溝通結構。”通俗地來講：產品必然是其（人員）組織溝通結構的縮影。

康威定律可總結為以下四個定律：

第一定律：組織溝通方式會通過系統設計表達出來。

這條定律重點是講組織架構和溝通對系統設計的影響。

組織的溝通和系統的設計之間緊密相連，特別是復雜系統，解決好人與人的溝通才能有一個更好的系統設計。

溝通的問題會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果，這也是為什么互聯網公司都追求小團隊的原因之一。

第二定律：時間再多一件事情也不可能做得完美，但總有時間做完一件事情。

人手永遠是不夠的，事情永遠是做不完的，但可以一件一件來。

這不就是軟件行業中“敏捷開發”模式所解決的問題嗎，面對這樣的狀況，敏捷開發可以做到不斷迭代、持續交付、快速驗證和反饋，并持續改進。

再牛的開發也會寫出BUG，再全面的測試覆蓋率也無法測出所有的問題，解決方案不是消滅這些問題，是容忍一些問題的存在，然后通過適當的設計（冗余、監控、高可用設計），當問題發生時能夠快速解決。

幾個開發人員的小公司，去追求微服務、中臺架構、這是追求完美嗎？

不是，這是找死。

好的架構不是買來的，也不是設計出來的，而是根據業務落地生根長期演化來的。

第三定律：線型系統和線型組織架構間有潛在的異質同態特性。

這一定律是第一定律的具體應用。

想象一下如果公司的架構是這樣的：

團隊是分布式，每個團隊都包含產品、研發、測試、運維等角色，而此時系統是單體應用，那項目溝通和協調的成本是巨大的，弄不好還會打起來。

如果將單塊的系統拆分成微服務，每個團隊負責自己的部分，對外提供對應的接口即可，互不干擾，系統效率將得到提升，這與軟件設計中的高內聚、低耦合是相通的。

直白地說就是想要什么樣的系統就搭建什么樣的團隊，有什么樣的團隊就搭建什么樣的系統，需要前后端分離的系統就搭建前后端分離的團隊；反之，擁有前后端分離的團隊就可以設計前后端分離的系統。

第四定律：大的系統組織總是比小系統更傾向于分解。

“話說天下大勢，分久必合，合久必分。”系統越復雜，越需要增加人手，人手越多，溝通成本也呈指數增長，分而治之便是大多數公司選擇的解決方案，分不同的層級，分不同的小團隊，讓團隊內部完成自治理，然后統一對外溝通。

我們試著從康威定律來推導系統的架構演進方向，自然知道微服務的拆解粒度了。

SOA 也好、微服務也好，解決的根本問題是團隊分工問題，這是大型軟件發展的必然，不因為人的喜好而改變，當你讀懂康威定律，就會發現“服務拆分粒度難以準確把握”根本不是本質問題，你有幾個 2 pizza 團隊，最好就拆成幾個微服務。

只有一個開發人員時，盡量就做單體應用，不要沒事找刺激拆成 10 個微服務，最終這個開發人員還會把他合成一個。

微服務要求縱向的 2 pizza 團隊（無數個小團隊，包含開發、測試、運維），如果團隊還是處在橫向結構的場景下（開發、運維、測試各是一個團隊），比如說一些傳統大型企業，去實施微服務會讓他們很痛苦，尤其是運維團隊。

總結一下

具體實踐建議：

• 我們要用一切手段提升溝通效率，比如slack，github，wiki。能2個人講清楚的事情，就不要拉更多人，每個人每個系統都有明確的分工，出了問題知道馬上找誰，避免踢皮球。

• 通過MVP的方式來設計系統，通過不斷地迭代來驗證優化，系統應該是彈性設計的。

• 你想要什么樣的系統設計，就架構什么樣的團隊，能扁平化就扁平化。最好按業務來劃分團隊，這樣能讓團隊自然的自治內聚，明確的業務邊界會減少和外部的溝通成本，每個小團隊都對自己的模塊的整個生命周期負責，沒有邊界不清，沒有無效的扯皮，inter-operate, not integrate。

• 做小而美的團隊，人多會帶來溝通的成本，讓效率下降。亞馬遜的Bezos有個逗趣的比喻，如果2個披薩不夠一個團隊吃的，那么這個團隊就太大了。事實上一般一個互聯網公司小產品的團隊差不多就是7，8人左右。

總之，只要說得清楚，運維能力又能跟上，服務拆分一般就是合理的！

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的面试基操：微服务拆分需要考虑什么因素？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。