大家好，我是不才陳某~

我們知道微服務(wù)是一種理念，沒(méi)有確切的定義和邊界，好比設(shè)計(jì)原則，是屬于抽象的概念。在定義不明確的情況下談劃分也是一種各說(shuō)各話，具體問(wèn)題需要具體分析，所以這篇文章談到的劃分也不是絕對(duì)標(biāo)準(zhǔn)，僅供參考。

有人說(shuō)微服務(wù)不難，難的是服務(wù)的劃分，雖然我持保留意見(jiàn)，但是從側(cè)面也反應(yīng)了劃分具有一定的困難。這里的矛盾在于粒度，如果粒度太大了，分和不分似乎都差不多；如果粒度太小了，聚合、發(fā)布、調(diào)用鏈、調(diào)試等都是坑。

以下談到的拆分是前人經(jīng)驗(yàn)的總結(jié)，我羅列了三種行家的拆分姿勢(shì)，每個(gè)的的經(jīng)驗(yàn)和視野不同，各有偏頗，我在這里更多的是談共鳴和感受，希望對(duì)你有所啟發(fā)。

推薦Java工程師技術(shù)指南：https://github.com/chenjiabing666/JavaFamily

拆分姿勢(shì)

姿勢(shì)一：新浪微博微服務(wù)專家胡忠想從縱橫兩個(gè)維度來(lái)劃分，簡(jiǎn)單粗暴

1. 縱向拆分

從業(yè)務(wù)維度進(jìn)行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來(lái)決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個(gè)微服務(wù)，而功能相對(duì)比較獨(dú)立的業(yè)務(wù)適合單獨(dú)拆分為一個(gè)微服務(wù)。

2. 橫向拆分

從公共且獨(dú)立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個(gè)其他服務(wù)調(diào)用，且依賴的資源獨(dú)立不與其他業(yè)務(wù)耦合。

縱向以業(yè)務(wù)為基準(zhǔn)，關(guān)系鐵的在一起；橫向功能獨(dú)立的在一起。我想如果拆分這么簡(jiǎn)單，你有底氣拆，敢拆嗎？所以我們又繼續(xù)比對(duì)一下其他專家的言論。

?

??

姿勢(shì)二：阿里的小伙伴從綜合的維度來(lái)看，部分維度和上面會(huì)有重合

1. 服務(wù)拆分要迎合業(yè)務(wù)的需要

充分考慮業(yè)務(wù)獨(dú)立性和專業(yè)性，避免以團(tuán)隊(duì)來(lái)定義服務(wù)邊界，從而出現(xiàn)“土匪”搶地盤(pán)，影響團(tuán)隊(duì)信任。

這個(gè)維度和上面的類似，但是強(qiáng)調(diào)的是業(yè)務(wù)和團(tuán)隊(duì)成員的各自獨(dú)立性，對(duì)上面是一種很好的補(bǔ)充。

2. 拆分后的維護(hù)成本要低于拆分前

這里的維護(hù)成本包括：人力、物力、時(shí)間。

這里的成本對(duì)大部分中小團(tuán)隊(duì)來(lái)說(shuō)都是必須要考慮的重要環(huán)節(jié)，如果投入和收益不能成正比，或者超出領(lǐng)導(dǎo)的預(yù)算或者市場(chǎng)窗口，那么先進(jìn)的技術(shù)就是絆腳石，千萬(wàn)不要迷戀技術(shù)，所謂工程師思維千萬(wàn)要不得。關(guān)注公眾號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能優(yōu)化手冊(cè)！

拆分不僅僅是架構(gòu)的調(diào)整，組織結(jié)構(gòu)上也要做響應(yīng)的適應(yīng)性優(yōu)化

確保拆分后的服務(wù)由相對(duì)獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)維護(hù)。

