微服務(wù)劃分模式

雖然服務(wù)是逐步被拆分出來(lái)的，隨著業(yè)務(wù)的演進(jìn)，在某一時(shí)刻，可能需要我們重新審視服務(wù)劃分得是否合理。本節(jié)向大家推薦兩種服務(wù)劃分的方法，首先介紹如何選擇服務(wù)劃分的方法。

[[280846]]

基于業(yè)務(wù)復(fù)雜度選擇服務(wù)劃分方法

根據(jù)業(yè)務(wù)復(fù)雜度劃分服務(wù)，如圖2-4所示。當(dāng)業(yè)務(wù)復(fù)雜度足夠高的時(shí)候，應(yīng)該基于領(lǐng)域驅(qū)動(dòng)劃分服務(wù)，而領(lǐng)域驅(qū)動(dòng)本身足夠復(fù)雜，很多概念比較抽象，應(yīng)用范圍并不是特別廣泛，所以當(dāng)業(yè)務(wù)復(fù)雜度較低時(shí)，可以選擇基于數(shù)據(jù)驅(qū)動(dòng)劃分服務(wù)。數(shù)據(jù)驅(qū)動(dòng)更容易理解和上手。也就是說(shuō)，除非業(yè)務(wù)復(fù)雜度非常高，否則應(yīng)該優(yōu)先以數(shù)據(jù)驅(qū)動(dòng)劃分服務(wù)。這里的業(yè)務(wù)復(fù)雜度專指業(yè)務(wù)邏輯，而非數(shù)據(jù)量、并發(fā)量等相關(guān)復(fù)雜度。

圖2-4 根據(jù)業(yè)務(wù)復(fù)雜度劃分服務(wù)

在做出選擇的時(shí)候，還有一個(gè)參考指標(biāo)是，團(tuán)隊(duì)以前是否已經(jīng)基于領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)業(yè)務(wù)。也就是說(shuō)，如果產(chǎn)品已經(jīng)基于領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)了一段時(shí)間，團(tuán)隊(duì)具備了領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)的能力，那么推薦繼續(xù)選擇領(lǐng)域驅(qū)動(dòng)劃分服務(wù)。如果是一個(gè)全新的產(chǎn)品，則可以靈活選擇。

選擇服務(wù)劃分的方法時(shí)要重點(diǎn)考慮如下條件。

• 業(yè)務(wù)復(fù)雜度。
• 團(tuán)隊(duì)對(duì)領(lǐng)域驅(qū)動(dòng)的熟悉程度。

基于數(shù)據(jù)驅(qū)動(dòng)劃分服務(wù)

數(shù)據(jù)驅(qū)動(dòng)是一個(gè)自下而上的架構(gòu)設(shè)計(jì)方法，數(shù)據(jù)驅(qū)動(dòng)強(qiáng)調(diào)的是數(shù)據(jù)結(jié)構(gòu)，也就是通過(guò)分析需求，確定整體數(shù)據(jù)結(jié)構(gòu)，根據(jù)表之間的關(guān)系劃分服務(wù)。

通?；跀?shù)據(jù)驅(qū)動(dòng)劃分服務(wù)的步驟如下。

(1)需求分析。通過(guò)領(lǐng)域?qū)＜?或者產(chǎn)品經(jīng)理)確定目標(biāo)，然后總結(jié)User Story，確定核心的業(yè)務(wù)流程;通過(guò)工具呈現(xiàn)比較粗糙的界面，進(jìn)行內(nèi)部討論;不斷迭代此環(huán)節(jié)，直到滿意為止。

(2)抽象數(shù)據(jù)結(jié)構(gòu)。根據(jù)需求總結(jié)Use Case，協(xié)助分析需求，從中抽象數(shù)據(jù)結(jié)構(gòu)。

(3)劃分服務(wù)。分析數(shù)據(jù)結(jié)構(gòu)，識(shí)別服務(wù)——服務(wù)應(yīng)該滿足高內(nèi)聚、低耦合、單一職責(zé)等特征。

(4)確定服務(wù)調(diào)用關(guān)系。先分析出主要流程，根據(jù)請(qǐng)求需要調(diào)用的服務(wù)確定服務(wù)調(diào)用關(guān)系。如果存在問(wèn)題，則需要回到(1)重新開(kāi)始。

