圖片

我們先來(lái)分析一下軟件架構(gòu)模式演進(jìn)的三個(gè)階段。

第一階段是單機(jī)架構(gòu)：采用面向過(guò)程的設(shè)計(jì)方法，系統(tǒng)包括客戶端 UI 層和數(shù)據(jù)庫(kù)兩層，采用 C/S 架構(gòu)模式，整個(gè)系統(tǒng)圍繞數(shù)據(jù)庫(kù)驅(qū)動(dòng)設(shè)計(jì)和開發(fā)，并且總是從設(shè)計(jì)數(shù)據(jù)庫(kù)和字段開始。

第二階段是集中式架構(gòu)：采用面向?qū)ο蟮脑O(shè)計(jì)方法，系統(tǒng)包括業(yè)務(wù)接入層、業(yè)務(wù)邏輯層和數(shù)據(jù)庫(kù)層，采用經(jīng)典的三層架構(gòu)，也有部分應(yīng)用采用傳統(tǒng)的 SOA 架構(gòu)。這種架構(gòu)容易使系統(tǒng)變得臃腫，可擴(kuò)展性和彈性伸縮性差。

第三階段是分布式微服務(wù)架構(gòu)：隨著微服務(wù)架構(gòu)理念的提出，集中式架構(gòu)正向分布式微服務(wù)架構(gòu)演進(jìn)。微服務(wù)架構(gòu)可以很好地實(shí)現(xiàn)應(yīng)用之間的解耦，解決單體應(yīng)用擴(kuò)展性和彈性伸縮能力不足的問(wèn)題。

我們知道，在單機(jī)和集中式架構(gòu)時(shí)代，系統(tǒng)分析、設(shè)計(jì)和開發(fā)往往是獨(dú)立、分階段割裂進(jìn)行的。

比如，在系統(tǒng)建設(shè)過(guò)程中，我們經(jīng)常會(huì)看到這樣的情形：A 負(fù)責(zé)提出需求，B 負(fù)責(zé)需求分析，C 負(fù)責(zé)系統(tǒng)設(shè)計(jì)，D 負(fù)責(zé)代碼實(shí)現(xiàn)，這樣的流程很長(zhǎng)，經(jīng)手的人也很多，很容易導(dǎo)致信息丟失。最后，就很容易導(dǎo)致需求、設(shè)計(jì)與代碼實(shí)現(xiàn)的不一致，往往到了軟件上線后，我們才發(fā)現(xiàn)很多功能并不是自己想要的，或者做出來(lái)的功能跟自己提出的需求偏差太大。

而且在單機(jī)和集中式架構(gòu)這兩種模式下，軟件無(wú)法快速響應(yīng)需求和業(yè)務(wù)的迅速變化，最終錯(cuò)失發(fā)展良機(jī)。此時(shí)，分布式微服務(wù)的出現(xiàn)就有點(diǎn)恰逢其時(shí)的意思了。

微服務(wù)設(shè)計(jì)和拆分的困境

那進(jìn)入微服務(wù)架構(gòu)時(shí)代以后，微服務(wù)確實(shí)也解決了原來(lái)采用集中式架構(gòu)的單體應(yīng)用的很多問(wèn)題，比如擴(kuò)展性、彈性伸縮能力、小規(guī)模團(tuán)隊(duì)的敏捷開發(fā)等等。

但在看到這些好處的同時(shí)，微服務(wù)實(shí)踐過(guò)程中也產(chǎn)生了不少的爭(zhēng)論和疑惑：微服務(wù)的粒度應(yīng)該多大呀？微服務(wù)到底應(yīng)該如何拆分和設(shè)計(jì)呢？微服務(wù)的邊界應(yīng)該在哪里？

可以說(shuō)，很久以來(lái)都沒有一套系統(tǒng)的理論和方法可以指導(dǎo)微服務(wù)的拆分，包括微服務(wù)架構(gòu)模式的提出者 Martin Fowler 在提出微服務(wù)架構(gòu)的時(shí)候，也沒有告訴我們究竟應(yīng)該如何拆分微服務(wù)。