這句話怎么理解呢？傳統(tǒng)的團(tuán)隊(duì)劃分是按照產(chǎn)品部、前端、后端橫向劃分，微服務(wù)化以后的團(tuán)隊(duì)可能就會(huì)是吃一張披薩餅的人數(shù)，產(chǎn)品、前端、后端被歸類到服務(wù)里面，以服務(wù)為中心來(lái)分配人數(shù)。

拆分最有價(jià)值的結(jié)果是提高了系統(tǒng)的可擴(kuò)展性

把具有不同擴(kuò)展性要求的服務(wù)拆分出來(lái)，分別進(jìn)行部署，降低成本，提高效率。比如全文搜索服務(wù)。

這點(diǎn)和上面的按功能獨(dú)立性來(lái)拆分有點(diǎn)類似，功能獨(dú)立其實(shí)就是面向可擴(kuò)展性。

3. 考慮軟件發(fā)布頻率

比如把20%經(jīng)常變動(dòng)的部分進(jìn)行抽離，80%不經(jīng)常變動(dòng)的單獨(dú)部署和管理。說(shuō)白了就是按照8/2原則進(jìn)行拆分。這個(gè)拆分的好處很明顯，可以盡可能的減少發(fā)布產(chǎn)生的后遺癥，比如用戶體驗(yàn)、服務(wù)相互干擾等。關(guān)注公眾號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能優(yōu)化手冊(cè)！

但是這里有一個(gè)問(wèn)題，假如20%的服務(wù)分屬于不同的業(yè)務(wù)層面，那該怎么辦？所以這里的拆分應(yīng)該有個(gè)優(yōu)先級(jí)，在拆分相互沖突的時(shí)候應(yīng)該要優(yōu)先考慮權(quán)重比較高的那個(gè)。?

??

姿勢(shì)三：資深技術(shù)專家李運(yùn)華在他的架構(gòu)書(shū)中給出的拆分

1. 基于業(yè)務(wù)邏輯

將系統(tǒng)中的業(yè)務(wù)按照職責(zé)范圍進(jìn)行識(shí)別，職責(zé)相同的劃分為一個(gè)單獨(dú)的服務(wù)。這種業(yè)務(wù)優(yōu)先的方式在前面兩種姿勢(shì)當(dāng)中都出現(xiàn)過(guò)，可見(jiàn)是最基本，最重要的劃分方式（沒(méi)有之一）。

2. 基于穩(wěn)定性

將系統(tǒng)中的業(yè)務(wù)模塊按照穩(wěn)定性進(jìn)行排序。穩(wěn)定的、不經(jīng)常修改的劃分一塊；將不穩(wěn)定的，經(jīng)常修改的劃分為一個(gè)獨(dú)立服務(wù)。比如日志服務(wù)、監(jiān)控服務(wù)都是相對(duì)穩(wěn)定的服務(wù)，可以歸到一起。這個(gè)很類似上面提到的2/8原則，80%的業(yè)務(wù)是穩(wěn)定的。

至此你會(huì)發(fā)現(xiàn)服務(wù)的拆分真的沒(méi)有絕對(duì)的標(biāo)準(zhǔn)，只有合理才是標(biāo)準(zhǔn)。

3. 基于可靠性

同樣，將系統(tǒng)中的業(yè)務(wù)模塊按照可靠性進(jìn)行排序。對(duì)可靠性要求比較高的核心模塊歸在一起，對(duì)可靠性要求不高的非核心模塊歸在一塊。

這種拆分的高明可以很好的規(guī)避因?yàn)橐活w老鼠屎壞了一鍋粥的單體弊端，同時(shí)將來(lái)要做高可用方案也能很好的節(jié)省機(jī)器或帶寬的成本。

4. 基于高性能

同上，將系統(tǒng)中的業(yè)務(wù)模塊按照對(duì)性能的要求進(jìn)行優(yōu)先級(jí)排序。把對(duì)性能要求較高的模塊獨(dú)立成一個(gè)服務(wù)，對(duì)性能要求不高的放在一起。比如全文搜索，商品查詢和分類，秒殺就屬于高性能的核心模塊。

