我們知道微服務是一種理念，沒有确切的定義和邊界，好比設計原則，是屬于抽象的概念。在定義不明确的情況下談劃分也是一種各說各話，具體問題需要具體分析，是以這篇文章談到的劃分也不是絕對标準，僅供參考。
有人說微服不難，難的是服務的劃分，雖然我持保留意見。但是從側面也反應了劃分具有一定的困難。這裡的沖突在于粒度。如果粒度太大了，分和不分似乎都差不多；如果粒度太小了，聚合、釋出、調用鍊、調試等都是坑。
以下談到的拆分是前人經驗的總結，我羅列了三種行家的拆分姿勢，每個的的經驗和視野不同，各有偏頗，我在這裡更多的是談共鳴和感受，希望對你有所啟發。
一、拆分姿勢
1、姿勢一
新浪微網誌微服務專家胡忠想從縱橫兩個次元來劃分，簡單粗暴：
1.1 縱向拆分
從業務次元進行拆分。标準是按照業務的關聯程度來決定，關聯比較密切的業務适合拆分為一個微服務，而功能相對比較獨立的業務适合單獨拆分為一個微服務。
1.2 橫向拆分
從公共且獨立功能次元拆分。标準是按照是否有公共的被多個其他服務調用，且依賴的資源獨立不與其他業務耦合。
縱向以業務為基準，關系鐵的在一起；橫向功能獨立的在一起。我想如果拆分這麼簡單，你有底氣拆，敢拆嗎？是以我們又繼續比對一下其他專家的言論。
2、姿勢二
阿裡的小夥伴從綜合的次元來看，部分次元和上面會有重合。
2.1 服務拆分要迎合業務的需要
充分考慮業務獨立性和專業性，避免以團隊來定義服務邊界，進而出現“土匪”搶地盤，影響團隊信任。
這個次元和上面的類似，但是強調的是業務和團隊成員的各自獨立性，對上面是一種很好的補充。
2.2 拆分後的維護成本要低于拆分前
這裡的維護成本包括：人力、物力、時間。
這裡的成本對大部分中小團隊來說都是必須要考慮的重要環節，如果投入和收益不能成正比，或者超出上司的預算或者市場視窗，那麼先進的技術就是絆腳石，千萬不要迷戀技術，所謂工程師思維千萬要不得。
2.3 拆分不僅僅是架構的調整，組織結構上也要做響應的适應性優化
確定拆分後的服務由相對獨立的團隊負責維護。
這句話怎麼了解呢？傳統的團隊劃分是按照産品部、前端、後端橫向劃分，微服務化以後的團隊可能就會是吃一張披薩餅的人數，産品、前端、後端被歸類到服務裡面，以服務為中心來配置設定人數。《微服務為什麼選Spring Cloud？》推薦大家閱讀。
2.4 拆分最有價值的結果是提高了系統的可擴充性
把具有不同擴充性要求的服務拆分出來，分别進行部署，降低成本，提高效率。比如全文搜尋服務。
這點和上面的按功能獨立性來拆分有點類似，功能獨立其實就是面向可擴充性。
2.5 考慮軟體釋出頻率
比如把20%經常變動的部分進行抽離，80%不經常變動的單獨部署和管理。說白了就是按照8/2原則進行拆分。這個拆分的好處很明顯，可以盡可能的減少釋出産生的後遺症，比如使用者體驗、服務互相幹擾等。推薦閱讀：微服務架構如何保證安全性？
但是這裡有一個問題，假如20%的服務分屬于不同的業務層面，那該怎麼辦？是以這裡的拆分應該有個優先級，在拆分互相沖突的時候應該要優先考慮權重比較高的那個。
3、姿勢三
資深技術專家李運華在他的架構書中給出的拆分：
3.1 基于業務邏輯
将系統中的業務按照職責範圍進行識别，職責相同的劃分為一個單獨的服務。這種業務優先的方式在前面兩種姿勢當中都出現過，可見是最基本，最重要的劃分方式（沒有之一）。
3.2 基于穩定性
将系統中的業務子產品按照穩定性進行排序。穩定的、不經常修改的劃分一塊；将不穩定的，經常修改的劃分為一個獨立服務。比如日志服務、監控服務都是相對穩定的服務，可以歸到一起。這個很類似上面提到的2/8原則，80%的業務是穩定的。
至此你會發現服務的拆分真的沒有絕對的标準，隻有合理才是标準。
3.3 基于可靠性
同樣，将系統中的業務子產品按照可靠性進行排序。對可靠性要求比較高的核心子產品歸在一起，對可靠性要求不高的非核心子產品歸在一塊。
這種拆分的高明可以很好的規避因為一顆老鼠屎壞了一鍋粥的單體弊端，同時将來要做高可用方案也能很好的節省機器或帶寬的成本。
3.4 基于高性能
同上，将系統中的業務子產品按照對性能的要求進行優先級排序。把對性能要求較高的子產品獨立成一個服務，對性能要求不高的放在一起。比如全文搜尋，商品查詢和分類，秒殺就屬于高性能的核心子產品。
4、姿勢盤點
以上不同拆分姿勢各有千秋，異曲同工！
對業務邏輯均不約而同的放在第一位。
對業務子產品的穩定性和可靠性，對功能的獨立性、可擴充性都有相似的看法
強調拆分應該是多選，而不是單選。具體情況具體分析，可以自由靈活排列組合。
**二、題外話
**
如果你把上面的劃分角度背下來了拿去現場套，可能還會遇到沖突或争議。
1、業務沖突
假如我們按照業務來劃分，根據粒度大小，可能存在以下兩種：
第一種分為商品、交易、使用者3個服務；
第二種分為商品、訂單、支付、物流、買家、賣家6個服務。
3 VS 6，這該怎麼辦？
如果你的團隊隻有9個人，那麼分成3個是合理的，如果有18個人，那麼6個服務是合理的。這裡引入團隊成員進行協助拆分。
可見拆分的姿勢不是單選，而是多選的。這個時候必須要考慮團隊成員數量。
在拆分遇到争議的時候，一般情況下我們增加一項拆分條件，雖然不是充要條件，但至少我們的答案會更加接近真理。
除了業務可能存在争議，其他的劃分也會有争議，比如一個獨立的服務到底需要多少人員的配置？
2、三個火槍手(人員配置)
上面提到的人員數量配置，這裡為什麼是9和18呢？(這裡的團隊配置參考李雲華前輩提到的三個火槍手的觀點)
換一種問法，為什麼說是三個人配置設定一個服務（當然，成員主要是後端人員）？
假設是1個人，請個假、生個病都不行。一個人會遇到單點的問題，是以不合理。
假設是2個人，終于有備份了，但是抽離一個後，剩下1個壓力還是很大，不合理。
假設是3個人，抽離一個還有2個在。而且數字3是個穩定而神奇數字，用得好事半功倍。特别是遇到技術讨論，3個人相對周全，如果是2個可能會各持己見，帶有自我的偏見和盲區。
那麼這個3是不是就是穩定的數量呢？
假設你做的是邊開飛機邊換引擎的重寫工作，那麼前期3個人都可能捉襟見肘。但是到了服務後期，你可能1個就夠了。
是以3在我的了解應該是一個基準線，不同的時間段會有上下波動，但是相對穩定。
推薦去我的部落格閱讀更多：
1.Java JVM、集合、多線程、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、後端、架構、阿裡巴巴等大廠最新面試題
覺得不錯，别忘了點贊+轉發哦！