寧小庚 黃曉芳

(西南科技大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 四川綿陽 621010)

微服務(wù)[1]在后端開發(fā)領(lǐng)域已經(jīng)席卷起一股風(fēng)潮。微服務(wù)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分為一組小的服務(wù)，服務(wù)之間相互協(xié)調(diào)、互相配合，為用戶最終提供價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相協(xié)作(通常是基于HTTP協(xié)議的RESTful API)。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。

但是，微服務(wù)天生的分布式特性，在傳統(tǒng)單一架構(gòu)上無須考慮的問題在微服務(wù)架構(gòu)中就會(huì)很常見，在劃分服務(wù)過程中開發(fā)人員可能會(huì)傾向于用熟悉的SOA(Service Oriented Architecture,SOA)標(biāo)準(zhǔn)進(jìn)行劃分。微服務(wù)雖然由SOA概念演化而來，但是兩者之間卻不可劃等號(hào)[2]，SOA首先要解決的是異構(gòu)應(yīng)用的服務(wù)化，而微服務(wù)強(qiáng)調(diào)的是服務(wù)拆分盡可能小，最好是獨(dú)立的原子服務(wù)。服務(wù)的劃分結(jié)果會(huì)直接影響系統(tǒng)功能，一個(gè)劃分不成熟的微服務(wù)體系可能在后期開發(fā)過程中為了保證數(shù)據(jù)一致性而導(dǎo)致分布式鎖的出現(xiàn)，這將導(dǎo)致系統(tǒng)復(fù)雜度急劇上升，不利于后期的迭代開發(fā)。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)[3](Domain Driven Design,DDD)是由 Eric Evans 最早提出的綜合軟件系統(tǒng)分析和設(shè)計(jì)的面向?qū)ο蠼７椒?，如今已?jīng)發(fā)展成為了一種針對(duì)大型復(fù)雜系統(tǒng)的領(lǐng)域建模與分析方法。它完全改變了傳統(tǒng)軟件開發(fā)工程師針對(duì)數(shù)據(jù)庫進(jìn)行的建模方法，從而將要解決的業(yè)務(wù)概念和業(yè)務(wù)規(guī)則轉(zhuǎn)換為軟件系統(tǒng)中的類型以及類型的屬性與行為，通過合理運(yùn)用面向?qū)ο蟮姆庋b、繼承和多態(tài)等設(shè)計(jì)要素，降低或隱藏整個(gè)系統(tǒng)的業(yè)務(wù)復(fù)雜性，并使得系統(tǒng)具有更好的擴(kuò)展性，以應(yīng)對(duì)紛繁多變的現(xiàn)實(shí)業(yè)務(wù)問題。

本文將在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的研究基礎(chǔ)上，結(jié)合微服務(wù)架構(gòu)的特點(diǎn)，提出一種尋找微服務(wù)邊界的方法，改進(jìn)現(xiàn)有微服務(wù)架構(gòu)設(shè)計(jì)存在的潛在的服務(wù)間耦合等問題，尋找更加良好的服務(wù)劃分方法。

1 領(lǐng)域驅(qū)動(dòng)的核心元素及設(shè)計(jì)概念

1.1 領(lǐng)域驅(qū)動(dòng)的核心元素

圖1為領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的元素組成，本文在使用領(lǐng)域驅(qū)動(dòng)尋找微服務(wù)邊界的過程中不會(huì)全部使用這些元素，僅會(huì)使用符合微服務(wù)概念的元素。可以看到領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是圍繞著領(lǐng)域模型進(jìn)行設(shè)計(jì)，通過分層結(jié)構(gòu)把每個(gè)領(lǐng)域獨(dú)立出去。用實(shí)體、值對(duì)象以及領(lǐng)域服務(wù)來標(biāo)識(shí)領(lǐng)域模型對(duì)象。這種嚴(yán)格的設(shè)計(jì)原則可以將業(yè)務(wù)邏輯約束在領(lǐng)域?qū)觾?nèi)。

圖1 領(lǐng)域驅(qū)動(dòng)的核心元素Fig.1 The core elements of domain driven design

1.2 本文用到的幾個(gè)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的概念

1.2.1 統(tǒng)一語言(Ubiquitous Language)

統(tǒng)一語言可以幫助領(lǐng)域?qū)＜?、開發(fā)團(tuán)隊(duì)、客戶能在互相理解彼此的意圖，在討論時(shí)避免產(chǎn)生歧義。利用統(tǒng)一語言，抽象出領(lǐng)域?qū)＜遗c開發(fā)人員的共識(shí)，是后繼溝通的基本準(zhǔn)則。

