微服務(wù)與領(lǐng)域驅(qū)動設(shè)計（DDD）有著共生關(guān)系。所謂領(lǐng)域驅(qū)動設(shè)計是一種設(shè)計方法，在這種方法中我們基于業(yè)務(wù)領(lǐng)域涉及的內(nèi)容用軟件精心搭建出一套模型，這套模型隨著時間的推移而逐漸發(fā)展，但并不受運行系統(tǒng)的管道約束。我發(fā)現(xiàn)人們喜歡將這種模式與 Apache Kafka 結(jié)合起來，這種組合在實踐中也運用得越來越多了。在這類項目中，微服務(wù)架構(gòu)通常使用 Kafka 作為事件流平臺；而領(lǐng)域驅(qū)動設(shè)計方法則用來定義各種有界上下文，這些上下文表示應(yīng)用需要執(zhí)行的各種業(yè)務(wù)流程。它們與各種事件結(jié)合在一起，創(chuàng)建了一個將各個有界上下文與下游出現(xiàn)的上下文分離的單向依賴圖，以創(chuàng)建豐富多樣的事件流業(yè)務(wù)應(yīng)用。本文將探討為什么 Apache Kafka 會成為微服務(wù)架構(gòu)事實上的標(biāo)準(zhǔn)和主干——Kafka 不僅取代了其他傳統(tǒng)的中間件，而且人們還使用 DDD 和 Kafka 原生 API（如 Kafka Streams、KSQL 和 Kafka Connect）直接構(gòu)建微服務(wù)。 1 微服務(wù)

如今人們都想用微服務(wù)創(chuàng)建敏捷而靈活的架構(gòu)，微服務(wù)這個術(shù)語在很多環(huán)境中都很常見。

雖然微服務(wù)并不是什么免費的午餐，但它們確實提供了許多好處，解耦就是其中一項優(yōu)勢。解耦是圍繞業(yè)務(wù)功能來組織系統(tǒng)，以形成分散的體系結(jié)構(gòu)的過程。其中智能端點和啞管道（dumb pipe）會確保：

基于微服務(wù)構(gòu)建的應(yīng)用程序需要盡可能分散開來，同時還保持緊密的協(xié)作關(guān)系——它們擁有自己的領(lǐng)域邏輯（這些邏輯針對的是各自需要處理的業(yè)務(wù)問題），且行為更像是經(jīng)典的 Unix 系統(tǒng)中的過濾器——接收一個請求，對其應(yīng)用合適的邏輯并生成回應(yīng)?！?Martin Fowler

https://martinfowler.com/articles/microservices.html

2 Apache Kafka——微服務(wù)的事件流平臺

應(yīng)該使用哪些技術(shù)來構(gòu)建微服務(wù)架構(gòu)？這個問題可以分為兩部分來回答：

1. 微服務(wù)之間怎樣相互通信？

當(dāng)我們考慮微服務(wù)之間的通信問題時（比如說與同步 HTTP(S) 調(diào)用進(jìn)行通信），大多數(shù)人一開始會使用 REST 這個方法。很多用戶場景都可以使用這種方法。但是，請求——響應(yīng)模式所創(chuàng)建的點對點連接會將發(fā)送方與接收方的通信來往耦合在一起，這樣就很難在不影響其他組件的情況下更改某個組件。

因此許多架構(gòu)師使用中間件作為微服務(wù)通信的主干，以創(chuàng)建解耦、可擴(kuò)展和高度可用的系統(tǒng)。很多東西都能拿來用作中間件——比如說一些自定義粘合代碼或框架、像 RabbitMQ 這樣的消息傳遞系統(tǒng)、像 Talend 這樣的 ETL 工具、像 WSO2 這樣的 ESB，或者像 Apache Kafka 這樣的事件流平臺。

2. 如果你要使用中間件，該用哪個？

Apache Kafka 之所以能成為微服務(wù)事實上的標(biāo)準(zhǔn)，主要原因是它融合了三個強(qiáng)大的概念：

發(fā)布和訂閱事件流，類似于消息隊列或企業(yè)消息傳遞系統(tǒng)