(5)業(yè)務(wù)流程驗(yàn)證。重新回到User Story，以服務(wù)為粒度實(shí)現(xiàn)時(shí)序圖，注意此階段重點(diǎn)是驗(yàn)證服務(wù)劃分是否合適，要關(guān)注如下問(wèn)題。

• 一次更新操作如果要跨越更多服務(wù)，那么一致性的要求是什么。
•  跨服務(wù)查詢時(shí)，是否要做關(guān)聯(lián)查詢，一個(gè)服務(wù)內(nèi)是否能解決問(wèn)題。
• 性能是否能滿足要求。
• 成本是否滿足要求。

(6)持續(xù)優(yōu)化。

基于領(lǐng)域驅(qū)動(dòng)劃分服務(wù)

領(lǐng)域驅(qū)動(dòng)是一個(gè)自上而下的架構(gòu)設(shè)計(jì)方法，通過(guò)和領(lǐng)域?qū)＜医⒔y(tǒng)一的語(yǔ)言，不斷交流，確定關(guān)鍵業(yè)務(wù)場(chǎng)景，逐步確定邊界上下文。領(lǐng)域驅(qū)動(dòng)更強(qiáng)調(diào)業(yè)務(wù)實(shí)現(xiàn)效果，認(rèn)為自下而上的設(shè)計(jì)可能會(huì)導(dǎo)致技術(shù)人員不能更好地理解業(yè)務(wù)方向，進(jìn)而偏離業(yè)務(wù)目標(biāo)。

通?；陬I(lǐng)域驅(qū)動(dòng)劃分服務(wù)的步驟如下。

(1)通過(guò)模型和領(lǐng)域?qū)＜医⒔y(tǒng)一語(yǔ)言。建立統(tǒng)一語(yǔ)言是為了更深入地理解需求。通用語(yǔ)言盡量以業(yè)務(wù)語(yǔ)言為主，而非技術(shù)語(yǔ)言;通用語(yǔ)言和代碼一樣，需要不斷地重構(gòu)。

(2)業(yè)務(wù)分析。確定核心的業(yè)務(wù)流程，然后逐步擴(kuò)展到全部。最好通過(guò)工具呈現(xiàn)比較粗糙的界面，供內(nèi)部討論。

(3)尋找聚合。顯式地定義領(lǐng)域模型的邊界。最近比較熱門(mén)的事件風(fēng)暴，是一種基于領(lǐng)域驅(qū)動(dòng)分析業(yè)務(wù)、劃分服務(wù)的方法。

事件風(fēng)暴就是把所有的關(guān)鍵參與者都召集到一個(gè)很寬敞的屋子里來(lái)開(kāi)會(huì)，并且使用便利貼來(lái)描述系統(tǒng)中發(fā)生的事情，如圖2-5所示。

圖2-5 事件風(fēng)暴

• 用桔黃色的便利貼代表領(lǐng)域事件，在上面用一句話描述曾經(jīng)發(fā)生過(guò)什么事情。
• 用藍(lán)色的便利貼代表命令。命令的發(fā)起者可能是人，也可能是注入系統(tǒng)中的外部事件，或者定時(shí)器等。
• 用黃色的便利貼代表聚合。聚合是一組相關(guān)領(lǐng)域?qū)ο蟮募?，高?nèi)聚、低耦合是其基本要求，聚合內(nèi)還要保證數(shù)據(jù)一致性。

(4)確定服務(wù)調(diào)用關(guān)系。先分析出主要流程，根據(jù)一次請(qǐng)求需要調(diào)用的服務(wù)來(lái)確定服務(wù)調(diào)用關(guān)系。如果存在水平劃分，則需要根據(jù)服務(wù)依賴原則確定關(guān)系。如果存在問(wèn)題，則需要回到(1)重新開(kāi)始。

(5)業(yè)務(wù)流程驗(yàn)證。以服務(wù)為粒度實(shí)現(xiàn)時(shí)序圖，注意此階段重點(diǎn)是要驗(yàn)證服務(wù)劃分是否合適，主要關(guān)注如下問(wèn)題。

• 一次更新操作如果要跨越更多服務(wù)，那么一致性的要求是什么。
• 跨服務(wù)查詢時(shí)，是否要做關(guān)聯(lián)查詢，一個(gè)服務(wù)內(nèi)是否能解決問(wèn)題。
• 性能是否能滿足要求。
• 成本是否滿足要求。

