微服務(wù)與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)有著共生關(guān)系。所謂領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是一種設(shè)計(jì)方法，在這種方法中我們基于業(yè)務(wù)領(lǐng)域涉及的內(nèi)容用軟件精心搭建出一套模型，這套模型隨著時(shí)間的推移而逐漸發(fā)展，但并不受運(yùn)行系統(tǒng)的管道約束。我發(fā)現(xiàn)人們喜歡將這種模式與 Apache Kafka 結(jié)合起來，這種組合在實(shí)踐中也運(yùn)用得越來越多了。

在這類項(xiàng)目中，微服務(wù)架構(gòu)通常使用 Kafka 作為事件流平臺(tái);而領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)方法則用來定義各種有界上下文，這些上下文表示應(yīng)用需要執(zhí)行的各種業(yè)務(wù)流程。它們與各種事件結(jié)合在一起，創(chuàng)建了一個(gè)將各個(gè)有界上下文與下游出現(xiàn)的上下文分離的單向依賴圖，以創(chuàng)建豐富多樣的事件流業(yè)務(wù)應(yīng)用。

本文將探討為什么 Apache Kafka 會(huì)成為微服務(wù)架構(gòu)事實(shí)上的標(biāo)準(zhǔn)和主干——Kafka 不僅取代了其他傳統(tǒng)的中間件，而且人們還使用 DDD 和 Kafka 原生 API(如 Kafka Streams、KSQL 和 Kafka Connect)直接構(gòu)建微服務(wù)。

微服務(wù)

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

雖然微服務(wù)并不是什么免費(fèi)的午餐( http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html )，但它們確實(shí)提供了許多好處，解耦就是其中一項(xiàng)優(yōu)勢(shì)。解耦是圍繞業(yè)務(wù)功能來組織系統(tǒng)，以形成分散的體系結(jié)構(gòu)的過程。其中智能端點(diǎn)和啞管道(dumb pipe)會(huì)確保：

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

Martin Fowler( https://martinfowler.com/articles/microservices.html )

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

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

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

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

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

2. 如果你要使用中間件，該用哪個(gè)?

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

發(fā)布和訂閱事件流，類似于消息隊(duì)列或企業(yè)消息傳遞系統(tǒng)
以容錯(cuò)方式存儲(chǔ)事件流
在事件流發(fā)生時(shí)實(shí)時(shí)處理

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

 

 

為了更好地理解 Apache Kafka 相比傳統(tǒng)中間件(如 MQ、ETL 或 ESB 工具)的優(yōu)勢(shì)，請(qǐng)參閱”Apache Kafka vs 企業(yè)服務(wù)總線——朋友，敵人還是亦敵亦友?”( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ )

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

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

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

DDD 方法基于下列原則( https://techbeacon.com/app-dev-testing/get-your-feet-wet-domain-driven-design-3-guiding-principles )：

團(tuán)隊(duì)需要與領(lǐng)域?qū)＜医涣�，從而使用領(lǐng)域術(shù)語搭建領(lǐng)域模型
在領(lǐng)域代碼中嵌入領(lǐng)域術(shù)語
保護(hù)領(lǐng)域知識(shí)免受來自其他領(lǐng)域和技術(shù)子域的損害

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

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

一個(gè)事件流平臺(tái)可能看起來像這樣：

 

 

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

那么為什么 Kafka 就是事件流平臺(tái)的不二之選呢?

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

還有一個(gè)關(guān)鍵要點(diǎn)我們還沒討論過：Apache Kafka 不僅是一個(gè)消息系統(tǒng)或者一個(gè)集成層——它是一個(gè)事件流平臺(tái)。這意味著它不僅負(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)隊(duì)共存。ESB 模式有著很嚴(yán)重的問題，人們將越來越多的邏輯、編排和轉(zhuǎn)換推入集中管理的 ESB 中，不得不愈加依賴中心化的團(tuán)隊(duì)。我們指出這一現(xiàn)象就是想讓人們不要再推進(jìn)這種有缺陷的模式了。

“使用 Kafka 重建 ESB 反模式”( https://www.thoughtworks.com/radar/techniques/recreating-esb-antipatterns-with-kafka )

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

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

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

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

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

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

如何構(gòu)建這樣的系統(tǒng)

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

你還必須決定該如何管理狀態(tài)。可以使用 Kafka Connect 等技術(shù)在數(shù)據(jù)庫(kù)中管理，也可以使用 Kafka Streams API 在托管服務(wù)中管理。關(guān)于構(gòu)建有狀態(tài)事件流的微服務(wù)，可以參閱 Ben Stopford 的博客文章“使用 Kafka Streams 和 KSQL 構(gòu)建微服務(wù)生態(tài)系統(tǒng)”( https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/ )。

要從宏觀層面了解如何將 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)建完成后，你需要對(duì)其檢測(cè)、控制和操作。具體內(nèi)容可參閱這篇文章( https://www.confluent.io/blog/journey-to-event-driven-part-4-four-pillars-of-event-streaming-microservices )。

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

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

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

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

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

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

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

作者：Kai Waehner 在 Confluent 擔(dān)任技術(shù)傳播人。Kai 的主要專業(yè)領(lǐng)域包括大數(shù)據(jù)分析、機(jī)器學(xué)習(xí) / 深度學(xué)習(xí)、云 / 混合架構(gòu)、消息傳遞、集成、微服務(wù)、流處理、物聯(lián)網(wǎng)和區(qū)塊鏈等。他經(jīng)常在 JavaOne、O’Reilly Software Architecture 和 ApacheCon 等國(guó)際會(huì)議上發(fā)表演講，還為專業(yè)期刊撰寫文章。

譯者：王強(qiáng)

來源：InfoQ

標(biāo)簽： Kafka 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。