建站
咨詢
售后
建站咨詢
新聞中心
微服務劃分模式
10年積累的成都網(wǎng)站建設、網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有科爾沁右翼前免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
雖然服務是逐步被拆分出來的，隨著業(yè)務的演進，在某一時刻，可能需要我們重新審視服務劃分得是否合理。本節(jié)向大家推薦兩種服務劃分的方法，首先介紹如何選擇服務劃分的方法。
基于業(yè)務復雜度選擇服務劃分方法
根據(jù)業(yè)務復雜度劃分服務，如圖2-4所示。當業(yè)務復雜度足夠高的時候，應該基于領域驅動劃分服務，而領域驅動本身足夠復雜，很多概念比較抽象，應用范圍并不是特別廣泛，所以當業(yè)務復雜度較低時，可以選擇基于數(shù)據(jù)驅動劃分服務。數(shù)據(jù)驅動更容易理解和上手。也就是說，除非業(yè)務復雜度非常高，否則應該優(yōu)先以數(shù)據(jù)驅動劃分服務。這里的業(yè)務復雜度專指業(yè)務邏輯，而非數(shù)據(jù)量、并發(fā)量等相關復雜度。
圖2-4 根據(jù)業(yè)務復雜度劃分服務
在做出選擇的時候，還有一個參考指標是，團隊以前是否已經(jīng)基于領域驅動開發(fā)業(yè)務。也就是說，如果產(chǎn)品已經(jīng)基于領域驅動開發(fā)了一段時間，團隊具備了領域驅動開發(fā)的能力，那么推薦繼續(xù)選擇領域驅動劃分服務。如果是一個全新的產(chǎn)品，則可以靈活選擇。
選擇服務劃分的方法時要重點考慮如下條件。
- 業(yè)務復雜度。
- 團隊對領域驅動的熟悉程度。
基于數(shù)據(jù)驅動劃分服務
數(shù)據(jù)驅動是一個自下而上的架構設計方法，數(shù)據(jù)驅動強調的是數(shù)據(jù)結構，也就是通過分析需求，確定整體數(shù)據(jù)結構，根據(jù)表之間的關系劃分服務。
通常基于數(shù)據(jù)驅動劃分服務的步驟如下。
(1)需求分析。通過領域專家(或者產(chǎn)品經(jīng)理)確定目標，然后總結User Story，確定核心的業(yè)務流程;通過工具呈現(xiàn)比較粗糙的界面，進行內部討論;不斷迭代此環(huán)節(jié)，直到滿意為止。
(2)抽象數(shù)據(jù)結構。根據(jù)需求總結Use Case，協(xié)助分析需求，從中抽象數(shù)據(jù)結構。
(3)劃分服務。分析數(shù)據(jù)結構，識別服務——服務應該滿足高內聚、低耦合、單一職責等特征。
(4)確定服務調用關系。先分析出主要流程，根據(jù)請求需要調用的服務確定服務調用關系。如果存在問題，則需要回到(1)重新開始。
(5)業(yè)務流程驗證。重新回到User Story，以服務為粒度實現(xiàn)時序圖，注意此階段重點是驗證服務劃分是否合適，要關注如下問題。
- 一次更新操作如果要跨越更多服務，那么一致性的要求是什么。
- 跨服務查詢時，是否要做關聯(lián)查詢，一個服務內是否能解決問題。
- 性能是否能滿足要求。
- 成本是否滿足要求。
(6)持續(xù)優(yōu)化。
基于領域驅動劃分服務
領域驅動是一個自上而下的架構設計方法，通過和領域專家建立統(tǒng)一的語言，不斷交流，確定關鍵業(yè)務場景，逐步確定邊界上下文。領域驅動更強調業(yè)務實現(xiàn)效果，認為自下而上的設計可能會導致技術人員不能更好地理解業(yè)務方向，進而偏離業(yè)務目標。
通?；陬I域驅動劃分服務的步驟如下。
(1)通過模型和領域專家建立統(tǒng)一語言。建立統(tǒng)一語言是為了更深入地理解需求。通用語言盡量以業(yè)務語言為主，而非技術語言;通用語言和代碼一樣，需要不斷地重構。
(2)業(yè)務分析。確定核心的業(yè)務流程，然后逐步擴展到全部。最好通過工具呈現(xiàn)比較粗糙的界面，供內部討論。
(3)尋找聚合。顯式地定義領域模型的邊界。最近比較熱門的事件風暴，是一種基于領域驅動分析業(yè)務、劃分服務的方法。
事件風暴就是把所有的關鍵參與者都召集到一個很寬敞的屋子里來開會，并且使用便利貼來描述系統(tǒng)中發(fā)生的事情，如圖2-5所示。
圖2-5 事件風暴
- 用桔黃色的便利貼代表領域事件，在上面用一句話描述曾經(jīng)發(fā)生過什么事情。
- 用藍色的便利貼代表命令。命令的發(fā)起者可能是人，也可能是注入系統(tǒng)中的外部事件，或者定時器等。
- 用黃色的便利貼代表聚合。聚合是一組相關領域對象的集合，高內聚、低耦合是其基本要求，聚合內還要保證數(shù)據(jù)一致性。
(4)確定服務調用關系。先分析出主要流程，根據(jù)一次請求需要調用的服務來確定服務調用關系。如果存在水平劃分，則需要根據(jù)服務依賴原則確定關系。如果存在問題，則需要回到(1)重新開始。
(5)業(yè)務流程驗證。以服務為粒度實現(xiàn)時序圖，注意此階段重點是要驗證服務劃分是否合適，主要關注如下問題。
- 一次更新操作如果要跨越更多服務，那么一致性的要求是什么。
- 跨服務查詢時，是否要做關聯(lián)查詢，一個服務內是否能解決問題。
- 性能是否能滿足要求。
- 成本是否滿足要求。
(6)持續(xù)優(yōu)化。
從已有單體架構中逐步劃分服務
在大多數(shù)場景下，并非從開始階段就采用微服務架構，而是隨著業(yè)務不斷發(fā)展，從最初的單體架構中逐步拆分服務。下面描述了從一個單體架構逐步拆分的步驟。
(1)所有微服務成功的故事都是從一個單體架構太大，需要被拆散開始的，如圖2-6所示。我們應該從單體架構開始，當系統(tǒng)規(guī)模足夠大、團隊人數(shù)足夠多時，再逐步拆分服務，通常前后端分離是拆分的第一步。
圖2-6 從已有架構逐步拆分服務(一)
(2)提取公共基礎服務，如單點登錄。拆分可以遵循邏輯分離和物理分離兩種方法。另外隨著系統(tǒng)壓力的增加，可能會用到消息中間件、分布式緩存等服務。
(3)不斷地從老系統(tǒng)中抽象出服務，垂直劃分優(yōu)先，如圖2-7所示。
圖2-7 從已有架構逐步拆分服務(二)
(4)當業(yè)務越來越復雜的時候，API Gateway做了太多的事情，會成為一個瓶頸點，服務之間的依賴關系也會變得越來越復雜，此時，需要適當?shù)剡M行水平切分，如圖2-8所示。
圖2-8 從已有架構逐步拆分服務(三)
微服務拆分策略
當不斷從單體架構中抽象服務的時候，哪些服務優(yōu)先被拆分，哪些服務不需要被拆分?以下幾個策略可以幫助解決拆分中的這些問題。
- 比較獨立的新業(yè)務優(yōu)先采用微服務架構。從成本角度考慮，新業(yè)務采用新的架構是最合理的，因為這樣做對老業(yè)務的影響最小。
- 優(yōu)先抽象通用服務。因為通常通用服務的邊界比較明顯，耦合度低，比較容易分離。
- 優(yōu)先抽象比較容易識別的、邊界比較明顯的服務。如果原有包結構比較清晰，可以基于原有包結構中有明顯邊界的、比較完整的業(yè)務進行劃分，這是從成本角度考慮。如果已經(jīng)基于單體架構開發(fā)了一段時間，對業(yè)務的理解程度已經(jīng)非常高，那么開發(fā)及架構人員能夠比較容易地提煉出一些邊界比較明顯的服務。
- 優(yōu)先抽象核心服務。因為微服務的開發(fā)及運維成本比較高，并不是所有的地方都需要劃分很小的粒度。往往一些比較邊緣的運營、管理的系統(tǒng)甚至不會考慮拆分。另外，隨著時間的推移，有一些業(yè)務可能會發(fā)生改變，因此應該先抽象出核心服務。
- 優(yōu)先抽象具有獨立屬性的服務。應根據(jù)功能的變更頻率、資源占用、技術棧等屬性劃分服務。
- 采用絞殺者模式，在遺留系統(tǒng)外圍，隨著時間的推移，讓新的服務逐漸“絞殺”老的系統(tǒng)。在這種情況下，復雜度往往體現(xiàn)在如何灰度發(fā)布、遷移數(shù)據(jù)，以及如何保障服務不中斷，后面的章節(jié)會詳細描述。
如何衡量服務劃分的合理性
每個產(chǎn)品在實施微服務架構最初的動力都不一樣，目標也有所區(qū)別，所以判斷是否劃分合理，首先要看是否達成了目標。其次，可以參考以下幾種衡量方式。每種衡量方式不能單獨作為一個判斷標準，需要綜合考慮。
- 一個小功能的修改從需求到上線需要多長時間?正常情況下的微服務架構交付周期應該是以天為單位的。如果一個小功能的修改需要幾周到幾個月的時間，可能意味著服務劃分粒度過大，存在太多的沖突，要等待合并代碼。
- 大多數(shù)功能修改是否可以在一個服務內完成?如果經(jīng)常需要跨服務團隊的聯(lián)合開發(fā)組才能完成一個新功能的開發(fā)或者舊功能的修改，則說明服務劃分存在問題。
- 是否要頻繁修改接口?頻繁修改接口有可能是接口設計不合理導致的，也有可能是服務劃分的問題導致的，說明服務之間的邊界并不是特別明確和穩(wěn)定。
- 響應時間是否能滿足要求?在某些追求極致性能的場景中，對響應時間要求較高，服務劃分的層次太多、粒度太小都可能導致響應時間不能滿足要求。
- 是否存在大量的跨服務更新?是否存在大量的跨服務的關聯(lián)查詢?出現(xiàn)這兩個問題，可能是因為劃分不合理。
微服務劃分反模式
前面我們介紹了如何劃分服務，在此之上，我們希望通過微服務劃分的反模式來幫助大家少走彎路。
根據(jù)代碼行數(shù)劃分服務
代碼規(guī)模太大會導致溝通效率、交付效率低下，耦合度高，以及比較笨重。代碼規(guī)?？梢宰鳛橐粋€參考，但是不能作為一個絕對標準，微服務架構中存在一個“大服務”是很正常的?；诖a行數(shù)拆分服務很難衡量服務的完整性，容易導向更小的拆分粒度，引起不必要的復雜度。
劃分粒度越小越好
服務的大小并不是特別重要，可以根據(jù)團隊規(guī)模、代碼規(guī)模、業(yè)務復雜度、技術領域、重要程度、成本等因素綜合考慮。關于服務粒度的大小，業(yè)界并沒有統(tǒng)一標準，也很難衡量，最接近的衡量標準是研發(fā)團隊規(guī)模。粒度小意味著更高的維護成本。后端管理、輔助系統(tǒng)通常粒度較大。
一次性劃分服務
拆分服務有如下兩種方式。
第一種，先拆分業(yè)務代碼再拆分數(shù)據(jù)庫。如圖2-9所示，數(shù)據(jù)庫并沒有拆分，只是從單體中抽象出部分服務。
圖2-9 先拆分業(yè)務代碼再拆分數(shù)據(jù)庫
第二種，業(yè)務代碼和數(shù)據(jù)庫同步拆分。如圖2-10所示，部分業(yè)務服務被拆分出來的同時，數(shù)據(jù)庫也被同步拆分出來。
圖2-10 業(yè)務代碼和數(shù)據(jù)庫同步拆分
采用第二種方式拆分服務時，根據(jù)服務將數(shù)據(jù)庫徹底拆分為多個獨立的數(shù)據(jù)庫，每個服務獨享數(shù)據(jù)庫服務，服務之間只能通過接口調用。這看起來非常美好，但需要為此做大量的數(shù)據(jù)遷移。當業(yè)務處于初期，需求不是非常確定，開發(fā)人員對業(yè)務理解不是特別透徹的時候，可能拆分后發(fā)現(xiàn)拆分得并不合理，只能再進行合并，又要進行一次數(shù)據(jù)遷移。相對來說，業(yè)務代碼拆分成本更低，而數(shù)據(jù)遷移的成本更高，頻繁、大量的數(shù)據(jù)遷移并不可取。
更好的做法是把第一種方式作為過渡階段，當業(yè)務逐步穩(wěn)定后再徹底進行數(shù)據(jù)遷移。注意，處于過渡階段時數(shù)據(jù)庫并沒有徹底分離，一切依賴都通過接口訪問。但是這只是口頭上的約定，對于業(yè)務開發(fā)人員直接在數(shù)據(jù)庫中進行關聯(lián)查詢。需要通過Code Review的方式避免。
服務劃分是一個長期的過程，需要積累大量的領域知識，以此來理解核心流程。最好是和領域專家一起組成聯(lián)合團隊，在理解核心問題的情況下，持續(xù)拆分服務并驗證拆分合理性，隨著時間的推移，還可以重新劃分。可見，服務拆分是一個持續(xù)性的過程。
服務劃分一旦完成，不能改變
由于業(yè)務的不斷變化，以及開發(fā)人員對領域知識和其他影響因素的理解等問題，很難一次性做出一個完美的解決方案。通常在劃分后會發(fā)現(xiàn)，某個問題是不可忍受的，例如劃分后導致響應時間降低，增加了更多的成本，有可能需要重新合并服務;由于業(yè)務的變化，原本的依賴關系發(fā)生了變化，有可能面臨需要重新劃分服務等類似的問題。
先實施組件化，再實施微服務架構
很多技術人員試圖先通過組件化逐步過渡到微服務架構，這是一種錯誤的思路。微服務架構劃分更強調業(yè)務領域的完整性，因此垂直劃分優(yōu)先，而組件化往往通過抽象出穩(wěn)定的部分形成組件共享，對調用次數(shù)和依賴關系并不強調。因此，組件化之后再轉化到微服務架構的方式，通常是錯誤的。
新聞名稱：來吧，說說你眼中的微服務
文章轉載：http://m.5511xx.com/article/dhggcgg.html