?

??

姿勢(shì)盤(pán)點(diǎn)：以上不同拆分姿勢(shì)各有千秋，異曲同工

• 對(duì)業(yè)務(wù)邏輯均不約而同的放在第一位
• 對(duì)業(yè)務(wù)模塊的穩(wěn)定性和可靠性，對(duì)功能的獨(dú)立性、可擴(kuò)展性都有相似的看法
• 強(qiáng)調(diào)拆分應(yīng)該是多選，而不是單選。具體情況具體分析，可以自由靈活排列組合。

推薦Java工程師技術(shù)指南：https://github.com/chenjiabing666/JavaFamily，star支持一下！

題外話

如果你把上面的劃分角度背下來(lái)了拿去現(xiàn)場(chǎng)套，可能還會(huì)遇到矛盾或爭(zhēng)議。

業(yè)務(wù)矛盾

假如我們按照業(yè)務(wù)來(lái)劃分，根據(jù)粒度大小，可能存在以下兩種：

• 第一種分為商品、交易、用戶3個(gè)服務(wù)；
• 第二種分為商品、訂單、支付、物流、買(mǎi)家、賣(mài)家6個(gè)服務(wù)。

3 VS 6，這該怎么辦？

如果你的團(tuán)隊(duì)只有9個(gè)人，那么分成3個(gè)是合理的，如果有18個(gè)人，那么6個(gè)服務(wù)是合理的。這里引入團(tuán)隊(duì)成員進(jìn)行協(xié)助拆分。

可見(jiàn)拆分的姿勢(shì)不是單選，而是多選的。這個(gè)時(shí)候必須要考慮團(tuán)隊(duì)成員數(shù)量。

在拆分遇到爭(zhēng)議的時(shí)候，一般情況下我們?cè)黾右豁?xiàng)拆分條件，雖然不是充要條件，但至少我們的答案會(huì)更加接近真理。

除了業(yè)務(wù)可能存在爭(zhēng)議，其他的劃分也會(huì)有爭(zhēng)議，比如一個(gè)獨(dú)立的服務(wù)到底需要多少人員的配置？

推薦Java工程師技術(shù)指南：https://github.com/chenjiabing666/JavaFamily，star支持一下！

三個(gè)火槍手（人員配置）

上面提到的人員數(shù)量配置，這里為什么是9和18呢？（這里的團(tuán)隊(duì)配置參考李云華前輩提到的三個(gè)火槍手的觀點(diǎn)）

換一種問(wèn)法，為什么說(shuō)是三個(gè)人分配一個(gè)服務(wù)（當(dāng)然，成員主要是后端人員）？

• 假設(shè)是1個(gè)人，請(qǐng)個(gè)假、生個(gè)病都不行。一個(gè)人會(huì)遇到單點(diǎn)的問(wèn)題，所以不合理。
• 假設(shè)是2個(gè)人，終于有備份了，但是抽離一個(gè)后，剩下1個(gè)壓力還是很大，不合理。
• 假設(shè)是3個(gè)人，抽離一個(gè)還有2個(gè)在。而且數(shù)字3是個(gè)穩(wěn)定而神奇數(shù)字，用得好事半功倍。特別是遇到技術(shù)討論，3個(gè)人相對(duì)周全，如果是2個(gè)可能會(huì)各持己見(jiàn)，帶有自我的偏見(jiàn)和盲區(qū)。

那么這個(gè)3是不是就是穩(wěn)定的數(shù)量呢？

假設(shè)你做的是邊開(kāi)飛機(jī)邊換引擎的重寫(xiě)工作，那么前期3個(gè)人都可能捉襟見(jiàn)肘。但是到了服務(wù)后期，你可能1個(gè)就夠了。

所以3在我的理解應(yīng)該一個(gè)基準(zhǔn)線，不同的時(shí)間段會(huì)有上下波動(dòng)，但是相對(duì)穩(wěn)定。

?

??