微服務(wù)的架構設計

　　近年來(lái)，服務(wù)化和微服務(wù)的架構隨著(zhù)線(xiàn)上業(yè)務(wù)對響應變化和發(fā)布頻率要求的不斷提高已經(jīng)變得日益常見(jiàn)。下面yjbys小編為大家準備了關(guān)于微服務(wù)架構設計的文章，歡迎閱讀。

　　前言

　　許多企業(yè)對微服務(wù)思考的關(guān)注點(diǎn)也從最初的“該不該用”、“該如何用”逐漸轉向“如何評價(jià)服務(wù)拆分的好壞”、“服務(wù)拆分后的數據如何治理”這樣更加具體而實(shí)際的方面�？v觀(guān)社區里與微服務(wù)有關(guān)的話(huà)題，既有一些適合大眾閱讀的概念入門(mén)科普文章，也有一些像“架構去中心化”、“消息異步解耦”、“最終一致性補償”這類(lèi)專(zhuān)業(yè)性的技術(shù)討論，但卻很少看到能夠比較深入的介紹微服務(wù)實(shí)施經(jīng)驗，說(shuō)清楚“什么地方會(huì )有什么坑”這類(lèi)問(wèn)題的實(shí)踐性?xún)热荨?/p>

　　若將微服務(wù)的方方面面鋪開(kāi)，將是一個(gè)非常龐大而復雜的知識體系。萬(wàn)事開(kāi)頭難，如何邁出服務(wù)劃分的第一步是對于那些從未采用過(guò)微服務(wù)的項目首先要面對的問(wèn)題。雖然服務(wù)的劃分本來(lái)是一件十分憑借架構師個(gè)人經(jīng)驗和對業(yè)務(wù)理解的主觀(guān)工作，但其中仍然有些規律可循。根據服務(wù)的類(lèi)型特點(diǎn)，可以有以下幾種常見(jiàn)的方式：

　　1. 根據業(yè)務(wù)進(jìn)行建模，依據業(yè)務(wù)領(lǐng)域的邊界劃分，這也是當下微服務(wù)社區十分推崇的領(lǐng)域驅動(dòng)設計(Domain Driven Design，簡(jiǎn)稱(chēng)DDD)方法;

　　2. 根據資源使用類(lèi)型劃分，這種方式主要使用在對硬件資源需求很高、或對特定硬件類(lèi)型/區域地址等存在依賴(lài)的大型服務(wù)系統，例如系統的某些功能非常消耗CPU、或是某些功能必須在有加密狗設備的機器上運行。此時(shí)可以依據系統各部分對不同資源的需要作為邊界進(jìn)行最安全的劃分，以最大化運行效率;

　　3. 根據數據邊界劃分，直接從數據表結構或數據源著(zhù)手，依據數據歸屬關(guān)系界定服務(wù)。這種劃分方法簡(jiǎn)單粗暴且能避免數據耦合，但容易導致潛在隱患，甚至可以被認為是一種反模式。僅僅對于強數據驅動(dòng)的系統，如某些報表系統和多數據源ETL系統等適用，在實(shí)際案例中很少見(jiàn)。

　　從現實(shí)上來(lái)說(shuō)，我們平時(shí)遇到的絕大部分系統都是需要為特定終端用戶(hù)群體服務(wù)的。因此，采用基于業(yè)務(wù)領(lǐng)域的建模的方法通常都會(huì )是個(gè)不錯的選擇，它也是目前在劃分服務(wù)問(wèn)題中的最主流的方法。不過(guò)即使有了理論指導的支撐，服務(wù)劃分里的利弊權衡并不是非黑即白的事情，依然存在不少模棱兩可之處，只有在犯下一些錯誤后才能摸索出適合自己系統的方法。本文將會(huì )聚焦在這些點(diǎn)。