于是，在這段較長(zhǎng)的時(shí)間里，就有不少人對(duì)微服務(wù)的理解產(chǎn)生了一些曲解。有人認(rèn)為：“微服務(wù)很簡(jiǎn)單，不過(guò)就是把原來(lái)一個(gè)單體包拆分為多個(gè)部署包，或者將原來(lái)的單體應(yīng)用架構(gòu)替換為一套支持微服務(wù)架構(gòu)的技術(shù)框架，就算是微服務(wù)了。” 還有人說(shuō)：“微服務(wù)嘛，就是要微要小，拆得越小效果越好?！?/span>

但我想，這兩年，你在技術(shù)圈中一定聽說(shuō)過(guò)一些項(xiàng)目因?yàn)榍捌谖⒎?wù)拆分過(guò)度，導(dǎo)致項(xiàng)目復(fù)雜度過(guò)高，無(wú)法上線和運(yùn)維。

綜合來(lái)看，我認(rèn)為微服務(wù)拆分困境產(chǎn)生的根本原因就是不知道業(yè)務(wù)或者微服務(wù)的邊界到底在什么地方。換句話說(shuō)，確定了業(yè)務(wù)邊界和應(yīng)用邊界，這個(gè)困境也就迎刃而解了。

那如何確定，是否有相關(guān)理論或知識(shí)體系支持呢？在回答這些問(wèn)題之前，我們先來(lái)了解一下領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與微服務(wù)的前世今生。

2004 年埃里克·埃文斯（Eric Evans）發(fā)表了《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》（Domain-Driven Design –Tackling Complexity in the Heart of Software）這本書，從此領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design，簡(jiǎn)稱 DDD）誕生。DDD 核心思想是通過(guò)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)方法定義領(lǐng)域模型，從而確定業(yè)務(wù)和應(yīng)用邊界，保證業(yè)務(wù)模型與代碼模型的一致性。

但 DDD 提出后在軟件開發(fā)領(lǐng)域一直都是“雷聲大，雨點(diǎn)小”！直到 Martin Fowler 提出微服務(wù)架構(gòu)，DDD 才真正迎來(lái)了自己的時(shí)代。有些熟悉 DDD 設(shè)計(jì)方法的軟件工程師在進(jìn)行微服務(wù)設(shè)計(jì)時(shí)，發(fā)現(xiàn)可以利用 DDD 設(shè)計(jì)方法來(lái)建立領(lǐng)域模型，劃分領(lǐng)域邊界，再根據(jù)這些領(lǐng)域邊界從業(yè)務(wù)視角來(lái)劃分微服務(wù)邊界。而按照 DDD 方法設(shè)計(jì)出的微服務(wù)的業(yè)務(wù)和應(yīng)用邊界都非常合理，可以很好地實(shí)現(xiàn)微服務(wù)內(nèi)部和外部的“高內(nèi)聚、低耦合”。于是越來(lái)越多的人開始把 DDD 作為微服務(wù)設(shè)計(jì)的指導(dǎo)思想。

現(xiàn)在，很多大型互聯(lián)網(wǎng)企業(yè)已經(jīng)將 DDD 設(shè)計(jì)方法作為微服務(wù)的主流設(shè)計(jì)方法了。DDD 也從過(guò)去“雷聲大，雨點(diǎn)小”，開始真正火爆起來(lái)。

為什么 DDD 適合微服務(wù)？

“眾里尋他千百度。驀然回首，那人卻在燈火闌珊處?！痹诮?jīng)歷了多年的迷茫和爭(zhēng)論后，微服務(wù)終于尋到了他的心上人。

那 DDD 到底是何方神圣，擁有什么神器呢？

