微服務的拆分一直是歷史性的難題，行業內更是沒有具體的拆分標準，拆分的好壞更多取決於拆分者的經驗，並通過反覆迭代，逐步優化、調整，以達到比較合適的劃分。web
數據庫
本文包括微服務的拆分時機、拆分原則、拆分方法，用於指導微服務的拆分工做，但願可以對你們有所啓示。後端
安全
微服務拆分絕非是一個大躍進的過程，拆分時機不對，很容易把一個應用拆分的七零八落，最終大大增長運維成本，卻不會帶來明顯收益。微信
架構
微服務拆分的過程，是基於某個痛點出發，是業務真正遇到快速迭代和高併發等問題，若是不拆分，將對於業務的發展帶來影響，只有這個時候，微服務的拆分纔是有肯定收益的，增長的運維成本纔是值得的。併發
有快速迭代的需求app
互聯網時代，業務快速變化，應用的交付須要快速響應式交付。經過微服務架構，採用快速迭代的方式進行架構演進，將系統拆分紅多個獨立的微服務，微服務之間彼此獨立，經過服務接口交互。當某個微服務遇到問題時發版修復，不會致使整個系統不可用，從而支撐業務的快速試錯。運維
提交代碼頻繁出現大量衝突
編輯器
單體應用開發一般是幾十人開發一個系統，代碼管理時常常會遇到代碼提交衝突。微服務架構經過快速迭代可實現開發獨立，將系統拆分紅不一樣的微服務，每一個微服務對外提供接口，其餘依賴服務不用關注具體的實現細節，只需保證接口正確便可。每幾我的維護一個服務模塊，下降代碼衝突的機率，出現衝突時也可快速解決。
小功能要積累到大版本才能上線
傳統模式單次上線的需求一般較多、風險較大，小功能的錯誤可能會致使大功能沒法上線。所以每次上線都會帶來較大的工做量。
微服務架構對於快速迭代可帶來獨立上線的效果。微服務拆分後，在服務接口穩定的狀況下，不一樣的微服務可獨立上線。上線的次數增多，單次上線的需求量變小，可隨時回滾，風險變小，時間變短，影響面小，從而加快迭代速度。
解決高併發橫向擴展問題
互聯網時代，業務應用的高併發要求愈來愈高，單體應用雖然能夠經過部署多份承載必定的併發量，可是會形成資源很是浪費。有的業務須要擴容，例以下單和支付，有的業務不須要擴容，例如註冊。若是一塊兒擴容，消耗的資源多是拆分後的幾倍。所以，對於併發量大的系統，選擇微服務拆分是頗有必要的。
單一職責原則： 每一個微服務只需關心本身的業務規則，確保職責單一，避免職責交叉，耦合度太高將會形成代碼修改重合，不利於後期維護。
服務自治原則：每一個微服務的開發，必須擁有開發、測試、運維、部署等整個過程，而且擁有本身獨立的數據庫等，能夠徹底把其看成一個單獨的項目來作，而不牽扯到其餘無關業務。
輕量級通訊原則：微服務間需經過輕量級通訊機制進行交互。首先是體量較輕，其次是須要支持跨平臺、跨語言的通訊協議，再次是須要具有操做性強、易於測試等能力，如：REST通訊協議。
接口明確原則：明確接口要實現的內容，避免接口依賴，如A接口的改動會致使B接口的改動。
持續演進原則：單體架構向微服務架構拆分過程當中，沒法作到一蹴而就，剛開始不建議拆分過小，過分拆分將會帶來架構複雜度的急劇升高，開發、測試、運維等環節很難快速適應，將會致使故障率大幅增長，可用性下降，非必要狀況，應逐步拆分細化，持續演進，避免微服務數量的瞬間爆炸性增加。
微服務的拆分應遵循上述拆分時機、拆分原則，並選擇合適的拆分方法，逐步拆分。在實際拆分過程當中，除了要遵循拆分原則，還要從實際業務領域出發，並結合考慮非業務的因素，好比需求變動的頻率、高性能、安全性、團隊規模以及技術異構等因素。這些非業務因素對於最終落地也會起到決定性的做用，所以在微服務拆分時須要重點關注。
業務領域拆分
基於領域模型，圍繞業務界限上下文邊界，將同類業務劃歸爲一個微服務，按單一職責原則、功能完整性進行微服務的拆分。
需求變化頻率
須要識別業務需求的變更頻率，考慮業務變化頻率與相關度，將業務需求變更較高和功能相對穩定的業務進一步分離拆分。
由於需求的常常性變更必然會致使代碼的頻繁修改和版本發佈，這種拆分能夠有效下降頻繁發佈版本的業務對不須要常常發佈版本的業務的影響。
服務性能要求
須要識別性能壓力較大的業務。由於對性能指標要求高的業務在資源需求上會比其餘業務的高，這樣可能會拖累其餘業務，也會形成資源無謂的浪費。爲了下降對系統總體性能和資源要求的影響，咱們將對性能方面有較高要求的業務與對性能要求不高的業務進一步拆分。
組織架構和團隊規模
除非有意識地優化組織架構，不然微服務的拆分應儘可能避免對組織架構和團隊的調整，避免因爲功能的從新劃分，而增長大量且沒必要要的團隊之間的溝通成本。
在進行微服務拆分和組建項目團隊時，應儘可能將溝通邊界控制在團隊內。
安全邊界
對於有特殊安全要求的業務，應獨立出來，避免因不一樣的安全要求，而帶來沒必要要的成本，或帶來泄密的風險。
技術異構
雖然都是在同一個業務領域內，但因爲各類條件的限制，在技術實現時可能會存在較大的差別（存在技術異構的問題）。
大部分都是採用Java語言實現，但因爲業務場景或者技術條件的限制，有的可能須要採用Go語言實現，甚至有的採用大數據技術架構。
對應這些存在技術異構的業務功能，能夠考慮按照技術棧的邊界進一步拆分。
- END -
往期回顧
點一下在看再走吧
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。