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

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

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

微服務

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

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

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

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

Apache Kafka——微服務的事件流平臺

應該使用哪些技術來構建微服務架構?這個問題可以分為兩部分來回答：

1. 微服務之間怎樣相互通信?

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

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

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

Apache Kafka 之所以能成為微服務事實上的標準，主要原因是它融合了三個強大的概念：

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

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

 

 

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

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

用于構建和解耦微服務的領域驅動設計方法(DDD)

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

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

團隊需要與領域專家交流，從而使用領域術語搭建領域模型
在領域代碼中嵌入領域術語
保護領域知識免受來自其他領域和技術子域的損害

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

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

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

 

 

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

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

Apache Kafka 和領域驅動的微服務

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

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

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

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

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

消費者可以以自己的節(jié)奏(批量或實時)處理數(shù)據(jù)。

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

有了這些特性，項目團隊就都能擁有自己的領域了;這些領域可以有不同的職責、SLA、版本控制和技術選擇。

 

 

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

領域模型、有界上下文和通用語言

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

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

反腐層有兩大職責：

它讓領域模型不受其他模型的更改影響

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

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

使用 Apache Kafka、Kafka Streams、KSQL 和 Kafka Connect 將各個領域連接起來

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

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

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

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

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

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

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

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

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

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

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

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

要從宏觀層面了解如何將 Connect、Kafka Streams 和微服務組合在一起，可以參閱 Yeva Byzek 的一篇寫得很棒的文章( https://www.confluent.io/blog/stream-processing-part-1-tutorial-developing-streaming-applications )。最后，構建微服務生態(tài)系統(tǒng)只是問題的第一部分。生態(tài)系統(tǒng)構建完成后，你需要對其檢測、控制和操作。具體內容可參閱這篇文章( https://www.confluent.io/blog/journey-to-event-driven-part-4-four-pillars-of-event-streaming-microservices )。

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

只需挑選最適合你的架構即可。例如，你可以讓每個 Kafka Connect 群集由負責它的領域團隊運營，或者把 Kafka Connect 托管為 Kafka 群集的一部分，并允許團隊為其部署連接器。

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

Apache Kafka+ 領域驅動設計(DDD)= 解耦事件流微服務

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

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

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

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

譯者：王強

來源：InfoQ

標簽： Kafka 

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