　　沒(méi)有什么能比一個(gè)具體而貼近真實(shí)的案例更具有代表性了。因此，我們將剖析一個(gè)傳統行業(yè)企業(yè)的線(xiàn)上業(yè)務(wù)：某汽車(chē)產(chǎn)品代理商的線(xiàn)上銷(xiāo)售和售后平臺，介紹它在微服務(wù)轉型過(guò)程中遇到的種種情況，希望能以此作為前車(chē)之鑒，讓后來(lái)者避開(kāi)不必要的趟坑。這個(gè)案例中講述的場(chǎng)景原型并非完全來(lái)自同一個(gè)項目，而是從我們過(guò)去一年中所經(jīng)歷的多個(gè)項目的實(shí)際場(chǎng)景抽取出來(lái)的，去除了其中的敏感信息，并添加了基于真實(shí)情況的適當演繹，使之更加完整。簡(jiǎn)單介紹一下案例的背景：這是一家頗具規模的汽車(chē)代理商企業(yè)，承接多個(gè)國際一線(xiàn)品牌汽車(chē)的銷(xiāo)售和周邊資源整合的業(yè)務(wù)，具有龐大的實(shí)體店網(wǎng)點(diǎn)。其線(xiàn)上的IT業(yè)務(wù)系統已經(jīng)存在了十余年，提供的功能從最初的進(jìn)銷(xiāo)存管理、客戶(hù)信息管理等到現在的面向消費者客戶(hù)的服務(wù)系統，十分復雜。系統中的線(xiàn)上銷(xiāo)售和售后平臺部分是相對比較新、且需求變化特別迅速的部分，也是目前出問(wèn)題最頻繁、收到抱怨最多的部分。

　　不要從數據庫開(kāi)始建模

　　傳統軟件開(kāi)發(fā)中，數據模型被認為是整個(gè)系統的核心，業(yè)務(wù)邏輯僅僅是對數據的CRUD加上簡(jiǎn)單的計算呈現。有些項目團隊的架構評審會(huì )花很多時(shí)間來(lái)討論系統龐大的ER圖(實(shí)體關(guān)系圖)設計。但在微服務(wù)架構設計時(shí)，ER圖并非最佳選擇，特別是在服務(wù)劃分時(shí)采用ER圖進(jìn)行建模甚至是十分有害的。

　　在領(lǐng)域驅動(dòng)設計的實(shí)踐中，有一個(gè)和ER圖建模有些相似的環(huán)節，叫做“領(lǐng)域建模”。相比ER圖建模通常只有開(kāi)發(fā)人員參與，并從數據表的角度考慮模型的方法，領(lǐng)域建模的過(guò)程需要由產(chǎn)品的業(yè)務(wù)人員和核心開(kāi)發(fā)人員共同參與，先梳理用戶(hù)場(chǎng)景，然后從業(yè)務(wù)領(lǐng)域角度，逐步確定場(chǎng)景中的實(shí)體、關(guān)聯(lián)和聚合等元素。其中的“實(shí)體、關(guān)聯(lián)”與ER圖中的“實(shí)體、關(guān)系”有些相似，但含義并不一致。領(lǐng)域模型中的“實(shí)體”本質(zhì)上是業(yè)務(wù)場(chǎng)景中需要被持久化存儲的對象，但存儲方式不一定是數據庫，更不一定是關(guān)系型數據庫，而ER圖中的“實(shí)體”最終對應的就是關(guān)系型數據庫的表。領(lǐng)域模型中的“關(guān)聯(lián)”是兩個(gè)實(shí)體在業(yè)務(wù)上下文之間有業(yè)務(wù)含義的聯(lián)系，而ER圖中的“關(guān)系”只的是兩張表之間的一個(gè)關(guān)聯(lián)外鍵。

　　那么，使用ER圖給微服務(wù)建模會(huì )存在什么問(wèn)題呢?