戰(zhàn)略設(shè)計(jì)主要從業(yè)務(wù)視角出發(fā)，建立業(yè)務(wù)領(lǐng)域模型，劃分領(lǐng)域邊界，建立通用語(yǔ)言的限界上下文，限界上下文可以作為微服務(wù)設(shè)計(jì)的參考邊界。

戰(zhàn)術(shù)設(shè)計(jì)則從技術(shù)視角出發(fā)，側(cè)重于領(lǐng)域模型的技術(shù)實(shí)現(xiàn)，完成軟件開發(fā)和落地，包括：聚合根、實(shí)體、值對(duì)象、領(lǐng)域服務(wù)、應(yīng)用服務(wù)和資源庫(kù)等代碼邏輯的設(shè)計(jì)和實(shí)現(xiàn)。

我們不妨來(lái)看看 DDD 是如何進(jìn)行戰(zhàn)略設(shè)計(jì)的。

DDD 戰(zhàn)略設(shè)計(jì)會(huì)建立領(lǐng)域模型，領(lǐng)域模型可以用于指導(dǎo)微服務(wù)的設(shè)計(jì)和拆分。事件風(fēng)暴是建立領(lǐng)域模型的主要方法，它是一個(gè)從發(fā)散到收斂的過(guò)程。它通常采用用例分析、場(chǎng)景分析和用戶旅程分析，盡可能全面不遺漏地分解業(yè)務(wù)領(lǐng)域，并梳理領(lǐng)域?qū)ο笾g的關(guān)系，這是一個(gè)發(fā)散的過(guò)程。事件風(fēng)暴過(guò)程會(huì)產(chǎn)生很多的實(shí)體、命令、事件等領(lǐng)域?qū)ο螅覀儗⑦@些領(lǐng)域?qū)ο髲牟煌木S度進(jìn)行聚類，形成如聚合、限界上下文等邊界，建立領(lǐng)域模型，這就是一個(gè)收斂的過(guò)程。

圖片

我們可以用三步來(lái)劃定領(lǐng)域模型和微服務(wù)的邊界。

第一步：在事件風(fēng)暴中梳理業(yè)務(wù)過(guò)程中的用戶操作、事件以及外部依賴關(guān)系等，根據(jù)這些要素梳理出領(lǐng)域?qū)嶓w等領(lǐng)域?qū)ο蟆?/span>

第二步：根據(jù)領(lǐng)域?qū)嶓w之間的業(yè)務(wù)關(guān)聯(lián)性，將業(yè)務(wù)緊密相關(guān)的實(shí)體進(jìn)行組合形成聚合，同時(shí)確定聚合中的聚合根、值對(duì)象和實(shí)體。在這個(gè)圖里，聚合之間的邊界是第一層邊界，它們?cè)谕粋€(gè)微服務(wù)實(shí)例中運(yùn)行，這個(gè)邊界是邏輯邊界，所以用虛線表示。

第三步：根據(jù)業(yè)務(wù)及語(yǔ)義邊界等因素，將一個(gè)或者多個(gè)聚合劃定在一個(gè)限界上下文內(nèi)，形成領(lǐng)域模型。在這個(gè)圖里，限界上下文之間的邊界是第二層邊界，這一層邊界可能就是未來(lái)微服務(wù)的邊界，不同限界上下文內(nèi)的領(lǐng)域邏輯被隔離在不同的微服務(wù)實(shí)例中運(yùn)行，物理上相互隔離，所以是物理邊界，邊界之間用實(shí)線來(lái)表示。

有了這兩層邊界，微服務(wù)的設(shè)計(jì)就不是什么難事了。

在戰(zhàn)略設(shè)計(jì)中我們建立了領(lǐng)域模型，劃定了業(yè)務(wù)領(lǐng)域的邊界，建立了通用語(yǔ)言和限界上下文，確定了領(lǐng)域模型中各個(gè)領(lǐng)域?qū)ο蟮年P(guān)系。到這兒，業(yè)務(wù)端領(lǐng)域模型的設(shè)計(jì)工作基本就完成了，這個(gè)過(guò)程同時(shí)也基本確定了應(yīng)用端的微服務(wù)邊界。