(6)持續(xù)優(yōu)化。

從已有單體架構(gòu)中逐步劃分服務(wù)

在大多數(shù)場(chǎng)景下，并非從開(kāi)始階段就采用微服務(wù)架構(gòu)，而是隨著業(yè)務(wù)不斷發(fā)展，從最初的單體架構(gòu)中逐步拆分服務(wù)。下面描述了從一個(gè)單體架構(gòu)逐步拆分的步驟。

(1)所有微服務(wù)成功的故事都是從一個(gè)單體架構(gòu)太大，需要被拆散開(kāi)始的，如圖2-6所示。我們應(yīng)該從單體架構(gòu)開(kāi)始，當(dāng)系統(tǒng)規(guī)模足夠大、團(tuán)隊(duì)人數(shù)足夠多時(shí)，再逐步拆分服務(wù)，通常前后端分離是拆分的第一步。

圖2-6 從已有架構(gòu)逐步拆分服務(wù)(一)

(2)提取公共基礎(chǔ)服務(wù)，如單點(diǎn)登錄。拆分可以遵循邏輯分離和物理分離兩種方法。另外隨著系統(tǒng)壓力的增加，可能會(huì)用到消息中間件、分布式緩存等服務(wù)。

(3)不斷地從老系統(tǒng)中抽象出服務(wù)，垂直劃分優(yōu)先，如圖2-7所示。

圖2-7 從已有架構(gòu)逐步拆分服務(wù)(二)

(4)當(dāng)業(yè)務(wù)越來(lái)越復(fù)雜的時(shí)候，API Gateway做了太多的事情，會(huì)成為一個(gè)瓶頸點(diǎn)，服務(wù)之間的依賴關(guān)系也會(huì)變得越來(lái)越復(fù)雜，此時(shí)，需要適當(dāng)?shù)剡M(jìn)行水平切分，如圖2-8所示。

圖2-8 從已有架構(gòu)逐步拆分服務(wù)(三)

微服務(wù)拆分策略

當(dāng)不斷從單體架構(gòu)中抽象服務(wù)的時(shí)候，哪些服務(wù)優(yōu)先被拆分，哪些服務(wù)不需要被拆分?以下幾個(gè)策略可以幫助解決拆分中的這些問(wèn)題。

• 比較獨(dú)立的新業(yè)務(wù)優(yōu)先采用微服務(wù)架構(gòu)。從成本角度考慮，新業(yè)務(wù)采用新的架構(gòu)是最合理的，因?yàn)檫@樣做對(duì)老業(yè)務(wù)的影響最小。
• 優(yōu)先抽象通用服務(wù)。因?yàn)橥ǔＭㄓ梅?wù)的邊界比較明顯，耦合度低，比較容易分離。
• 優(yōu)先抽象比較容易識(shí)別的、邊界比較明顯的服務(wù)。如果原有包結(jié)構(gòu)比較清晰，可以基于原有包結(jié)構(gòu)中有明顯邊界的、比較完整的業(yè)務(wù)進(jìn)行劃分，這是從成本角度考慮。如果已經(jīng)基于單體架構(gòu)開(kāi)發(fā)了一段時(shí)間，對(duì)業(yè)務(wù)的理解程度已經(jīng)非常高，那么開(kāi)發(fā)及架構(gòu)人員能夠比較容易地提煉出一些邊界比較明顯的服務(wù)。
• 優(yōu)先抽象核心服務(wù)。因?yàn)槲⒎?wù)的開(kāi)發(fā)及運(yùn)維成本比較高，并不是所有的地方都需要?jiǎng)澐趾苄〉牧６?。往往一些比較邊緣的運(yùn)營(yíng)、管理的系統(tǒng)甚至不會(huì)考慮拆分。另外，隨著時(shí)間的推移，有一些業(yè)務(wù)可能會(huì)發(fā)生改變，因此應(yīng)該先抽象出核心服務(wù)。
• 優(yōu)先抽象具有獨(dú)立屬性的服務(wù)。應(yīng)根據(jù)功能的變更頻率、資源占用、技術(shù)棧等屬性劃分服務(wù)。
• 采用絞殺者模式，在遺留系統(tǒng)外圍，隨著時(shí)間的推移，讓新的服務(wù)逐漸“絞殺”老的系統(tǒng)。在這種情況下，復(fù)雜度往往體現(xiàn)在如何灰度發(fā)布、遷移數(shù)據(jù)，以及如何保障服務(wù)不中斷，后面的章節(jié)會(huì)詳細(xì)描述。