1.2.2 領(lǐng)域事件(Domain Event)

領(lǐng)域事件泛指在我們所建模領(lǐng)域中發(fā)生過的事件[4]。嚴(yán)格來說，領(lǐng)域事件本身也屬于統(tǒng)一語言的一個(gè)子集，在項(xiàng)目建模過程中，領(lǐng)域事件也可以成為項(xiàng)目組員的交流用語。

1.2.3 聚合(Aggregate)

聚合是由實(shí)體(Entity)組成的，實(shí)體是一個(gè)對(duì)象附帶著唯一標(biāo)識(shí)。例如在一個(gè)銀行應(yīng)用系統(tǒng)中，客戶就是實(shí)體。實(shí)體中附帶的唯一標(biāo)識(shí)符可以是數(shù)據(jù)庫中的主鍵，也可以是UUID，這個(gè)標(biāo)識(shí)符可以跨越多個(gè)子域，甚至在應(yīng)用程序結(jié)束之后仍然有效，例如公民身份證號(hào)。聚合是一個(gè)或多個(gè)實(shí)體的一致性邊界。一個(gè)聚合如果只包含一個(gè)實(shí)體，那這個(gè)實(shí)體稱為此聚合的聚合根(Aggregate Root),每個(gè)聚合中只能有一個(gè)聚合根，非聚合根實(shí)體都被聚合根實(shí)體引用。

1.2.4 限界上下文(Bounded Context)

限界上下文是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中最重要的元素。上下文(Context)是領(lǐng)域業(yè)務(wù)目標(biāo)語境，限界(Bounded)則是保護(hù)和隔離上下文的邊界，避免業(yè)務(wù)目標(biāo)的多樣而帶來的混亂和概念的不一致。限界上下文可以類比細(xì)胞膜，因?yàn)榧?xì)胞膜定義了什么在細(xì)胞內(nèi)，什么在細(xì)胞外，而且確定了哪些物質(zhì)可以通過細(xì)胞膜。因此，團(tuán)隊(duì)組織中必須首先明確地定義模型所應(yīng)用的上下文，標(biāo)記出不同模型之間的邊界和關(guān)系，通過團(tuán)隊(duì)的組織、軟件系統(tǒng)的各個(gè)部分的用法以及物理表現(xiàn)(代碼和數(shù)據(jù)庫模式等)來設(shè)置模型的邊界，在這些邊界中嚴(yán)格保持模型的一致性，而不要受到邊界之外問題的干擾和混淆。因此，限界上下文的理念與微服務(wù)的每個(gè)服務(wù)邊界范圍正好相符，這也正是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與微服務(wù)概念天生相契合的原因之一。

2 解決方案

事件風(fēng)暴[5](Event Storming)是落實(shí)領(lǐng)域驅(qū)動(dòng)的一種常用方法，使用事件風(fēng)暴能夠通過領(lǐng)域事件來識(shí)別出聚合根，組合的聚合根則又組成限界上下文，限界上下文則正是我們尋找的“微服務(wù)”的概念。本文將借助電子簽章SaaS應(yīng)用實(shí)例，介紹如何在業(yè)務(wù)中準(zhǔn)確定義領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心要素，繼而找出微服務(wù)的近似界限。

圖2 電子簽章應(yīng)用領(lǐng)域草圖Fig.2 The draft of E-signature application

圖2是此電子簽名SaaS應(yīng)用的領(lǐng)域草圖?？梢钥吹?，簽署屬于核心模塊，關(guān)系圖中的其他模塊都是為了支撐此模塊而存在，其主要負(fù)責(zé)系統(tǒng)的核心簽署功能。賬戶也是業(yè)務(wù)的核心功能，其主要用于管理系統(tǒng)中的用戶數(shù)據(jù)。財(cái)務(wù)模塊主要負(fù)責(zé)用戶消費(fèi)行為的管理。消息為系統(tǒng)的整個(gè)系統(tǒng)推送模塊。其他模塊供將來擴(kuò)展使用。

2.1 確定統(tǒng)一語言