在從業(yè)務(wù)模型向微服務(wù)落地的過(guò)程中，也就是從戰(zhàn)略設(shè)計(jì)向戰(zhàn)術(shù)設(shè)計(jì)的實(shí)施過(guò)程中，我們會(huì)將領(lǐng)域模型中的領(lǐng)域?qū)ο笈c代碼模型中的代碼對(duì)象建立映射關(guān)系，將業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)進(jìn)行綁定。當(dāng)我們?nèi)ロ憫?yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)和領(lǐng)域模型時(shí)，系統(tǒng)架構(gòu)也會(huì)同時(shí)發(fā)生調(diào)整，并同步建立新的映射關(guān)系。

DDD 與微服務(wù)的關(guān)系

有了上面的講解，現(xiàn)在我們不妨再次總結(jié)下 DDD 與微服務(wù)的關(guān)系。

DDD 是一種架構(gòu)設(shè)計(jì)方法，微服務(wù)是一種架構(gòu)風(fēng)格，兩者從本質(zhì)上都是為了追求高響應(yīng)力，而從業(yè)務(wù)視角去分離應(yīng)用系統(tǒng)建設(shè)復(fù)雜度的手段。兩者都強(qiáng)調(diào)從業(yè)務(wù)出發(fā)，其核心要義是強(qiáng)調(diào)根據(jù)業(yè)務(wù)發(fā)展，合理劃分領(lǐng)域邊界，持續(xù)調(diào)整現(xiàn)有架構(gòu)，優(yōu)化現(xiàn)有代碼，以保持架構(gòu)和代碼的生命力，也就是我們常說(shuō)的演進(jìn)式架構(gòu)。

DDD 主要關(guān)注：從業(yè)務(wù)領(lǐng)域視角劃分領(lǐng)域邊界，構(gòu)建通用語(yǔ)言進(jìn)行高效溝通，通過(guò)業(yè)務(wù)抽象，建立領(lǐng)域模型，維持業(yè)務(wù)和代碼的邏輯一致性。

微服務(wù)主要關(guān)注：運(yùn)行時(shí)的進(jìn)程間通信、容錯(cuò)和故障隔離，實(shí)現(xiàn)去中心化數(shù)據(jù)管理和去中心化服務(wù)治理，關(guān)注微服務(wù)的獨(dú)立開發(fā)、測(cè)試、構(gòu)建和部署。

總結(jié)

DDD 是一套完整而系統(tǒng)的設(shè)計(jì)方法，它能帶給你從戰(zhàn)略設(shè)計(jì)到戰(zhàn)術(shù)設(shè)計(jì)的標(biāo)準(zhǔn)設(shè)計(jì)過(guò)程，使得你的設(shè)計(jì)思路能夠更加清晰，設(shè)計(jì)過(guò)程更加規(guī)范。

DDD 善于處理與領(lǐng)域相關(guān)的擁有高復(fù)雜度業(yè)務(wù)的產(chǎn)品開發(fā)，通過(guò)它可以建立一個(gè)核心而穩(wěn)定的領(lǐng)域模型，有利于領(lǐng)域知識(shí)的傳遞與傳承。

DDD 強(qiáng)調(diào)團(tuán)隊(duì)與領(lǐng)域?qū)＜业暮献鳎軌驇椭愕膱F(tuán)隊(duì)建立一個(gè)溝通良好的氛圍，構(gòu)建一致的架構(gòu)體系。

DDD 的設(shè)計(jì)思想、原則與模式有助于提高你的架構(gòu)設(shè)計(jì)能力。無(wú)論是在新項(xiàng)目中設(shè)計(jì)微服務(wù)，還是將系統(tǒng)從單體架構(gòu)演進(jìn)到微服務(wù)，都可以遵循 DDD 的架構(gòu)原則。

DDD 不僅適用于微服務(wù)，也適用于傳統(tǒng)的單體應(yīng)用。