如何衡量服務(wù)劃分的合理性

每個(gè)產(chǎn)品在實(shí)施微服務(wù)架構(gòu)最初的動(dòng)力都不一樣，目標(biāo)也有所區(qū)別，所以判斷是否劃分合理，首先要看是否達(dá)成了目標(biāo)。其次，可以參考以下幾種衡量方式。每種衡量方式不能單獨(dú)作為一個(gè)判斷標(biāo)準(zhǔn)，需要綜合考慮。

• 一個(gè)小功能的修改從需求到上線需要多長(zhǎng)時(shí)間?正常情況下的微服務(wù)架構(gòu)交付周期應(yīng)該是以天為單位的。如果一個(gè)小功能的修改需要幾周到幾個(gè)月的時(shí)間，可能意味著服務(wù)劃分粒度過(guò)大，存在太多的沖突，要等待合并代碼。
• 大多數(shù)功能修改是否可以在一個(gè)服務(wù)內(nèi)完成?如果經(jīng)常需要跨服務(wù)團(tuán)隊(duì)的聯(lián)合開(kāi)發(fā)組才能完成一個(gè)新功能的開(kāi)發(fā)或者舊功能的修改，則說(shuō)明服務(wù)劃分存在問(wèn)題。
• 是否要頻繁修改接口?頻繁修改接口有可能是接口設(shè)計(jì)不合理導(dǎo)致的，也有可能是服務(wù)劃分的問(wèn)題導(dǎo)致的，說(shuō)明服務(wù)之間的邊界并不是特別明確和穩(wěn)定。
• 響應(yīng)時(shí)間是否能滿足要求?在某些追求極致性能的場(chǎng)景中，對(duì)響應(yīng)時(shí)間要求較高，服務(wù)劃分的層次太多、粒度太小都可能導(dǎo)致響應(yīng)時(shí)間不能滿足要求。
• 是否存在大量的跨服務(wù)更新?是否存在大量的跨服務(wù)的關(guān)聯(lián)查詢?出現(xiàn)這兩個(gè)問(wèn)題，可能是因?yàn)閯澐植缓侠怼?/li>

微服務(wù)劃分反模式

前面我們介紹了如何劃分服務(wù)，在此之上，我們希望通過(guò)微服務(wù)劃分的反模式來(lái)幫助大家少走彎路。

根據(jù)代碼行數(shù)劃分服務(wù)

代碼規(guī)模太大會(huì)導(dǎo)致溝通效率、交付效率低下，耦合度高，以及比較笨重。代碼規(guī)?？梢宰鳛橐粋€(gè)參考，但是不能作為一個(gè)絕對(duì)標(biāo)準(zhǔn)，微服務(wù)架構(gòu)中存在一個(gè)“大服務(wù)”是很正常的?；诖a行數(shù)拆分服務(wù)很難衡量服務(wù)的完整性，容易導(dǎo)向更小的拆分粒度，引起不必要的復(fù)雜度。

劃分粒度越小越好

服務(wù)的大小并不是特別重要，可以根據(jù)團(tuán)隊(duì)規(guī)模、代碼規(guī)模、業(yè)務(wù)復(fù)雜度、技術(shù)領(lǐng)域、重要程度、成本等因素綜合考慮。關(guān)于服務(wù)粒度的大小，業(yè)界并沒(méi)有統(tǒng)一標(biāo)準(zhǔn)，也很難衡量，最接近的衡量標(biāo)準(zhǔn)是研發(fā)團(tuán)隊(duì)規(guī)模。粒度小意味著更高的維護(hù)成本。后端管理、輔助系統(tǒng)通常粒度較大。

一次性劃分服務(wù)

拆分服務(wù)有如下兩種方式。

第一種，先拆分業(yè)務(wù)代碼再拆分?jǐn)?shù)據(jù)庫(kù)。如圖2-9所示，數(shù)據(jù)庫(kù)并沒(méi)有拆分，只是從單體中抽象出部分服務(wù)。