以容錯方式存儲事件流

在事件流發(fā)生時實時處理

Kafka 將這三大支柱一起內(nèi)置到了一個分布式事件流平臺中，這樣用戶就可以用可靠、可擴(kuò)展和容錯的方式將各種微服務(wù)（例如生產(chǎn)者和消費者）分離開來。

為了更好地理解 Apache Kafka 相比傳統(tǒng)中間件（如 MQ、ETL 或 ESB 工具）的優(yōu)勢，請參閱”Apache Kafka vs 企業(yè)服務(wù)總線——朋友，敵人還是亦敵亦友？”

下面探討像 Apache Kafka 這樣的事件流平臺是怎樣與領(lǐng)域驅(qū)動設(shè)計方法建立聯(lián)系的。

3 用于構(gòu)建和解耦微服務(wù)的領(lǐng)域驅(qū)動設(shè)計方法（DDD）

領(lǐng)域驅(qū)動設(shè)計（DDD）最早是由 Eric Evans 在他的一本著作中提出來的方法，用于構(gòu)建包含復(fù)雜業(yè)務(wù)領(lǐng)域的系統(tǒng)。也就是說你不會將 DDD 應(yīng)用于基礎(chǔ)架構(gòu)軟件或構(gòu)建路由器、代理或緩存層之類的項目中，而是會應(yīng)用到解決實際業(yè)務(wù)問題的軟件項目上。這種技術(shù)很好用，可以將業(yè)務(wù)模型與將各種模型連接在一起的管道代碼分離開來。將這兩部分在軟件層面分離開來之后，團(tuán)隊就很容易去設(shè)計、建模、構(gòu)建并改進(jìn)具體的產(chǎn)品實現(xiàn)。

DDD 方法基于下列原則：

https://techbeacon.com/app-dev-testing/get-your-feet-wet-domain-driven-design-3-guiding-principles

團(tuán)隊需要與領(lǐng)域?qū)＜医涣?，從而使用領(lǐng)域術(shù)語搭建領(lǐng)域模型

在領(lǐng)域代碼中嵌入領(lǐng)域術(shù)語

保護(hù)領(lǐng)域知識免受來自其他領(lǐng)域和技術(shù)子域的損害

本文討論的 DDD 核心概念是有界上下文。大型項目通常有許多種領(lǐng)域模型和有界上下文。但開發(fā)人員將不同種類有界上下文中的代碼組合在一起的過程中，軟件系統(tǒng)可能會變得越來越不可靠且難以理解。團(tuán)隊成員之間越來越難溝通，而且人們通常很難搞清楚某個模型不該應(yīng)用在哪些上下文中。

因此，DDD 要求我們明確定義每個模型所應(yīng)用的上下文對象。我們在設(shè)置邊界時需要考慮下列因素：哪個團(tuán)隊擁有該模型、應(yīng)用程序特定部分的用途、以及諸如代碼庫和數(shù)據(jù)庫 schema 之類的物理表現(xiàn)等。將各個模型嚴(yán)格約束在自己的邊界內(nèi)后，各個部分就更容易實現(xiàn)和理解，因為我們只需要考慮每個部分所屬的一個有界上下文就夠了。我們不用再因為其他人泄露的代碼而分散精力或感到困惑。正如 Dan North 所說：“專心構(gòu)建你負(fù)責(zé)的代碼，不用想太多”。

https://www.youtube.com/watch?v=4Y0tOi7QWqM

一個事件流平臺可能看起來像這樣：

在平臺中每個微服務(wù)都有自己的有界上下文。從技術(shù)角度來看，這可能涉及不同的 API、框架、通信協(xié)議和數(shù)據(jù)存儲等。有些部分遵循請求——響應(yīng)模式，而其他部分則根據(jù)需要解決的問題來使用事件?？偠灾總€部分都是一個單獨的有界上下文，擁有屬于自己的領(lǐng)域模型，并在該模型、業(yè)務(wù)流程和它與其他部分共享的數(shù)據(jù)之間建立映射。

那么為什么 Kafka 就是事件流平臺的不二之選呢？