　　首先，ER圖設計時(shí)假定了使用的是關(guān)系型的數據庫。微服務(wù)的一個(gè)特點(diǎn)在于它支持異構架構，系統的不同部分，依據實(shí)際需要可選擇不同的編程語(yǔ)言、框架以及數據庫的類(lèi)型。關(guān)系型數據庫采用平面表的結構，如果有兩類(lèi)嵌套關(guān)系的對象，只能使用關(guān)聯(lián)表來(lái)表達兩個(gè)實(shí)體之間的關(guān)系，然后通過(guò)復雜的SQL語(yǔ)句在查詢(xún)時(shí)將多個(gè)表拼成更大的平面表，最后在業(yè)務(wù)代碼里再分解到各個(gè)獨立的對象里去。這些單獨的表又可能在其他地方與另一個(gè)表存在關(guān)聯(lián)查詢(xún)。這樣設計出來(lái)的表結構的冗余很低，且使用非常靈活，但正是這種靈活性往導致系統中多個(gè)業(yè)務(wù)邏輯表出現錯中纏繞的關(guān)系，從而使剝離單獨服務(wù)進(jìn)行異構設計變得困難。

　　其次，ER圖還會(huì )導致實(shí)體相似的不同業(yè)務(wù)邏輯在設計時(shí)被耦合在一起。舉一個(gè)具體的例子，在汽車(chē)代理銷(xiāo)售系統中，不同品牌汽車(chē)的購買(mǎi)流程后端實(shí)際上分別對接的是完全不同的分銷(xiāo)渠道系統和邏輯流程，但它們在用戶(hù)視圖上所需要的信息比較一致，因此存儲的數據結構也比較相似。這個(gè)系統在最初設計時(shí)采用了ER圖的方式建模，由于ER圖模型不關(guān)心業(yè)務(wù)層面上的東西，不同品牌汽車(chē)的實(shí)體數據看上去都是一種類(lèi)型的數據，僅僅是一個(gè)品牌字段的差異而已，因此被理所當然的設計成了同一張表。上層邏輯實(shí)現的時(shí)候使用了大量的if-else語(yǔ)句來(lái)區分各種品牌的購買(mǎi)流程，結果使得多條完全不同的業(yè)務(wù)線(xiàn)糅合在同一個(gè)上下文里，后來(lái)的開(kāi)發(fā)非常容易在這里錯改、漏改代碼。若當初使用的是領(lǐng)域建模，則不同的購車(chē)流程會(huì )自然的被劃分到各種不同的用戶(hù)場(chǎng)景，即使它們在數據結構上看起來(lái)基本相同，也會(huì )被識別為兩個(gè)獨立的上下文，這就會(huì )使得未來(lái)劃分服務(wù)時(shí)能夠更加容易。

　　最后，ER圖設計的架構會(huì )使得系統的模塊之間傾向于使用數據庫集成，而非API集成。在ER圖中沒(méi)有明確劃分模塊和表的所有權關(guān)系，所有的數據表對所有的模塊都是可見(jiàn)的，倘若不加額外約束，各個(gè)模塊便都會(huì )輕易的讀寫(xiě)其中的內容。數據集成并不會(huì )直接導致服務(wù)無(wú)法拆分，但由于數據的所有權不清晰，十分容易引發(fā)的意想不到的狀況。還是舉銷(xiāo)售平臺的例子，在ER圖建模得到的模型中，有一張與購買(mǎi)記錄相關(guān)的表。在一次銷(xiāo)售業(yè)務(wù)的代碼更新中，對購買(mǎi)結果的增加了字段，在測試過(guò)程中沒(méi)有發(fā)現問(wèn)題，結果上線(xiàn)幾天以后，由于售后服務(wù)也在修改這個(gè)表而導致出現了臟數據，造成難以排查的故障。

　　當然，我們并非要完全否認ER圖建模的價(jià)值，只不過(guò)通過(guò)數據庫角度建立模型的過(guò)程容易傾向于設計出龐大的單體應用，因而不太適應于服務(wù)劃分的目的。

　　端到端的劃分服務(wù)