圖2-9 先拆分業(yè)務(wù)代碼再拆分?jǐn)?shù)據(jù)庫(kù)

第二種，業(yè)務(wù)代碼和數(shù)據(jù)庫(kù)同步拆分。如圖2-10所示，部分業(yè)務(wù)服務(wù)被拆分出來(lái)的同時(shí)，數(shù)據(jù)庫(kù)也被同步拆分出來(lái)。

圖2-10 業(yè)務(wù)代碼和數(shù)據(jù)庫(kù)同步拆分

采用第二種方式拆分服務(wù)時(shí)，根據(jù)服務(wù)將數(shù)據(jù)庫(kù)徹底拆分為多個(gè)獨(dú)立的數(shù)據(jù)庫(kù)，每個(gè)服務(wù)獨(dú)享數(shù)據(jù)庫(kù)服務(wù)，服務(wù)之間只能通過(guò)接口調(diào)用。這看起來(lái)非常美好，但需要為此做大量的數(shù)據(jù)遷移。當(dāng)業(yè)務(wù)處于初期，需求不是非常確定，開(kāi)發(fā)人員對(duì)業(yè)務(wù)理解不是特別透徹的時(shí)候，可能拆分后發(fā)現(xiàn)拆分得并不合理，只能再進(jìn)行合并，又要進(jìn)行一次數(shù)據(jù)遷移。相對(duì)來(lái)說(shuō)，業(yè)務(wù)代碼拆分成本更低，而數(shù)據(jù)遷移的成本更高，頻繁、大量的數(shù)據(jù)遷移并不可取。

更好的做法是把第一種方式作為過(guò)渡階段，當(dāng)業(yè)務(wù)逐步穩(wěn)定后再?gòu)氐走M(jìn)行數(shù)據(jù)遷移。注意，處于過(guò)渡階段時(shí)數(shù)據(jù)庫(kù)并沒(méi)有徹底分離，一切依賴都通過(guò)接口訪問(wèn)。但是這只是口頭上的約定，對(duì)于業(yè)務(wù)開(kāi)發(fā)人員直接在數(shù)據(jù)庫(kù)中進(jìn)行關(guān)聯(lián)查詢。需要通過(guò)Code Review的方式避免。

服務(wù)劃分是一個(gè)長(zhǎng)期的過(guò)程，需要積累大量的領(lǐng)域知識(shí)，以此來(lái)理解核心流程。最好是和領(lǐng)域?qū)＜乙黄鸾M成聯(lián)合團(tuán)隊(duì)，在理解核心問(wèn)題的情況下，持續(xù)拆分服務(wù)并驗(yàn)證拆分合理性，隨著時(shí)間的推移，還可以重新劃分?？梢?jiàn)，服務(wù)拆分是一個(gè)持續(xù)性的過(guò)程。

服務(wù)劃分一旦完成，不能改變

由于業(yè)務(wù)的不斷變化，以及開(kāi)發(fā)人員對(duì)領(lǐng)域知識(shí)和其他影響因素的理解等問(wèn)題，很難一次性做出一個(gè)完美的解決方案。通常在劃分后會(huì)發(fā)現(xiàn)，某個(gè)問(wèn)題是不可忍受的，例如劃分后導(dǎo)致響應(yīng)時(shí)間降低，增加了更多的成本，有可能需要重新合并服務(wù);由于業(yè)務(wù)的變化，原本的依賴關(guān)系發(fā)生了變化，有可能面臨需要重新劃分服務(wù)等類似的問(wèn)題。

先實(shí)施組件化，再實(shí)施微服務(wù)架構(gòu)

很多技術(shù)人員試圖先通過(guò)組件化逐步過(guò)渡到微服務(wù)架構(gòu)，這是一種錯(cuò)誤的思路。微服務(wù)架構(gòu)劃分更強(qiáng)調(diào)業(yè)務(wù)領(lǐng)域的完整性，因此垂直劃分優(yōu)先，而組件化往往通過(guò)抽象出穩(wěn)定的部分形成組件共享，對(duì)調(diào)用次數(shù)和依賴關(guān)系并不強(qiáng)調(diào)。因此，組件化之后再轉(zhuǎn)化到微服務(wù)架構(gòu)的方式，通常是錯(cuò)誤的。