一種基于領域驅動設計劃分微服務的方法

寧小庚 黃曉芳

(西南科技大學計算機科學與技術學院 四川綿陽 621010)

微服務[1]在后端開發領域已經席卷起一股風潮。微服務是一種架構模式，它提倡將單一應用程序劃分為一組小的服務，服務之間相互協調、互相配合，為用戶最終提供價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協作(通常是基于HTTP協議的RESTful API)。每個服務都圍繞著具體業務進行構建，并且能夠被獨立的部署到生產環境、類生產環境等。

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

領域驅動設計[3](Domain Driven Design,DDD)是由 Eric Evans 最早提出的綜合軟件系統分析和設計的面向對象建模方法，如今已經發展成為了一種針對大型復雜系統的領域建模與分析方法。它完全改變了傳統軟件開發工程師針對數據庫進行的建模方法，從而將要解決的業務概念和業務規則轉換為軟件系統中的類型以及類型的屬性與行為，通過合理運用面向對象的封裝、繼承和多態等設計要素，降低或隱藏整個系統的業務復雜性，并使得系統具有更好的擴展性，以應對紛繁多變的現實業務問題。

本文將在領域驅動設計的研究基礎上，結合微服務架構的特點，提出一種尋找微服務邊界的方法，改進現有微服務架構設計存在的潛在的服務間耦合等問題，尋找更加良好的服務劃分方法。

1 領域驅動的核心元素及設計概念

1.1 領域驅動的核心元素

圖1為領域驅動設計的元素組成，本文在使用領域驅動尋找微服務邊界的過程中不會全部使用這些元素，僅會使用符合微服務概念的元素。可以看到領域驅動設計是圍繞著領域模型進行設計，通過分層結構把每個領域獨立出去。用實體、值對象以及領域服務來標識領域模型對象。這種嚴格的設計原則可以將業務邏輯約束在領域層內。

圖1 領域驅動的核心元素Fig.1 The core elements of domain driven design

1.2 本文用到的幾個領域驅動設計的概念

1.2.1 統一語言(Ubiquitous Language)

統一語言可以幫助領域專家、開發團隊、客戶能在互相理解彼此的意圖，在討論時避免產生歧義。利用統一語言，抽象出領域專家與開發人員的共識，是后繼溝通的基本準則。

1.2.2 領域事件(Domain Event)

領域事件泛指在我們所建模領域中發生過的事件[4]。嚴格來說，領域事件本身也屬于統一語言的一個子集，在項目建模過程中，領域事件也可以成為項目組員的交流用語。

1.2.3 聚合(Aggregate)

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

1.2.4 限界上下文(Bounded Context)

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

2 解決方案

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

圖2 電子簽章應用領域草圖Fig.2 The draft of E-signature application

圖2是此電子簽名SaaS應用的領域草圖。可以看到，簽署屬于核心模塊，關系圖中的其他模塊都是為了支撐此模塊而存在，其主要負責系統的核心簽署功能。賬戶也是業務的核心功能，其主要用于管理系統中的用戶數據。財務模塊主要負責用戶消費行為的管理。消息為系統的整個系統推送模塊。其他模塊供將來擴展使用。

2.1 確定統一語言

在開發過程中，開發人員更注重從數據庫、通信機制等技術的角度進行敘述，而精通業務的領域專家可能對此完全不了解。例如，在電子簽章系統中，用戶的一個訂單對于開發人員可能就是數據庫中一條記錄，附帶著一個UUID標識，對于領域專家而言，可能只是用戶的一次購買行為。所以在籌劃階段，開發人員應該暫時屏蔽訂單這一概念的技術屬性，只保留其領域事件的屬性。

2.2 確定領域事件

如圖3所示，用戶下訂單，就是一個典型的領域事件。用戶生成一個訂單的消息可以被訂單模塊發向消息中間件，財務系統可以訂閱它，也可以是感興趣的第三方系統，這都會觸發系統下游事件接收者的相應動作。但是需要注意的是，在此例中如果一條訂單記錄成功插入數據庫則不屬于領域事件，因為它不屬于領域事件的生命周期，只是技術層面的行為。用戶下單成功的領域事件將通過消息中間件發布出去，則不關心誰會收到消息，財務系統訂閱了此消息則會進行相應的結算處理。領域驅動設計系統就是由這樣一個個領域事件組成的，這樣的消息驅動的系統更易于擴展，模塊化的系統健壯性極強。

圖3 領域事件之間的消息驅動Fig.3 The message drive between domain events

同時，訂閱方服務要對接受到的消息做冪等(idempotent)處理，因為相同的消息可能會重復發送，就要保證多次收到相同的消息只需處理一次，再次收到就要忽略。

為了便于在后續的限界上下文中尋找共同點，要盡可能簡明語言描述領域事件，在語法上采取動賓形式。在描述時盡量避免使用諸如“管理”、“維護”等過于抽象用詞，抽象用詞容易使我們忽略隱藏的領域語言，缺少對領域的精準表達[6]。以電子簽章應用為示例，圖4是一個用領域事件驅動的完整的簽署流程示例，圖中方框中的便是領域事件，很難在流程圖中體現的領域事件，比如“保存簽名草稿”。

2.3 確定聚合