　　在拆服務(wù)時(shí)要端到端的劃分，這是我們在設計微服務(wù)時(shí)經(jīng)常聽(tīng)到的一句話(huà)。端到端的劃分，指的是一個(gè)服務(wù)負責一個(gè)業(yè)務(wù)領(lǐng)域，這個(gè)功能領(lǐng)域的所有邏輯、數據都歸它管，這有利于微服務(wù)的數據治理。與之相對的是MVC那樣的橫向服務(wù)劃分，將所有數據歸一塊，所有邏輯歸另一塊，特別是在跨團隊管理的情況，橫向劃分服務(wù)會(huì )帶來(lái)十分高昂的協(xié)調和聯(lián)調成本。

　　道理不必多說(shuō)，還是講個(gè)例子吧。在汽車(chē)銷(xiāo)售平臺的最初架構中，使用了典型的MVC三層結構，由于人比較多，分成了前臺組、后臺組，就時(shí)不時(shí)要出現新開(kāi)發(fā)一個(gè)功能，一動(dòng)底層數據結構，結果上層的另一個(gè)不相干頁(yè)面掛了，一查發(fā)現原來(lái)那這個(gè)頁(yè)面間接的用了同一個(gè)數據模型。比較典型的例子是，有一回負責后臺的小組調整了汽車(chē)銷(xiāo)售服務(wù)里面的汽車(chē)參數信息相關(guān)的對象結構，結果一上線(xiàn)，銷(xiāo)售功能正常，試駕服務(wù)的頁(yè)面掛了。原來(lái)是試駕功能的前端開(kāi)發(fā)人員在處理汽車(chē)信息時(shí)候，看到銷(xiāo)售模塊有現成功能，就直接拿來(lái)復用了。這便是服務(wù)上下層分團隊開(kāi)發(fā)導致的問(wèn)題。

　　此外，橫向劃分服務(wù)也不利于系統的開(kāi)發(fā)效率的提升。不同業(yè)務(wù)服務(wù)對功能發(fā)布頻率的的需求是不一樣的，比如試駕平臺經(jīng)常推出新的優(yōu)惠促銷(xiāo)活動(dòng)，需要盡快進(jìn)行一次版本更新，于此同時(shí)售后服務(wù)有一個(gè)需要和第三方聯(lián)調的功能也已經(jīng)差不多完成并提交到代碼倉庫了，但由于需要協(xié)調第三方系統的時(shí)間，最近還不能夠上線(xiàn)，此時(shí)兩邊的業(yè)務(wù)主管就要開(kāi)掐了。類(lèi)似這樣的情況其實(shí)經(jīng)常發(fā)生，通常使用特性分支、特性開(kāi)關(guān)等流程或者技術(shù)手段能夠規避一部分業(yè)務(wù)開(kāi)發(fā)進(jìn)度不一致的風(fēng)險，但若要從根本上解決這種問(wèn)題，還是需要端到端的按業(yè)務(wù)來(lái)劃分服務(wù)。

　　最后，橫向劃分模塊對于問(wèn)題的追蹤調試也不友好，幾乎每次事故調查總是要穿插涉及在幾個(gè)團隊之間不停的協(xié)調開(kāi)會(huì )，因為一個(gè)完整業(yè)務(wù)流總是要貫穿前后幾個(gè)層的功能。

　　需要指出的是，端到端劃分服務(wù)并非是說(shuō)服務(wù)與服務(wù)之間都是平級的。實(shí)際上，服務(wù)之間可以再聚合成更高層級的組合服務(wù)的，以及在最頂端的API Gateway也可以算是一類(lèi)服務(wù)。只不過(guò)，在核心業(yè)務(wù)層的這些服務(wù)，每個(gè)都單獨提供了某項特定的業(yè)務(wù)價(jià)值。

　　識別核心業(yè)務(wù)服務(wù)

　　微服務(wù)的架構通常并非是一開(kāi)始就重頭設計出來(lái)的，而是先有整塊的單體架構，隨著(zhù)業(yè)務(wù)的復雜度上升，才逐步拆分出來(lái)。業(yè)務(wù)領(lǐng)域建模除了能用來(lái)指導適當的服務(wù)劃分，另一個(gè)重要的作用是讓工作聚焦到核心的業(yè)務(wù)服務(wù)中。

