微服務該如何拆分

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的拆分一直是歷史性的難題，行業內更是沒有具體的拆分標準，拆分的好壞更多取決於拆分者的經驗，並經過反覆迭代，逐步優化、調整，以達到比較合適的劃分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"本文包括微服務的拆分時機、拆分原則、拆分方法，用於指導微服務的拆分工作，希望能夠對大家有所啓示。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"1.拆分時機","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務拆分絕非是一個大躍進的過程，拆分時機不對，很容易把一個應用拆分的七零八落，最終大大增加運維成本，卻不會帶來明顯收益。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務拆分的過程，是基於某個痛點出發，是業務真正遇到快速迭代和高併發等問題，如果不拆分，將對於業務的發展帶來影響，只有這個時候，微服務的拆分纔是有確定收益的，增加的運維成本纔是值得的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1.1 有快速迭代的需求","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"互聯網時代，業務快速變化，應用的交付需要快速響應式交付。通過微服務架構，採用快速迭代的方式進行架構演進，將系統拆分成多個獨立的微服務，微服務之間彼此獨立，通過服務接口交互。當某個微服務遇到問題時發版修復，不會導致整個系統不可用，從而支撐業務的快速試錯。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1.2 提交代碼頻繁出現大量衝突","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"單體應用開發通常是幾十人開發一個系統，代碼管理時經常會遇到代碼提交衝突。微服務架構通過快速迭代可實現開發獨立，將系統拆分成不同的微服務，每個微服務對外提供接口，其他依賴服務不用關注具體的實現細節，只需保證接口正確即可。每幾個人維護一個服務模塊，降低代碼衝突的概率，出現衝突時也可快速解決。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1.3 小功能要積累到大版本才能上線","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"傳統模式單次上線的需求通常較多、風險較大，小功能的錯誤可能會導致大功能無法上線。因此每次上線都會帶來較大的工作量。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務架構對於快速迭代可帶來獨立上線的效果。微服務拆分後，在服務接口穩定的情況下，不同的微服務可獨立上線。上線的次數增多，單次上線的需求量變小，可隨時回滾，風險變小，時間變短，影響面小，從而加快迭代速度。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1.4 解決高併發橫向擴展問題","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"互聯網時代，業務應用的高併發要求越來越高，單體應用雖然可以通過部署多份承載一定的併發量，但是會造成資源非常浪費。有的業務需要擴容，例如下單和支付，有的業務不需要擴容，例如註冊。如果一起擴容，消耗的資源可能是拆分後的幾倍。因此，對於併發量大的系統，選擇微服務拆分是很有必要的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"2.拆分原則","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"單一職責原則：","attrs":{}},{"type":"text","text":" 每個微服務只需關心自己的業務規則，確保職責單一，避免職責交叉，耦合度過高將會造成代碼修改重合，不利於後期維護。","attrs":{}}]}],"attrs":{}},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"服務自治原則：","attrs":{}},{"type":"text","text":" 每個微服務的開發，必須擁有開發、測試、運維、部署等整個過程，並且擁有自己獨立的數據庫等，可以完全把其當作一個單獨的項目來做，而不牽扯到其他無關業務。","attrs":{}}]}],"attrs":{}},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"輕量級通信原則：","attrs":{}},{"type":"text","text":" 微服務間需通過輕量級通信機制進行交互。首先是體量較輕，其次是需要支持跨平臺、跨語言的通信協議，再次是需要具備操作性強、易於測試等能力，如：REST通信協議。","attrs":{}}]}],"attrs":{}},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"接口明確原則：","attrs":{}},{"type":"text","text":" 明確接口要實現的內容，避免接口依賴，如A接口的改動會導致B接口的改動。","attrs":{}}]}],"attrs":{}},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"持續演進原則：","attrs":{}},{"type":"text","text":" 單體架構向微服務架構拆分過程中，無法做到一蹴而就，剛開始不建議拆分太小，過度拆分將會帶來架構複雜度的急劇升高，開發、測試、運維等環節很難快速適應，將會導致故障率大幅增加，可用性降低，非必要情況，應逐步拆分細化，持續演進，避免微服務數量的瞬間爆炸性增長。","attrs":{}}]}],"attrs":{}}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"3.拆分方法","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的拆分應遵循上述拆分時機、拆分原則，並選擇合適的拆分方法，逐步拆分。在實際拆分過程中，除了要遵循拆分原則，還要從實際業務領域出發，並結合考慮非業務的因素，比如需求變更的頻率、高性能、安全性、團隊規模以及技術異構等因素。這些非業務因素對於最終落地也會起到決定性的作用，因此在微服務拆分時需要重點關注。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.1 業務領域拆分","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基於領域模型，圍繞業務界限上下文邊界，將同類業務劃歸爲一個微服務，按單一職責原則、功能完整性進行微服務的拆分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.2 需求變化頻率","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"需要識別業務需求的變動頻率，考慮業務變化頻率與相關度，將業務需求變動較高和功能相對穩定的業務進一步分離拆分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"因爲需求的經常性變動必然會導致代碼的頻繁修改和版本發佈，這種拆分可以有效降低頻繁發佈版本的業務對不需要經常發佈版本的業務的影響。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.3 服務性能要求","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"需要識別性能壓力較大的業務。因爲對性能指標要求高的業務在資源需求上會比其他業務的高，這樣可能會拖累其他業務，也會造成資源無謂的浪費。爲了降低對系統整體性能和資源要求的影響，我們將對性能方面有較高要求的業務與對性能要求不高的業務進一步拆分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.4 組織架構和團隊規模","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"除非有意識地優化組織架構，否則微服務的拆分應儘量避免對組織架構和團隊的調整，避免由於功能的重新劃分，而增加大量且不必要的團隊之間的溝通成本。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在進行微服務拆分和組建項目團隊時，應儘量將溝通邊界控制在團隊內。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.5 安全邊界","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對於有特殊安全要求的業務，應獨立出來，避免因不同的安全要求，而帶來不必要的成本，或帶來泄密的風險。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"3.6 技術異構","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雖然都是在同一個業務領域內，但由於各種條件的限制，在技術實現時可能會存在較大的差異（存在技術異構的問題）。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大部分都是採用Java語言實現，但由於業務場景或者技術條件的限制，有的可能需要採用Go語言實現，甚至有的採用大數據技術架構。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對應這些存在技術異構的業務功能，可以考慮按照技術棧的邊界進一步拆分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}