事件流在當今世界變得越來越普遍。事件是一條數(shù)據(jù)，它以時間快照的形式描述了您的業(yè)務(wù)中發(fā)生的重要事件。我們將該數(shù)據(jù)記錄到事件流(通常使用 Apache Kafka 主題)，這為其他應(yīng)用程序和業(yè)務(wù)流程做出相應(yīng)的響應(yīng)和反應(yīng)提供了基礎(chǔ)——也稱為事件驅(qū)動架構(gòu) (EDA)。

事件驅(qū)動架構(gòu) (EDA) 廣泛依賴于事件。為了在 EDA 方面取得成功，您需要知道如何正確設(shè)計您的活動，因為這不僅會顯著影響您今天可以做的事情，還會影響明天的事情。

設(shè)計活動可能具有挑戰(zhàn)性，特別是在考慮消費者的不同需求、數(shù)據(jù)格式和延遲要求時。在這篇文章中，我們將討論構(gòu)建事件時的主要考慮因素之一：圍繞狀態(tài)進行設(shè)計與圍繞更改進行設(shè)計。

但首先，讓我們看一下事件流的基礎(chǔ)知識。

什么是事件?

事件代表在特定時間點發(fā)生的事件。

事件確實可以代表任何事物，但它幾乎總是代表對業(yè)務(wù)重要的事物。例如，電子商務(wù)企業(yè)可能會記錄有關(guān)銷售、訂單、客戶、交貨和庫存的事件。航空公司可以記錄有關(guān)付款、航班、飛行員、航線、機場和航班遙測的事件。

事件流的基礎(chǔ)知識

事件流(有時也稱為數(shù)據(jù)流)是一系列事件，發(fā)布到不可變的僅附加日志代理(例如Apache Kafka)。生產(chǎn)者系統(tǒng)將事件寫入流(Kafka 主題)，該流由一個或多個消費者系統(tǒng)消費。一旦記錄了事件，它們就會被寫入事件流中。

· 事件和事件流都是完全不可變的——一旦發(fā)布，您就無法更改它們的內(nèi)容，也無法更改它們在流中的順序。就像生活一樣，你無法改變過去:)。

· 多個消費者可以根據(jù)自己的選擇使用該事件。

· 事件是持久且可重玩的。與傳統(tǒng)的排隊系統(tǒng)不同，寫入主題的事件仍然可以根據(jù)您選擇的次數(shù)進行處理和使用。

流中的事件日志可用于構(gòu)建系統(tǒng)隨時間變化的詳細情況，而不僅僅是當前的快照。

設(shè)計活動時需要考慮幾個因素。目標消費者是誰?事件是在單個系統(tǒng)內(nèi)生成以供同一系統(tǒng)內(nèi)部使用嗎?還是與外部消費者共享，例如其他系統(tǒng)、團隊和人員?

事件設(shè)計中最大的問題之一是決定哪些數(shù)據(jù)應(yīng)該出現(xiàn)在事件中，哪些數(shù)據(jù)不應(yīng)該出現(xiàn)。解決這個問題需要采用與確定服務(wù)邊界和 API 組成相同的思維方法。我們將什么封裝在服務(wù)內(nèi)部，以及我們愿意向更廣闊的世界公開什么?

讓我們更深入地了解一下。

內(nèi)部數(shù)據(jù)與外部數(shù)據(jù)

所有(或至少絕大多數(shù))服務(wù)都包含數(shù)據(jù)——已提供、創(chuàng)建、計算、處理或計算的數(shù)據(jù)。其中一些數(shù)據(jù)是私有的，一些是公共的，一些表示作為業(yè)務(wù)流程一部分的中間表單，一些表示需要與其他系統(tǒng)共享的數(shù)據(jù)。

無論如何，您可以將服務(wù)的數(shù)據(jù)需求分為兩個陣營：

· 內(nèi)部數(shù)據(jù)由應(yīng)用程序或服務(wù)內(nèi)部的數(shù)據(jù)模型和數(shù)據(jù)結(jié)構(gòu)組成。此數(shù)據(jù)是您的系統(tǒng)私有的。但它還包括您可能想要在邊界之外共享的數(shù)據(jù)。

· 外部的數(shù)據(jù)是我們與其他系統(tǒng)共享的數(shù)據(jù)。它是為其他團隊、系統(tǒng)和人員的發(fā)現(xiàn)、消費和使用而明確建模的。

內(nèi)部數(shù)據(jù)的兩個示例：數(shù)據(jù)庫支持的系統(tǒng)和事件源系統(tǒng)

服務(wù)可以將其數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫、鍵值存儲、文檔數(shù)據(jù)庫中，甚至存儲在一組事件流中(例如在事件溯源系統(tǒng)中)。內(nèi)部數(shù)據(jù)是私有的，專門供系統(tǒng)內(nèi)部使用。它是根據(jù)其服務(wù)的需求進行建模的。它不適合其他系統(tǒng)和團隊使用，也不向更廣闊的世界開放。它保持封裝并與服務(wù)內(nèi)部工作的需求緊密耦合。

內(nèi)部(內(nèi)部數(shù)據(jù))和外部(外部數(shù)據(jù))世界的高級視圖

相反，外部的數(shù)據(jù)是我們與其他系統(tǒng)共享的數(shù)據(jù)。它是為其他團隊、系統(tǒng)和人員的發(fā)現(xiàn)、消費和使用而明確建模的。創(chuàng)建外部模型需要與下游消費者進行協(xié)商，還需要考慮狀態(tài)、變更、非規(guī)范化、安全性、性能和成本——當我們研究事件設(shè)計的四個主要因素時，我們將涵蓋所有內(nèi)容。

內(nèi)部/外部數(shù)據(jù)是思考數(shù)據(jù)用途以及誰應(yīng)該能夠訪問和使用數(shù)據(jù)的有用方法。正如我們必須考慮通過 REST API 向其他服務(wù)公開哪些數(shù)據(jù)一樣，我們還必須考慮使用事件向其他服務(wù)公開哪些數(shù)據(jù)。

還有一個與 REST API 類似的地方值得探索。當您成功發(fā)出 REST 請求(例如 GET)時，您將收到包含鍵和值的數(shù)據(jù)負載。然后，您必須解析該數(shù)據(jù)以獲得對您的服務(wù)的意義。但我們并不期望每個使用 REST API 的人或服務(wù)都能自己弄清楚這些數(shù)據(jù)的含義。不，我們(通常)為他們提供文檔和他們應(yīng)該期望的數(shù)據(jù)的模式，以便他們可以輕松使用它 - 事件也不例外。

模式對于創(chuàng)建可重用、可發(fā)現(xiàn)且無錯誤的事件流至關(guān)重要。它們提供基礎(chǔ)和結(jié)構(gòu)，并賦予事件隨時間演變和變化的能力。讓我們更深入地了解一下。