微服務劃分的姿式

咱們知道微服務是一種理念，沒有確切的定義和邊界，比如設計原則，是屬於抽象的概念。在定義不明確的狀況下談劃分也是一種各說各話，具體問題須要具體分析，因此這篇文章談到的劃分也不是絕對標準，僅供參考。

　　有人說微幅不難，難的是服務的劃分，雖然我持保留意見。可是從側面也反應了劃分具備必定的困難。這裏的矛盾在於粒度。若是粒度太大了，分和不分彷佛都差很少；若是粒度過小了，聚合、發佈、調用鏈、調試等都是坑。

　　如下談到的拆分是前人經驗的總結，我羅列了三種行家的拆分姿式，每一個的的經驗和視野不一樣，各有偏頗，我在這裏更多的是談共鳴和感覺，但願對你有所啓發。

1、拆分姿式

1.姿式一：

　　新浪微博微服務專家胡忠想從縱橫兩個維度來劃分，簡單粗暴：

1.1 縱向拆分

　　從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分爲一個微服務，而功能相對比較獨立的業務適合單獨拆分爲一個微服務。

1.2 橫向拆分

　　從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其餘服務調用，且依賴的資源獨立不與其餘業務耦合。

　　縱向以業務爲基準，關係鐵的在一塊兒；橫向功能獨立的在一塊兒。我想若是拆分這麼簡單，你有底氣拆，敢拆嗎？因此咱們又繼續比對一下其餘專家的言論。

 

2.姿式二：

　　阿里的小夥伴從綜合的維度來看，部分維度和上面會有重合。

2.1 服務拆分要迎合業務的須要

　　充分考慮業務獨立性和專業性，避免以團隊來定義服務邊界，從而出現「土匪」搶地盤，影響團隊信任。

　　這個維度和上面的相似，可是強調的是業務和團隊成員的各自獨立性，對上面是一種很好的補充。

2.2 拆分後的維護成本要低於拆分前

　　這裏的維護成本包括：人力、物力、時間。

　　這裏的成本對大部分中小團隊來講都是必需要考慮的重要環節，若是投入和收益不能成正比，或者超出領導的預算或者市場窗口，那麼先進的技術就是絆腳石，千萬不要迷戀技術，所謂工程師思惟千萬要不得。

2.3 拆分不只僅是架構的調整，組織結構上也要作響應的適應性優化

　　確保拆分後的服務由相對獨立的團隊負責維護。

　　這句話怎麼理解呢？傳統的團隊劃分是按照產品部、前端、後端橫向劃分，微服務化之後的團隊可能就會是吃一張披薩餅的人數，產品、前端、後端被歸類到服務裏面，以服務爲中心來分配人數。

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在個人理解應該是一個基準線，不一樣的時間段會有上下波動，可是相對穩定。