模式和數據契約

模式對于定義事件至關重要。模式提供了有關事件中應該出現什么和不應該出現什么的所有信息，包括名稱、類型、可選性和內聯文檔，僅舉幾個功能。流行的模式技術包括Avro、Protobuf和JSON Schema。

如果您嘗試在沒有模式的情況下流式傳輸數據，那么您就做錯了。但如果您只想要簡短的形式，這里是：

1. 使用模式：模式可以防止生產者在寫入數據時犯錯誤，因為您可以直接從模式本身生成生產者代碼。同樣，消費者不再需要解釋數據 - 只需按照模式上的方式讀取數據，并相應地使用它。模式還提供演化功能，您可以根據不斷變化的業(yè)務需求安全地(在某種程度上)修改模式。

1. 構建數據契約：它們將事件的內容和流本身形式化。它類似于服務 API，不僅指定如何使用事件流，還指定如何訪問它、安全要求和所有權。

但現在我們已經確定我們正在使用一個模式……讓我們看看事件設計的第一個主要因素。

因素 1：狀態(tài)(事實)與增量(變化)

狀態(tài)事件(也稱為事實事件)詳細說明了特定時間點實體狀態(tài)的整個范圍。它包含履行公共數據合同所需的所有字段和值。您可以將狀態(tài)事件視為關系數據庫中的一行，其中所需字段由表的架構定義表示。

相反，增量事件記錄兩個狀態(tài)之間的變化。它包括有關哪些字段已更改及其新值的數據，但不包括有關未更改字段的信息。

我們來看一下購物車的例子：

狀態(tài)(事實)事件與item_added_to_cart增量事件

在左側，我們有代表購物車在某個時間點的狀態(tài)的狀態(tài)事件，盡管它本身并不能準確指示發(fā)生了什么變化。為此，您需要訪問之前的購物車信息。

右側的增量描述了完全相同的業(yè)務發(fā)生，特別是添加到購物車的 item:521 的 1 個實例。但是，它不會顯示購物車的當前狀態(tài) - 為此，您需要訪問之前的所有增量事件。

事實和增量各有其權衡：所以讓我們直接討論何時使用哪個。

事實事件對于溝通狀態(tài)來說是優(yōu)越的

事實為其消費者提供了預先計算的狀態(tài)，使他們無需計算任何狀態(tài)。他們只是簡單地消費事實并根據其業(yè)務邏輯處理狀態(tài)。

如果您嘗試與增量通信狀態(tài)，則必須從主題的最開始重新創(chuàng)建狀態(tài)。您還必須確保使用正確的業(yè)務邏輯來處理每個狀態(tài)更改。大多數域比簡單地在購物車中添加/刪除商品更復雜，并且嘗試在源系統(tǒng)外部重新計算狀態(tài)是非常危險的。相反，只依賴事實事件。

考慮計算的復雜性：

· 客戶公司銀行賬戶的賬戶余額

· 電子商務零售商的當前庫存

· 欠政府的稅款

雖然其中每一個都可以由關心它的每個消費者來計算，但設置和維護起來卻極其復雜。除了稍微減少網絡數據使用量之外，它沒有任何實際好處。簡而言之，最好使用事實事件來傳達狀態(tài)。

事實讓您推斷出三角洲

一對事實事件可讓您推斷自己的更改：您可以看到從第一個事件到第二個事件發(fā)生的所有更改。

推斷更改的一個選項：將最后一個事實保留在您的服務或作業(yè)的狀態(tài)存儲中。

您在服務或作業(yè)的狀態(tài)存儲中保留最后使用狀態(tài)的副本。請注意，您只需保留您關心的狀態(tài)，其余的都可以扔掉。您也可以選擇保留多個先前的狀態(tài)(例如，最近 3 個或最后 10 個狀態(tài)更新)，以便您可以隨著時間的推移推斷更復雜的更改。

作為權衡，您需要提供狀態(tài)存儲。您還需要編寫代碼來推斷狀態(tài)之間的任何變化，其復雜性將根據您的要求而有所不同。在某些情況下，邏輯只需要檢測邊緣過渡，如下圖所示，其中 adiscount_code應用于購物車。在其他情況下，狀態(tài)計算可能更復雜，需要來自多個事件或流的數據與內部狀態(tài)交叉引用。

推斷更改的第二個選項：使用事件中的before和after字段。

您可以在單個事件中提供兩種狀態(tài)。正如您可能已經猜到的，before 字段保存更改之前的狀態(tài)，而 after 字段保存更改后的狀態(tài)。它通常用作變更數據捕獲 (CDC) 服務的一部分，使您能夠查看兩個狀態(tài)之間的整個更新，并自行推斷單個事件中發(fā)生了什么變化。請注意，這會使活動規(guī)模增加一倍，并可能導致額外費用。

帶有前后小節(jié)的購物車事實

事實事件本質上比增量事件更大。如果數據非常大或者更新非常頻繁，那么維護成本可能會很高。