　　無(wú)論多復雜系統都是為特定業(yè)務(wù)價(jià)值而存在的。在系統的實(shí)現中必然會(huì )存在與核心業(yè)務(wù)最相關(guān)的部分、輔助核心業(yè)務(wù)的部分、和非核心業(yè)務(wù)關(guān)系的部分。它們在領(lǐng)域驅動(dòng)設計的術(shù)語(yǔ)中稱(chēng)為“核心域”、“支撐子域”和“通用子域”。在進(jìn)行領(lǐng)域建模的時(shí)候就應該順便識別出系統里的關(guān)鍵領(lǐng)域。將系統的業(yè)務(wù)領(lǐng)域羅列出來(lái)然后劃分出重要性，這件事情聽(tīng)起來(lái)似乎是多此一舉，甚至有點(diǎn)荒唐，但對于復雜系統，實(shí)際去做這件事帶來(lái)的價(jià)值可能遠比它看起來(lái)更大。

　　首先，當我們將一個(gè)復雜的系統的各種業(yè)務(wù)仔細清點(diǎn)到臺面上以后，得到的列表往往會(huì )比許多人最初想象得長(cháng)得多，它能提醒我們系統的復雜度是否已經(jīng)過(guò)高了。其次，列舉業(yè)務(wù)的過(guò)程也是開(kāi)發(fā)者與業(yè)務(wù)人員溝通的過(guò)程，來(lái)自不同業(yè)務(wù)線(xiàn)的代表也許會(huì )為某部分業(yè)務(wù)的價(jià)值點(diǎn)發(fā)生爭執，或是提供一些許多開(kāi)發(fā)人員此前并不了解的細節信息，將這些問(wèn)題當面討論清楚并非什么壞事。此外，當我們真的去仔細思考一個(gè)業(yè)務(wù)系統的核心價(jià)值時(shí)，也許會(huì )得出使人意想不到的結果。

　　繼續舉例子，在汽車(chē)的銷(xiāo)售和售后平臺中，通過(guò)業(yè)務(wù)建模，可以劃分出許多子領(lǐng)域：

　　• 在線(xiàn)購車(chē)(渠道A)

　　• 在線(xiàn)購車(chē)(渠道B)

　　• 在線(xiàn)購車(chē)(渠道C)

　　• 試駕預約

　　• 售后服務(wù)

　　• 用戶(hù)反饋

　　• 訂單系統

　　• 促銷(xiāo)活動(dòng)

　　• 車(chē)輛市價(jià)信息

　　• 車(chē)輛參數信息

　　• 4s店信息

　　• 用戶(hù)信息管理

　　• …

　　說(shuō)明：這里渠道指的是銷(xiāo)售平臺對接的一個(gè)第三方系統，其中每個(gè)渠道可以對應多個(gè)汽車(chē)品牌

　　然后我們要從中識別出業(yè)務(wù)中的核心域。必須強調，服務(wù)領(lǐng)域劃分僅僅是代表服務(wù)對系統關(guān)鍵業(yè)務(wù)貢獻的價(jià)值，處于核心域中的那些服務(wù)應該是該系統業(yè)務(wù)成功的主要促成因素，從戰略層面講，企業(yè)應該在自己的核心領(lǐng)域上具有一定壁壘優(yōu)勢。經(jīng)過(guò)討論，開(kāi)發(fā)者和業(yè)務(wù)人員最終得出讓人大跌眼鏡的結論，核心域部分的服務(wù)只有“試駕預約”和“售后服務(wù)”，因為這兩項才是該企業(yè)最具競爭力的業(yè)務(wù)。而看起來(lái)十分重要的“在線(xiàn)購車(chē)”服務(wù)，由于并不具有特別的行業(yè)競爭優(yōu)勢而被劃到了支撐子域中。正確的服務(wù)劃分定位將對系統未來(lái)的發(fā)展策略產(chǎn)生積極的影響。