4 Apache Kafka 和領(lǐng)域驅(qū)動的微服務(wù)

Apache Kafka 結(jié)合了消息傳遞和存儲能力，使不同的生產(chǎn)者和消費者之間能夠完全解耦：

服務(wù)端（Kafka broker、ZooKeeper 和 Confluent Schema 注冊表）可以與業(yè)務(wù)應(yīng)用之間分離開來。

生產(chǎn)者不知道或不關(guān)心是誰在消費它們創(chuàng)造的事件。Kafka 為他們處理背壓、解決可擴(kuò)展性和高可用性需求。

生產(chǎn)者的生產(chǎn)工作不受消費者下線影響。

就算新的消費者需要從較早的時間戳開始消費事件，它們也可以隨時添加進(jìn)來。

消費者可以以自己的節(jié)奏（批量或?qū)崟r）處理數(shù)據(jù)。

消費者可以反復(fù)處理數(shù)據(jù)（例如訓(xùn)練不同的分析模型或從錯誤和數(shù)據(jù)損壞中恢復(fù)）。

有了這些特性，項目團(tuán)隊就都能擁有自己的領(lǐng)域了；這些領(lǐng)域可以有不同的職責(zé)、SLA、版本控制和技術(shù)選擇。

這種方法不僅適用于業(yè)務(wù)應(yīng)用，也適用于公司 IT 團(tuán)隊的運營工作；運營團(tuán)隊可以擁有用于內(nèi)部自助服務(wù)的 Kafka 集群。Kafka 集群通常基于 PaaS 架構(gòu)部署，例如 Kubernetes 和 Confluent Operator 等。如果使用基于 Confluent Cloud 等托管服務(wù)的云部署方案，則通常不需要此類基礎(chǔ)架構(gòu)團(tuán)隊。

5 領(lǐng)域模型、有界上下文和通用語言

如上所述，領(lǐng)域驅(qū)動設(shè)計（DDD）的關(guān)鍵元素之一是將業(yè)務(wù)問題分離為許多獨立的有界上下文的集合。每個上下文都有一個領(lǐng)域模型，將所需數(shù)據(jù)完全封裝在軟件里，還包括需要執(zhí)行的業(yè)務(wù)操作以及用于描述這些元素的語言。但是，某個有界上下文中的領(lǐng)域模型該怎樣與其他上下文中的模型建立聯(lián)系呢？我們?nèi)绾伪ＷC一個模型中的更改不會對其他領(lǐng)域模型產(chǎn)生負(fù)面影響？

答案就是使用在 DDD 中被稱為反腐層（anti-corruption layer）的方法：反腐層將領(lǐng)域模型中使用的數(shù)據(jù)映射到在各個微服務(wù)或有界上下文之間傳輸?shù)臄?shù)據(jù)上。這個模式與具體的實現(xiàn)無關(guān)，這意味著無論你的服務(wù)是通過事件還是通過請求——響應(yīng)協(xié)議通信，都可以使用反腐層。在這兩種通信方式下通常都會有一種有線格式（可以是用來從 REST 端點返回數(shù)據(jù)的 schema，或是用來描述事件的 schema，例如存儲在 Schema 注冊表中的 Avro 消息）。

反腐層有兩大職責(zé)：

它讓領(lǐng)域模型不受其他模型的更改影響

它封裝了上下文之間的邊界，并描述了它們之間的映射。這種映射既能從技術(shù)意義上描述，例如一條消息中的字段 A 映射到模型中的字段 B；也能基于 DDD 的通用語言描述——將事件 schema 中的對手（counterparty）映射到領(lǐng)域模型中的客戶（customer）。

每個有界上下文中的模型都會進(jìn)化發(fā)展，而團(tuán)隊在設(shè)計改進(jìn)模型的過程中，要經(jīng)歷的一項關(guān)鍵步驟就是設(shè)計將各個模型連接在一起的接口。要走好這一步，首先應(yīng)該由開發(fā)人員和擁有系統(tǒng)的利益相關(guān)方共同開發(fā)一種通用語言。

6 使用Apache Kafka、Kafka Streams、KSQL和Kafka Connect 將各個領(lǐng)域連接起來