在開發(fā)過程中，開發(fā)人員更注重從數(shù)據(jù)庫、通信機(jī)制等技術(shù)的角度進(jìn)行敘述，而精通業(yè)務(wù)的領(lǐng)域?qū)＜铱赡軐?duì)此完全不了解。例如，在電子簽章系統(tǒng)中，用戶的一個(gè)訂單對(duì)于開發(fā)人員可能就是數(shù)據(jù)庫中一條記錄，附帶著一個(gè)UUID標(biāo)識(shí)，對(duì)于領(lǐng)域?qū)＜叶裕赡苤皇怯脩舻囊淮钨徺I行為。所以在籌劃階段，開發(fā)人員應(yīng)該暫時(shí)屏蔽訂單這一概念的技術(shù)屬性，只保留其領(lǐng)域事件的屬性。

2.2 確定領(lǐng)域事件

如圖3所示，用戶下訂單，就是一個(gè)典型的領(lǐng)域事件。用戶生成一個(gè)訂單的消息可以被訂單模塊發(fā)向消息中間件，財(cái)務(wù)系統(tǒng)可以訂閱它，也可以是感興趣的第三方系統(tǒng)，這都會(huì)觸發(fā)系統(tǒng)下游事件接收者的相應(yīng)動(dòng)作。但是需要注意的是，在此例中如果一條訂單記錄成功插入數(shù)據(jù)庫則不屬于領(lǐng)域事件，因?yàn)樗粚儆陬I(lǐng)域事件的生命周期，只是技術(shù)層面的行為。用戶下單成功的領(lǐng)域事件將通過消息中間件發(fā)布出去，則不關(guān)心誰會(huì)收到消息，財(cái)務(wù)系統(tǒng)訂閱了此消息則會(huì)進(jìn)行相應(yīng)的結(jié)算處理。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)系統(tǒng)就是由這樣一個(gè)個(gè)領(lǐng)域事件組成的，這樣的消息驅(qū)動(dòng)的系統(tǒng)更易于擴(kuò)展，模塊化的系統(tǒng)健壯性極強(qiáng)。

圖3 領(lǐng)域事件之間的消息驅(qū)動(dòng)Fig.3 The message drive between domain events

同時(shí)，訂閱方服務(wù)要對(duì)接受到的消息做冪等(idempotent)處理，因?yàn)橄嗤南⒖赡軙?huì)重復(fù)發(fā)送，就要保證多次收到相同的消息只需處理一次，再次收到就要忽略。

為了便于在后續(xù)的限界上下文中尋找共同點(diǎn)，要盡可能簡明語言描述領(lǐng)域事件，在語法上采取動(dòng)賓形式。在描述時(shí)盡量避免使用諸如“管理”、“維護(hù)”等過于抽象用詞，抽象用詞容易使我們忽略隱藏的領(lǐng)域語言，缺少對(duì)領(lǐng)域的精準(zhǔn)表達(dá)[6]。以電子簽章應(yīng)用為示例，圖4是一個(gè)用領(lǐng)域事件驅(qū)動(dòng)的完整的簽署流程示例，圖中方框中的便是領(lǐng)域事件，很難在流程圖中體現(xiàn)的領(lǐng)域事件，比如“保存簽名草稿”。

2.3 確定聚合

通常來說在確定聚合的時(shí)候，要以事務(wù)的邊界為參考。如果用戶下單購買了簽名服務(wù)，則需要在財(cái)務(wù)模塊中進(jìn)行扣費(fèi)，財(cái)務(wù)模塊相關(guān)對(duì)象的屬性也要隨之改變。在傳統(tǒng)單一架構(gòu)應(yīng)用中，我們通常使用一個(gè)事務(wù)保證數(shù)據(jù)的強(qiáng)一致性，但是對(duì)于天生分布式特性的微服務(wù)來說則行不通，除非使用重量級(jí)的2PC等分布式事務(wù)[7]方式，這種方式會(huì)造成服務(wù)之間的強(qiáng)耦合，也不符合微服務(wù)的思想，反而會(huì)生成一個(gè)“分布式單一架構(gòu)”的畸形應(yīng)用，所以一般不會(huì)考慮這種方式。對(duì)于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)理念來說，聚合是數(shù)據(jù)一致性的保證，我們將強(qiáng)關(guān)聯(lián)的對(duì)象封裝到一個(gè)聚合中，由聚合根負(fù)責(zé)與外界溝通，在一個(gè)聚合中傳統(tǒng)的數(shù)據(jù)庫的事務(wù)將會(huì)保證數(shù)據(jù)一致性。