　　在這個(gè)系統中的“車(chē)輛市價(jià)信息”、“車(chē)輛參數信息”、“4s店信息”等服務(wù)都被劃歸到了通用子域。在通用子域中的服務(wù)并非最沒(méi)有價(jià)值或是復雜度最低，而只是說(shuō)明系統在這些服務(wù)領(lǐng)域中通常不具優(yōu)勢，因此這部分功能完全可以考慮外包開(kāi)發(fā)或者購買(mǎi)第三方的現成服務(wù)。

　　使用符合業(yè)務(wù)結構的API

　　前面介紹業(yè)務(wù)建模的時(shí)候我們強調了使用“API集成”的必要性，以及它的反面形式“數據庫集成”所帶來(lái)的問(wèn)題。在微服務(wù)的架構中，服務(wù)的技術(shù)選型可能是異構的，API的實(shí)現也會(huì )各有不同。除了Web應用比較流行的RESTful標準，還有像SOAP、ProtolBuf、MessageQueue等不同的協(xié)議與格式標準，它們都可以被作為服務(wù)之間通信的API。不同的API設計對服務(wù)使用的體驗差別會(huì )很大，除去技術(shù)原因對API協(xié)議的傾向性，在設計和評價(jià)API方面依然有許多值得注意的地方。

　　一個(gè)好的API設計應該在接口的元數據中向用戶(hù)提供盡可能多的有意義的業(yè)務(wù)信息，這里指的元數據包括例如API的名稱(chēng)、參數、標簽等等用戶(hù)在不需要專(zhuān)門(mén)查看文檔就可以看到的內容。通常在各種不同的API協(xié)議里，總會(huì )存在一個(gè)相似的概念，就是目標路徑。比如RESTful的URL地址，ProtolBuf的消息類(lèi)型嵌套結構，MessageQueue名稱(chēng)里用斜線(xiàn)劃分Topic路徑的慣例等。以RESTful標準為例，可以試比較下面兩種URL地址的差異。

　　• 第一種：/users/123/orders/123

　　• 第二種：/orders?id=123&user_id=123

　　顯然前一種地址包含的信息更多，它告訴了訪(fǎng)問(wèn)者訂單(orders)是屬于用戶(hù)(users)這個(gè)實(shí)體中的一個(gè)子實(shí)體，并且包含了一個(gè)潛在業(yè)務(wù)規則，即如果ID為123的這個(gè)用戶(hù)不存在了，那么查詢(xún)他下面的所有訂單信息也是不具有業(yè)務(wù)意義的。實(shí)體之間的嵌套關(guān)系可以通過(guò)領(lǐng)域建模過(guò)程中的聚合識別。當然，這種URL結構有時(shí)會(huì )導致很長(cháng)的API路徑，但相比它所帶來(lái)的業(yè)務(wù)語(yǔ)義，我們認為還是值得的。

　　類(lèi)似的語(yǔ)義化例子還有例如：

　　• PUT /services/questions/123

　　• PUT /services/questions/123/comments/123

　　這是售后服務(wù)部分的兩個(gè)API，分別用來(lái)更新提問(wèn)的內容和提問(wèn)的評論內容，它們也是按層級組織的。

　　有些通信協(xié)議中還提供了其他可以表明業(yè)務(wù)語(yǔ)義的元素。比如RESTful中使用GET/POST/PUT操作語(yǔ)義(查詢(xún)/創(chuàng )建/修改)，以及HTTP返回值中的語(yǔ)義信息等。在實(shí)際設計API時(shí)充分利用這些協(xié)議特性，能夠使服務(wù)變得更加易用。

【微服務(wù)的架構設計】相關(guān)文章：

三層架構用戶(hù)服務(wù)系統的設計與實(shí)現03-03

ui設計師知識架構03-12

系統架構設計模式大全02-26

基于云架構的系統安全設計03-30

系統架構設計師要素01-11

J2EE架構與設計培訓03-18

系統架構設計師考試之路01-11

三層架構的商務(wù)智能系統設計12-25

MES系統安全架構設計03-04