通常來說在確定聚合的時候，要以事務的邊界為參考。如果用戶下單購買了簽名服務，則需要在財務模塊中進行扣費，財務模塊相關對象的屬性也要隨之改變。在傳統單一架構應用中，我們通常使用一個事務保證數據的強一致性，但是對于天生分布式特性的微服務來說則行不通，除非使用重量級的2PC等分布式事務[7]方式，這種方式會造成服務之間的強耦合，也不符合微服務的思想，反而會生成一個“分布式單一架構”的畸形應用，所以一般不會考慮這種方式。對于領域驅動設計理念來說，聚合是數據一致性的保證，我們將強關聯的對象封裝到一個聚合中，由聚合根負責與外界溝通，在一個聚合中傳統的數據庫的事務將會保證數據一致性。

在上一節中我們利用動賓等語法定義了一眾領域事件，我們從語義的角度去剖析領域活動的描述，如果語義相近，則可以歸為一類，例如，賬戶注冊，找回賬戶顯然可以歸為一類賬戶領域，可以考慮劃為賬戶限界上下文，但是有時又會有兩種描述語義相近，比如“注冊賬戶”，“賬戶認證”都具有“賬戶”與“認證”的“語義”，認證行為是否要屬于賬戶上下文，這時就要以哪個語義為標準就需要考慮每種語義相關性的耦合程度為劃分標準。由此可以劃分為同一個限界上下文中，但是同一個限界上下文中由于在不同的事務中，又需要劃分為不同的聚合。如果將“認證”和“賬戶”劃分為同一個上下文，這是就要把賬戶和認證分為兩個聚合，賬戶的聚合根可以是每一個用戶的唯一標識符，比如用戶在數據庫中的UUID，也可以是用戶的身份證號碼。同樣的，“認證”上下文也需要自己的聚合根。但是由于不在一個聚合中，由于領域驅動設計事務不能跨越多個聚合的原則，就需要借助消息中間件來傳遞消息，通過領域事件將各個模塊最大程度解耦，達到基于事件的最終一致性(Eventually Consistency)。最終劃分出來的聚合如表1所示。

表1 模塊內的聚合Table 1 Aggregations in modules

2.4 確定限界上下文

具體劃定邊界的時候可以從3個方面入手：(1)領域邏輯層面，它從領域模型的角度高度抽象，維護模型的一致性，降低系統的復雜度；(2)團隊合作層面，它限定了不同開發團隊的的工作邊界，避免團隊的混亂溝通，從而降低系統的管理復雜度；(3)技術實現層面，它限定了了系統架構的應用邊界，保證系統和上下文領域層的各自一致性，從而降低系統的技術復雜度。

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

從圖5可以看到，系統分為了5個限界上下文，在文件限界上下文分別有下載和版本兩個聚合，負責不同的業務邊界。在原來財務模塊中，分化出訂單以及余額兩個聚合。賬戶模塊分化出用戶和認證兩個聚合。核心子域簽署則有簽名和驗簽兩個聚合。消息限界上下文有系統推送和第三方兩個聚合構成。

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

對于第二種的團隊合作層面，由于康威定律[8]的限制，組織和系統架構之間有一一映射的關系，如果兩者不能對齊就會出現例如集中式和嚴格職能的組織，這樣的組織結構都傾向于局部優化，無法形成有效的合作閉環。因此，結合領域設計思路，我們將領域的劃分、微服務的劃分和人員組織進行匹配，這也要求組織內的開發人員也要基于每個限界上下文的不同拆分分配部門。

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

經過上述3個步驟可以大致確定系統微服務的邊界以及每個服務需要的開發人員配置，并且在業務變化中還可以進行拆分，達到解耦復用。

2.5 分析與比較

傳統的微服務的劃分方式是以模塊來劃分，數據庫先行。根據數據庫進行隱式建模，但是這種簡單劃分會造成潛在的服務間耦合，而且將來服務擴展會被先前的數據庫設計限制。隨著版本迭代，服務間耦合越來越嚴重，甚至在某一個服務調用失敗的情況下，造成雪崩效應，導致應用的癱瘓。而采用本文提出的基于領域驅動設計的微服務劃分方法，各個服務之間依賴領域事件的驅動完成通信，符合高內聚、低耦合的面向對象設計原則，將一個又一個的領域事件形成一個完整的業務閉環。同時，數據庫詳細設計可以在劃分完畢的微服務模塊和領域事件的基礎上確定，整體上是一個可插拔的模塊化設計，最大程度上規避了傳統劃分方式所帶來的設計缺陷。通過對一個電子簽章SaaS應用實例采用該方法，找出該SaaS應用微服務的近似界限，實現了服務的良好劃分，提高了系統的彈性。

3 結束語

在將領域驅動設計的戰略設計模式引入到架構過程中，會發現限界上下文不僅限于對領域模型的控制，而在于分離關注點之后使得整個上下文可以成為獨立部署的設計單元，這就是“微服務”的概念。上下文映射的諸多模式則對應了微服務之間的協作，因此在戰略設計階段，微服務擴展了領域驅動設計的內容，反過來領域驅動設計又能夠保證良好的微服務設計。

本文采用事件風暴的領域驅動設計原則實現微服務應用的系統分析，根據領域事件的語義相關性判斷，逐步劃分出限界上下文模型，最后得到每個微服務的近似邊界，給劃分服務過程提供了科學依據，降低了微服務設計的門檻，提高開發效率，并且能適應需求的變化，服務具備高可擴展性。

目前，領域驅動設計概念還比較晦澀，學習曲線比較陡峭，對開發人員的平均水平要求較高，因此領域驅動設計應用在大型項目上更能發揮其威力，如何讓其適用于小型應用團隊還需要進一步研究。