在上一節(jié)中我們利用動(dòng)賓等語法定義了一眾領(lǐng)域事件，我們從語義的角度去剖析領(lǐng)域活動(dòng)的描述，如果語義相近，則可以歸為一類，例如，賬戶注冊(cè)，找回賬戶顯然可以歸為一類賬戶領(lǐng)域，可以考慮劃為賬戶限界上下文，但是有時(shí)又會(huì)有兩種描述語義相近，比如“注冊(cè)賬戶”，“賬戶認(rèn)證”都具有“賬戶”與“認(rèn)證”的“語義”，認(rèn)證行為是否要屬于賬戶上下文，這時(shí)就要以哪個(gè)語義為標(biāo)準(zhǔn)就需要考慮每種語義相關(guān)性的耦合程度為劃分標(biāo)準(zhǔn)。由此可以劃分為同一個(gè)限界上下文中，但是同一個(gè)限界上下文中由于在不同的事務(wù)中，又需要?jiǎng)澐譃椴煌木酆稀Ｈ绻麑ⅰ罢J(rèn)證”和“賬戶”劃分為同一個(gè)上下文，這是就要把賬戶和認(rèn)證分為兩個(gè)聚合，賬戶的聚合根可以是每一個(gè)用戶的唯一標(biāo)識(shí)符，比如用戶在數(shù)據(jù)庫中的UUID，也可以是用戶的身份證號(hào)碼。同樣的，“認(rèn)證”上下文也需要自己的聚合根。但是由于不在一個(gè)聚合中，由于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)事務(wù)不能跨越多個(gè)聚合的原則，就需要借助消息中間件來傳遞消息，通過領(lǐng)域事件將各個(gè)模塊最大程度解耦，達(dá)到基于事件的最終一致性(Eventually Consistency)。最終劃分出來的聚合如表1所示。

表1 模塊內(nèi)的聚合Table 1 Aggregations in modules

2.4 確定限界上下文

具體劃定邊界的時(shí)候可以從3個(gè)方面入手：(1)領(lǐng)域邏輯層面，它從領(lǐng)域模型的角度高度抽象，維護(hù)模型的一致性，降低系統(tǒng)的復(fù)雜度；(2)團(tuán)隊(duì)合作層面，它限定了不同開發(fā)團(tuán)隊(duì)的的工作邊界，避免團(tuán)隊(duì)的混亂溝通，從而降低系統(tǒng)的管理復(fù)雜度；(3)技術(shù)實(shí)現(xiàn)層面，它限定了了系統(tǒng)架構(gòu)的應(yīng)用邊界，保證系統(tǒng)和上下文領(lǐng)域?qū)拥母髯砸恢滦裕瑥亩档拖到y(tǒng)的技術(shù)復(fù)雜度。

以上3種劃分方式對(duì)應(yīng)著對(duì)不同層面的控制力。在我們劃分服務(wù)的時(shí)候采用領(lǐng)域邏輯層面的方法，最終確定下來的限界上下文以及其中的聚合如圖5所示，每個(gè)限界上下文可以作為我們的一個(gè)微服務(wù)邊界。我們這一步具有里程碑意義，業(yè)務(wù)隨后的一切擴(kuò)展變化都將在此領(lǐng)域模型中迭代完善。

從圖5可以看到，系統(tǒng)分為了5個(gè)限界上下文，在文件限界上下文分別有下載和版本兩個(gè)聚合，負(fù)責(zé)不同的業(yè)務(wù)邊界。在原來財(cái)務(wù)模塊中，分化出訂單以及余額兩個(gè)聚合。賬戶模塊分化出用戶和認(rèn)證兩個(gè)聚合。核心子域簽署則有簽名和驗(yàn)簽兩個(gè)聚合。消息限界上下文有系統(tǒng)推送和第三方兩個(gè)聚合構(gòu)成。

圖5 電子簽章的限界上下文與聚合Fig.5 E-signature applications bounded contexts and aggregations

對(duì)于第二種的團(tuán)隊(duì)合作層面，由于康威定律[8]的限制，組織和系統(tǒng)架構(gòu)之間有一一映射的關(guān)系，如果兩者不能對(duì)齊就會(huì)出現(xiàn)例如集中式和嚴(yán)格職能的組織，這樣的組織結(jié)構(gòu)都傾向于局部優(yōu)化，無法形成有效的合作閉環(huán)。因此，結(jié)合領(lǐng)域設(shè)計(jì)思路，我們將領(lǐng)域的劃分、微服務(wù)的劃分和人員組織進(jìn)行匹配，這也要求組織內(nèi)的開發(fā)人員也要基于每個(gè)限界上下文的不同拆分分配部門。

