面試官：微服務(wù)如何拆分?需要考慮什么因素?

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

面試官：還有嗎?

候選人：唔……

要拆分微服務(wù)，首先我們要了解微服務(wù)拆了會(huì)有什么問題?怎么合理拆服務(wù)?

拆分服務(wù)會(huì)帶來什么問題?

舉個(gè)電商系統(tǒng)下單扣庫存的例子。

對(duì)于單體應(yīng)用，通訊在進(jìn)程內(nèi)部進(jìn)行，下單方法調(diào)用扣庫存方法，有問題就回滾事務(wù)，利用數(shù)據(jù)庫同一個(gè)Session會(huì)話的ACID特性干活，保證數(shù)據(jù)的強(qiáng)一致性，即使在調(diào)用下單方法成功后應(yīng)用崩潰，數(shù)據(jù)也不會(huì)提交到數(shù)據(jù)庫，不會(huì)產(chǎn)生臟數(shù)據(jù)。

而拆分成各個(gè)微服務(wù)后，代碼、數(shù)據(jù)庫進(jìn)行了隔離，下單扣庫存邏輯變成了訂單服務(wù)通過RPC調(diào)用庫存服務(wù)，由于不受同一個(gè)數(shù)據(jù)庫Session會(huì)話控制，就必然會(huì)存在因業(yè)務(wù)處理失敗、應(yīng)用崩潰、網(wǎng)絡(luò)通訊異常等一系列問題導(dǎo)致的數(shù)據(jù)不一致。

這是一個(gè)典型的復(fù)雜度轉(zhuǎn)移的例子——單體應(yīng)用的代碼復(fù)雜度轉(zhuǎn)移到了微服務(wù)之間的通訊復(fù)雜度，整體的復(fù)雜度并沒有降低。

回到經(jīng)典的分布式CAP定理：數(shù)據(jù)一致性、可用性、分區(qū)容錯(cuò)性，三者取其二。

CAP是分布式系統(tǒng)中三個(gè)維度的“客戶承諾”：

• 一致性：要么我給你返回一個(gè)錯(cuò)誤，要么我給你返回絕對(duì)一致的最新數(shù)據(jù)，強(qiáng)調(diào)數(shù)據(jù)正確。
• 可用性：我一定會(huì)給你返回?cái)?shù)據(jù)，不會(huì)給你返回錯(cuò)誤，但不保證數(shù)據(jù)最新，強(qiáng)調(diào)的是服務(wù)不出錯(cuò)。
• 分區(qū)容錯(cuò)性：我會(huì)一直運(yùn)行，不管我的內(nèi)部出現(xiàn)何種數(shù)據(jù)同步問題，強(qiáng)調(diào)的是不掛掉。

為了解決數(shù)據(jù)一致性問題，業(yè)界又引入了各種一致性保障機(jī)制，比如BASE理論(基本可用、軟狀態(tài)、最終一致)、分布式事務(wù)DTP模型(XA協(xié)議、TCC協(xié)議)、JTA模型等等，根據(jù)對(duì)數(shù)據(jù)一致性的要求又劃分為強(qiáng)一致性、弱一致性、最終一致性的方案，在分布式系統(tǒng)中通過一系列措施來保證ACID。

在實(shí)際互聯(lián)網(wǎng)項(xiàng)目開發(fā)中，分布式事務(wù)不宜設(shè)計(jì)得太重，通常來說異步的場景使用事務(wù)性MQ來解決，比如RabbitMQ、Kafka、RocketMQ等;同步的場景使用業(yè)務(wù)狀態(tài)機(jī)來規(guī)避它們，比如訂單分正向銷售單、逆向售后單，單據(jù)有不同維度的狀態(tài)，比如支付狀態(tài)、退款狀態(tài)、物流狀態(tài)、開票狀態(tài)等等，對(duì)于出錯(cuò)的環(huán)節(jié)進(jìn)行客戶干預(yù)、系統(tǒng)告警或客服干預(yù)，暫時(shí)停留在異常節(jié)點(diǎn)，這里的“狀態(tài)”可以理解為BASE理論中的軟狀態(tài)。