還有一個關(guān)鍵要點我們還沒討論過：Apache Kafka 不僅是一個消息系統(tǒng)或者一個集成層——它是一個事件流平臺。這意味著它不僅負(fù)責(zé)提供用來解耦微服務(wù)的中間件，還允許你在客戶端代碼中執(zhí)行復(fù)雜的數(shù)據(jù)操作，如拆分、連接、過濾和匯總等。這是 Apache Kafka 和傳統(tǒng)中間件之間的另一大區(qū)別所在，正如 ThoughtWorks 所解釋的那樣：

……我們看到一些組織將許多 Kafka 生態(tài)系統(tǒng)組件（例如連接器和流處理器）集中在一起，使用 Kafka 重建了 ESB 這種反模式，而不是讓這些組件與產(chǎn)品或服務(wù)團(tuán)隊共存。ESB 模式有著很嚴(yán)重的問題，人們將越來越多的邏輯、編排和轉(zhuǎn)換推入集中管理的 ESB 中，不得不愈加依賴中心化的團(tuán)隊。我們指出這一現(xiàn)象就是想讓人們不要再推進(jìn)這種有缺陷的模式了。“使用 Kafka 重建 ESB 反模式”

https://www.thoughtworks.com/radar/techniques/recreating-esb-antipatterns-with-kafka

這一點是很重要的。ESB 之所以會包含復(fù)雜的邏輯、編排和轉(zhuǎn)換并不是偶然產(chǎn)物，而是因為人們正在構(gòu)建的業(yè)務(wù)流程需要它們。ThoughtWorks 的觀點并不是說這些過程本身是問題所在，或者沒什么必要，而是說問題出在這些過程被推出了本應(yīng)擁有它們的應(yīng)用所在的邊界，并推入了中心化的基礎(chǔ)架構(gòu)中。這種中心化的基礎(chǔ)架構(gòu)和業(yè)務(wù)邏輯導(dǎo)致軟件愈加脆弱，難以發(fā)展——這正是現(xiàn)代化的敏捷軟件項目最不想看到的結(jié)果。

事件流系統(tǒng)則使用另一種方式處理這個問題。它們基于啞管道（可高度擴(kuò)展）和智能過濾器構(gòu)建；要注意這些過濾器比以往的設(shè)計更強(qiáng)大、功能更多。嵌入在微服務(wù)中的過濾器具有現(xiàn)代流處理引擎的所有功能。沒有中心化的邏輯，一切都是完全分散的，這意味著每個有界上下文都有自己的業(yè)務(wù)邏輯、編排和轉(zhuǎn)換等等。

因此，使用 Kafka 作為中樞系統(tǒng)后，你就可以使用流處理工具提供的更高級抽象來連接在各個有界上下文中創(chuàng)建的模型了。

這樣你就可以充分利用 DDD 的所有優(yōu)勢，同時避免 ESB 導(dǎo)致的種種麻煩——諸如緊密耦合、集中管理整個業(yè)務(wù)流程等。

具體選擇實現(xiàn)哪個微服務(wù)完全取決于團(tuán)隊的工作需要。你們的微服務(wù)可以使用簡單的技術(shù)接口，如 REST 或 JMS 這樣只用來通信的接口。你們也可以構(gòu)建真正的事件流式微服務(wù)，充分利用流處理的能力來操縱事件數(shù)據(jù)流并將其映射到你們的內(nèi)部模型上。

前面的例子中提到了許多種微服務(wù)。有些情況下會使用 REST（例如在微服務(wù)和 UI 之間通信），有些則使用 Kafka Streams 或 KSQL 將不同來源的事件連接在一起。還有的情況下會使用 Kafka Connect 將事件簡單地推送到數(shù)據(jù)庫中，以便進(jìn)一步操作或直接通過事件源模式使用事件。每個微服務(wù)都可以選擇自己獨立的技術(shù)實現(xiàn)，與其他微服務(wù)和它們選擇的技術(shù)無關(guān)。