第三種技術(shù)層面的劃分要求每個(gè)服務(wù)要有單獨(dú)的服務(wù)能力，要有獨(dú)立的數(shù)據(jù)庫。如圖5，對(duì)于每一個(gè)模塊都要考慮其數(shù)據(jù)的存儲(chǔ)和部署，例如，對(duì)于消息服務(wù)模塊而言，由于消息服務(wù)其存儲(chǔ)內(nèi)容的多變性[9]，可以考慮MongoDB，Redis等NoSQL數(shù)據(jù)庫。

經(jīng)過上述3個(gè)步驟可以大致確定系統(tǒng)微服務(wù)的邊界以及每個(gè)服務(wù)需要的開發(fā)人員配置，并且在業(yè)務(wù)變化中還可以進(jìn)行拆分，達(dá)到解耦復(fù)用。

2.5 分析與比較

傳統(tǒng)的微服務(wù)的劃分方式是以模塊來劃分，數(shù)據(jù)庫先行。根據(jù)數(shù)據(jù)庫進(jìn)行隱式建模，但是這種簡單劃分會(huì)造成潛在的服務(wù)間耦合，而且將來服務(wù)擴(kuò)展會(huì)被先前的數(shù)據(jù)庫設(shè)計(jì)限制。隨著版本迭代，服務(wù)間耦合越來越嚴(yán)重，甚至在某一個(gè)服務(wù)調(diào)用失敗的情況下，造成雪崩效應(yīng)，導(dǎo)致應(yīng)用的癱瘓。而采用本文提出的基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的微服務(wù)劃分方法，各個(gè)服務(wù)之間依賴領(lǐng)域事件的驅(qū)動(dòng)完成通信，符合高內(nèi)聚、低耦合的面向?qū)ο笤O(shè)計(jì)原則，將一個(gè)又一個(gè)的領(lǐng)域事件形成一個(gè)完整的業(yè)務(wù)閉環(huán)。同時(shí)，數(shù)據(jù)庫詳細(xì)設(shè)計(jì)可以在劃分完畢的微服務(wù)模塊和領(lǐng)域事件的基礎(chǔ)上確定，整體上是一個(gè)可插拔的模塊化設(shè)計(jì)，最大程度上規(guī)避了傳統(tǒng)劃分方式所帶來的設(shè)計(jì)缺陷。通過對(duì)一個(gè)電子簽章SaaS應(yīng)用實(shí)例采用該方法，找出該SaaS應(yīng)用微服務(wù)的近似界限，實(shí)現(xiàn)了服務(wù)的良好劃分，提高了系統(tǒng)的彈性。

3 結(jié)束語

在將領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的戰(zhàn)略設(shè)計(jì)模式引入到架構(gòu)過程中，會(huì)發(fā)現(xiàn)限界上下文不僅限于對(duì)領(lǐng)域模型的控制，而在于分離關(guān)注點(diǎn)之后使得整個(gè)上下文可以成為獨(dú)立部署的設(shè)計(jì)單元，這就是“微服務(wù)”的概念。上下文映射的諸多模式則對(duì)應(yīng)了微服務(wù)之間的協(xié)作，因此在戰(zhàn)略設(shè)計(jì)階段，微服務(wù)擴(kuò)展了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的內(nèi)容，反過來領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)又能夠保證良好的微服務(wù)設(shè)計(jì)。

本文采用事件風(fēng)暴的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)原則實(shí)現(xiàn)微服務(wù)應(yīng)用的系統(tǒng)分析，根據(jù)領(lǐng)域事件的語義相關(guān)性判斷，逐步劃分出限界上下文模型，最后得到每個(gè)微服務(wù)的近似邊界，給劃分服務(wù)過程提供了科學(xué)依據(jù)，降低了微服務(wù)設(shè)計(jì)的門檻，提高開發(fā)效率，并且能適應(yīng)需求的變化，服務(wù)具備高可擴(kuò)展性。

目前，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概念還比較晦澀，學(xué)習(xí)曲線比較陡峭，對(duì)開發(fā)人員的平均水平要求較高，因此領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)應(yīng)用在大型項(xiàng)目上更能發(fā)揮其威力，如何讓其適用于小型應(yīng)用團(tuán)隊(duì)還需要進(jìn)一步研究。