說到底還是用BASE理論指導(dǎo)生產(chǎn)。

說那么多，我們通過拆分微服務(wù)，提高了系統(tǒng)的分區(qū)容錯(cuò)性與可用性，卻犧牲了單體應(yīng)用的一致性優(yōu)勢(shì)，所以說，不要為了拆而拆，拆服務(wù)也需要合理“動(dòng)機(jī)”，那什么樣的“動(dòng)機(jī)”是合理的呢?

如何合理拆分微服務(wù)?

OK，了解了服務(wù)拆分帶來的問題后，我們拆服務(wù)就得更加嚴(yán)謹(jǐn)了，那怎么合理拆呢?

這里提供一些思路。

一、按單一職責(zé)拆

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

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

我們按照單一職責(zé)的劃分原則，每一個(gè)獨(dú)立的服務(wù)只提供該業(yè)務(wù)領(lǐng)域的核心功能，繼而每個(gè)獨(dú)立的服務(wù)演化出更為豐富的功能，數(shù)據(jù)庫也進(jìn)行垂直拆分提供應(yīng)用獨(dú)立訪問，并且每個(gè)服務(wù)提供雙節(jié)點(diǎn)保證高可用。

二、按團(tuán)隊(duì)組織架構(gòu)拆

這里必須提一提軟件架構(gòu)設(shè)計(jì)中的第一定律——康威定律。

康威定律是馬爾文·康威1967年提出的：“設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)?！蓖ㄋ椎貋碇v：產(chǎn)品必然是其(人員)組織溝通結(jié)構(gòu)的縮影。

康威定律可總結(jié)為以下四個(gè)定律：

第一定律：組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來。

這條定律重點(diǎn)是講組織架構(gòu)和溝通對(duì)系統(tǒng)設(shè)計(jì)的影響。

組織的溝通和系統(tǒng)的設(shè)計(jì)之間緊密相連，特別是復(fù)雜系統(tǒng)，解決好人與人的溝通才能有一個(gè)更好的系統(tǒng)設(shè)計(jì)。

溝通的問題會(huì)帶來系統(tǒng)設(shè)計(jì)的問題，進(jìn)而影響整個(gè)系統(tǒng)的開發(fā)效率和最終產(chǎn)品結(jié)果，這也是為什么互聯(lián)網(wǎng)公司都追求小團(tuán)隊(duì)的原因之一。

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

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

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

再牛的開發(fā)也會(huì)寫出BUG，再全面的測試覆蓋率也無法測出所有的問題，解決方案不是消滅這些問題，是容忍一些問題的存在，然后通過適當(dāng)?shù)脑O(shè)計(jì)(冗余、監(jiān)控、高可用設(shè)計(jì))，當(dāng)問題發(fā)生時(shí)能夠快速解決。

幾個(gè)開發(fā)人員的小公司，去追求微服務(wù)、中臺(tái)架構(gòu)、這是追求完美嗎?

不是，這是找死。

好的架構(gòu)不是買來的，也不是設(shè)計(jì)出來的，而是根據(jù)業(yè)務(wù)落地生根長期演化來的。

第三定律：線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。

這一定律是第一定律的具體應(yīng)用。

想象一下如果公司的架構(gòu)是這樣的：

團(tuán)隊(duì)是分布式，每個(gè)團(tuán)隊(duì)都包含產(chǎn)品、研發(fā)、測試、運(yùn)維等角色，而此時(shí)系統(tǒng)是單體應(yīng)用，那項(xiàng)目溝通和協(xié)調(diào)的成本是巨大的，弄不好還會(huì)打起來。

如果將單塊的系統(tǒng)拆分成微服務(wù)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)自己的部分，對(duì)外提供對(duì)應(yīng)的接口即可，互不干擾，系統(tǒng)效率將得到提升，這與軟件設(shè)計(jì)中的高內(nèi)聚、低耦合是相通的。

