微服務(wù)劃分的正確姿勢，值得學(xué)習(xí)！
作者：張飛洪
https://www.cnblogs.com/jackyfei/p/10856427.html
我們知道微服務(wù)是一種理念，沒有確切的定義和邊界，好比設(shè)計原則，是屬于抽象的概念。在定義不明確的情況下談劃分也是一種各說各話，具體問題需要具體分析，所以這篇文章談到的劃分也不是絕對標(biāo)準(zhǔn)，僅供參考。
有人說微服不難，難的是服務(wù)的劃分，雖然我持保留意見。但是從側(cè)面也反應(yīng)了劃分具有一定的困難。這里的矛盾在于粒度。如果粒度太大了，分和不分似乎都差不多；如果粒度太小了，聚合、發(fā)布、調(diào)用鏈、調(diào)試等都是坑。
以下談到的拆分是前人經(jīng)驗的總結(jié)，我羅列了三種行家的拆分姿勢，每個的的經(jīng)驗和視野不同，各有偏頗，我在這里更多的是談共鳴和感受，希望對你有所啟發(fā)。
一、拆分姿勢
1、姿勢一
新浪微博微服務(wù)專家胡忠想從縱橫兩個維度來劃分，簡單粗暴：
1.1 縱向拆分
從業(yè)務(wù)維度進行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個微服務(wù)，而功能相對比較獨立的業(yè)務(wù)適合單獨拆分為一個微服務(wù)。
1.2 橫向拆分
從公共且獨立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個其他服務(wù)調(diào)用，且依賴的資源獨立不與其他業(yè)務(wù)耦合。
縱向以業(yè)務(wù)為基準(zhǔn)，關(guān)系鐵的在一起；橫向功能獨立的在一起。我想如果拆分這么簡單，你有底氣拆，敢拆嗎？所以我們又繼續(xù)比對一下其他專家的言論。
2、姿勢二
阿里的小伙伴從綜合的維度來看，部分維度和上面會有重合。
2.1 服務(wù)拆分要迎合業(yè)務(wù)的需要
充分考慮業(yè)務(wù)獨立性和專業(yè)性，避免以團隊來定義服務(wù)邊界，從而出現(xiàn)“土匪”搶地盤，影響團隊信任。
這個維度和上面的類似，但是強調(diào)的是業(yè)務(wù)和團隊成員的各自獨立性，對上面是一種很好的補充。
2.2 拆分后的維護成本要低于拆分前
這里的維護成本包括：人力、物力、時間。
這里的成本對大部分中小團隊來說都是必須要考慮的重要環(huán)節(jié)，如果投入和收益不能成正比，或者超出領(lǐng)導(dǎo)的預(yù)算或者市場窗口，那么先進的技術(shù)就是絆腳石，千萬不要迷戀技術(shù)，所謂工程師思維千萬要不得。
2.3 拆分不僅僅是架構(gòu)的調(diào)整，組織結(jié)構(gòu)上也要做響應(yīng)的適應(yīng)性優(yōu)化
確保拆分后的服務(wù)由相對獨立的團隊負責(zé)維護。
這句話怎么理解呢？傳統(tǒng)的團隊劃分是按照產(chǎn)品部、前端、后端橫向劃分，微服務(wù)化以后的團隊可能就會是吃一張披薩餅的人數(shù)，產(chǎn)品、前端、后端被歸類到服務(wù)里面，以服務(wù)為中心來分配人數(shù)。《微服務(wù)為什么選Spring Cloud？》推薦大家閱讀。
2.4 拆分最有價值的結(jié)果是提高了系統(tǒng)的可擴展性
把具有不同擴展性要求的服務(wù)拆分出來，分別進行部署，降低成本，提高效率。比如全文搜索服務(wù)。
這點和上面的按功能獨立性來拆分有點類似，功能獨立其實就是面向可擴展性。
2.5 考慮軟件發(fā)布頻率
比如把20%經(jīng)常變動的部分進行抽離，80%不經(jīng)常變動的單獨部署和管理。說白了就是按照8/2原則進行拆分。這個拆分的好處很明顯，可以盡可能的減少發(fā)布產(chǎn)生的后遺癥，比如用戶體驗、服務(wù)相互干擾等。推薦閱讀：微服務(wù)架構(gòu)如何保證安全性？
但是這里有一個問題，假如20%的服務(wù)分屬于不同的業(yè)務(wù)層面，那該怎么辦？所以這里的拆分應(yīng)該有個優(yōu)先級，在拆分相互沖突的時候應(yīng)該要優(yōu)先考慮權(quán)重比較高的那個。
3、姿勢三
資深技術(shù)專家李運華在他的架構(gòu)書中給出的拆分：
3.1 基于業(yè)務(wù)邏輯
將系統(tǒng)中的業(yè)務(wù)按照職責(zé)范圍進行識別，職責(zé)相同的劃分為一個單獨的服務(wù)。這種業(yè)務(wù)優(yōu)先的方式在前面兩種姿勢當(dāng)中都出現(xiàn)過，可見是最基本，最重要的劃分方式（沒有之一）。
3.2 基于穩(wěn)定性
將系統(tǒng)中的業(yè)務(wù)模塊按照穩(wěn)定性進行排序。穩(wěn)定的、不經(jīng)常修改的劃分一塊；將不穩(wěn)定的，經(jīng)常修改的劃分為一個獨立服務(wù)。比如日志服務(wù)、監(jiān)控服務(wù)都是相對穩(wěn)定的服務(wù)，可以歸到一起。這個很類似上面提到的2/8原則，80%的業(yè)務(wù)是穩(wěn)定的。
至此你會發(fā)現(xiàn)服務(wù)的拆分真的沒有絕對的標(biāo)準(zhǔn)，只有合理才是標(biāo)準(zhǔn)。
3.3 基于可靠性
同樣，將系統(tǒng)中的業(yè)務(wù)模塊按照可靠性進行排序。對可靠性要求比較高的核心模塊歸在一起，對可靠性要求不高的非核心模塊歸在一塊。
這種拆分的高明可以很好的規(guī)避因為一顆老鼠屎壞了一鍋粥的單體弊端，同時將來要做高可用方案也能很好的節(jié)省機器或帶寬的成本。
3.4 基于高性能
同上，將系統(tǒng)中的業(yè)務(wù)模塊按照對性能的要求進行優(yōu)先級排序。把對性能要求較高的模塊獨立成一個服務(wù)，對性能要求不高的放在一起。比如全文搜索，商品查詢和分類，秒殺就屬于高性能的核心模塊。
4、姿勢盤點
以上不同拆分姿勢各有千秋，異曲同工！
對業(yè)務(wù)邏輯均不約而同的放在第一位。
對業(yè)務(wù)模塊的穩(wěn)定性和可靠性，對功能的獨立性、可擴展性都有相似的看法
強調(diào)拆分應(yīng)該是多選，而不是單選。具體情況具體分析，可以自由靈活排列組合。
二、題外話
如果你把上面的劃分角度背下來了拿去現(xiàn)場套，可能還會遇到矛盾或爭議。
1、業(yè)務(wù)矛盾
假如我們按照業(yè)務(wù)來劃分，根據(jù)粒度大小，可能存在以下兩種：
第一種分為商品、交易、用戶3個服務(wù)；
第二種分為商品、訂單、支付、物流、買家、賣家6個服務(wù)。
3 VS 6，這該怎么辦？
如果你的團隊只有9個人，那么分成3個是合理的，如果有18個人，那么6個服務(wù)是合理的。這里引入團隊成員進行協(xié)助拆分。
可見拆分的姿勢不是單選，而是多選的。這個時候必須要考慮團隊成員數(shù)量。
在拆分遇到爭議的時候，一般情況下我們增加一項拆分條件，雖然不是充要條件，但至少我們的答案會更加接近真理。
除了業(yè)務(wù)可能存在爭議，其他的劃分也會有爭議，比如一個獨立的服務(wù)到底需要多少人員的配置？
2、三個火槍手(人員配置)
上面提到的人員數(shù)量配置，這里為什么是9和18呢？(這里的團隊配置參考李云華前輩提到的三個火槍手的觀點)
換一種問法，為什么說是三個人分配一個服務(wù)（當(dāng)然，成員主要是后端人員）？
假設(shè)是1個人，請個假、生個病都不行。一個人會遇到單點的問題，所以不合理。
假設(shè)是2個人，終于有備份了，但是抽離一個后，剩下1個壓力還是很大，不合理。
假設(shè)是3個人，抽離一個還有2個在。而且數(shù)字3是個穩(wěn)定而神奇數(shù)字，用得好事半功倍。特別是遇到技術(shù)討論，3個人相對周全，如果是2個可能會各持己見，帶有自我的偏見和盲區(qū)。
那么這個3是不是就是穩(wěn)定的數(shù)量呢？
假設(shè)你做的是邊開飛機邊換引擎的重寫工作，那么前期3個人都可能捉襟見肘。但是到了服務(wù)后期，你可能1個就夠了。
所以3在我的理解應(yīng)該是一個基準(zhǔn)線，不同的時間段會有上下波動，但是相對穩(wěn)定。
-- end --
喜歡就三連呀
點擊"閱讀原文"可跳轉(zhuǎn)至我的博客。
【今日短語】
人若軟弱就是自己最大的敵人；人若勇敢就是自己最好的朋友。
關(guān)注 Stephen，一起學(xué)習(xí)，一起成長。