如何構(gòu)建這樣的系統(tǒng)人們很容易想到使用 REST、gRPC 或其他一些請求——響應(yīng)協(xié)議構(gòu)建分散的事件流微服務(wù)。但對許多人來說，構(gòu)建一種基于事件的系統(tǒng)更是觀念上的變革。用事件構(gòu)建系統(tǒng)的方式是多種多樣的。它們可以用于“發(fā)后即忘”消息傳輸，也可以用作協(xié)作手段。Ben Stopford 的博客文章“在事件的基礎(chǔ)上構(gòu)建服務(wù)”進(jìn)一步解釋了這些模式。

你還必須決定該如何管理狀態(tài)?？梢允褂?Kafka Connect 等技術(shù)在數(shù)據(jù)庫中管理，也可以使用 Kafka Streams API 在托管服務(wù)中管理。關(guān)于構(gòu)建有狀態(tài)事件流的微服務(wù)，可以參閱 Ben Stopford 的博客文章“使用 Kafka Streams 和 KSQL 構(gòu)建微服務(wù)生態(tài)系統(tǒng)”。

要從宏觀層面了解如何將 Connect、Kafka Streams 和微服務(wù)組合在一起，可以參閱 Yeva Byzek 的一篇寫得很棒的文章。

https://www.confluent.io/blog/stream-processing-part-1-tutorial-developing-streaming-applications

最后，構(gòu)建微服務(wù)生態(tài)系統(tǒng)只是問題的第一部分。生態(tài)系統(tǒng)構(gòu)建完成后，你需要對其檢測、控制和操作。具體內(nèi)容可參閱這篇文章。

https://www.confluent.io/blog/journey-to-event-driven-part-4-four-pillars-of-event-streaming-microservices

還有一件事值得一提，就是 Confluent 的 RBAC 功能；它允許在 Confluent 平臺上執(zhí)行基于角色的訪問控制。你可以詳細(xì)配置每個域組可以訪問的資源（如 Kafka 主題、Schema 注冊表或連接器等）。

只需挑選最適合你的架構(gòu)即可。例如，你可以讓每個 Kafka Connect 群集由負(fù)責(zé)它的領(lǐng)域團(tuán)隊運營，或者把 Kafka Connect 托管為 Kafka 群集的一部分，并允許團(tuán)隊為其部署連接器。

有這么多工具幫助你使用 DDD 方法構(gòu)建和運行基于微服務(wù)的系統(tǒng)，我希望你能從中獲益多多。

7 Apache Kafka+領(lǐng)域驅(qū)動設(shè)計（DDD）=解耦事件流微服務(wù)

雖然有許多方法可以構(gòu)建微服務(wù)架構(gòu)，但領(lǐng)域驅(qū)動設(shè)計（DDD）中描述的方法無疑是最強(qiáng)大的，特別是當(dāng)你構(gòu)建的系統(tǒng)具有復(fù)雜的業(yè)務(wù)領(lǐng)域（例如醫(yī)療保健、金融、保險、 零售）時更是如此。

DDD 中的許多設(shè)計原則都能直接用于事件驅(qū)動系統(tǒng)，有一些原則本文還沒具體涉及到；我強(qiáng)調(diào)的是最常見的技術(shù)挑戰(zhàn)：如何將應(yīng)用分離到各個有界上下文中，為什么這些上下文的獨立性如此重要，為什么需要領(lǐng)域模型，以及這些概念與消息傳遞、Apache Kafka 和事件的使用有什么關(guān)系。

在當(dāng)今眾多工具的幫助下，微服務(wù)架構(gòu)得以使用事件流平臺將各個微服務(wù)分離開來，并從中獲益匪淺。實現(xiàn)可以是請求驅(qū)動的，可以是簡單的事件驅(qū)動系統(tǒng)，也可以是整個事件流業(yè)務(wù)應(yīng)用。它們還可以是這些概念的某種混合產(chǎn)物。DDD 提供了一套管理各個部分之間相互作用的基本技術(shù)，包括通用語言、有界上下文，schema 和反腐層等。如你所見，事件和消息傳遞是讓這些系統(tǒng)在實踐中良好運行的關(guān)鍵因素。