直白地說就是想要什么樣的系統(tǒng)就搭建什么樣的團(tuán)隊(duì)，有什么樣的團(tuán)隊(duì)就搭建什么樣的系統(tǒng)，需要前后端分離的系統(tǒng)就搭建前后端分離的團(tuán)隊(duì);反之，擁有前后端分離的團(tuán)隊(duì)就可以設(shè)計(jì)前后端分離的系統(tǒng)。

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

“話說天下大勢(shì)，分久必合，合久必分?！毕到y(tǒng)越復(fù)雜，越需要增加人手，人手越多，溝通成本也呈指數(shù)增長，分而治之便是大多數(shù)公司選擇的解決方案，分不同的層級(jí)，分不同的小團(tuán)隊(duì)，讓團(tuán)隊(duì)內(nèi)部完成自治理，然后統(tǒng)一對(duì)外溝通。

我們?cè)囍鴱目低蓙硗茖?dǎo)系統(tǒng)的架構(gòu)演進(jìn)方向，自然知道微服務(wù)的拆解粒度了。

SOA 也好、微服務(wù)也好，解決的根本問題是團(tuán)隊(duì)分工問題，這是大型軟件發(fā)展的必然，不因?yàn)槿说南埠枚淖?，?dāng)你讀懂康威定律，就會(huì)發(fā)現(xiàn)“服務(wù)拆分粒度難以準(zhǔn)確把握”根本不是本質(zhì)問題，你有幾個(gè) 2 pizza 團(tuán)隊(duì)，最好就拆成幾個(gè)微服務(wù)。

只有一個(gè)開發(fā)人員時(shí)，盡量就做單體應(yīng)用，不要沒事找刺激拆成 10 個(gè)微服務(wù)，最終這個(gè)開發(fā)人員還會(huì)把他合成一個(gè)。

微服務(wù)要求縱向的 2 pizza 團(tuán)隊(duì)(無數(shù)個(gè)小團(tuán)隊(duì)，包含開發(fā)、測試、運(yùn)維)，如果團(tuán)隊(duì)還是處在橫向結(jié)構(gòu)的場景下(開發(fā)、運(yùn)維、測試各是一個(gè)團(tuán)隊(duì))，比如說一些傳統(tǒng)大型企業(yè)，去實(shí)施微服務(wù)會(huì)讓他們很痛苦，尤其是運(yùn)維團(tuán)隊(duì)。

總結(jié)一下

具體實(shí)踐建議：

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

通過MVP的方式來設(shè)計(jì)系統(tǒng)，通過不斷的迭代來驗(yàn)證優(yōu)化，系統(tǒng)應(yīng)該是彈性設(shè)計(jì)的。

你想要什么樣的系統(tǒng)設(shè)計(jì)，就架構(gòu)什么樣的團(tuán)隊(duì)，能扁平化就扁平化。最好按業(yè)務(wù)來劃分團(tuán)隊(duì)，這樣能讓團(tuán)隊(duì)自然的自治內(nèi)聚，明確的業(yè)務(wù)邊界會(huì)減少和外部的溝通成本，每個(gè)小團(tuán)隊(duì)都對(duì)自己的模塊的整個(gè)生命周期負(fù)責(zé)，沒有邊界不清，沒有無效的扯皮，inter-operate, not integrate。

做小而美的團(tuán)隊(duì)，人多會(huì)帶來溝通的成本，讓效率下降。亞馬遜的Bezos有個(gè)逗趣的比喻，如果2個(gè)披薩不夠一個(gè)團(tuán)隊(duì)吃的，那么這個(gè)團(tuán)隊(duì)就太大了。事實(shí)上一般一個(gè)互聯(lián)網(wǎng)公司小產(chǎn)品的團(tuán)隊(duì)差不多就是7，8人左右。

總之，只要說得清楚，運(yùn)維能力又能跟上，服務(wù)拆分一般就是合理的!