在第一部分中，我分享了在Nordstrom一直在探索和實施事件溯源作為一種架構模式。在第二部分中，我們將分享一些我們見過的常見生產者模式。

你可以把事件生產者看成業務的決策者：他們做出決定 有關或在觀察活動的業務，並通知有關剛剛發生了什麼事件流。一些事件生成者也會首先使用其他事件，做出決策，然後釋出這些決策：您可以在消費者中呼叫這些決定。事件源系統僅與所生成事件的質量和生產者的可靠性一樣好，因此可以很好地與系統其餘部分分離。

在Nordstrom，我們的活動是Avro -serialized，它提供壓縮，文件，標準化以及跨架構修訂的一些前向和後向相容性。每個事件共享一個公共標題，並符合事件標準。這些事件將寫入共享的多租戶Kafka群集，並且事件架構將使用中央架構登錄檔進行註冊。在我們的標準中，事件是過去發生的事情的通知 - 而不是將來採取行動的命令。例如，“add to cart”不是事件; “added to cart”才是。

九個事件生產者架構模式

在現有系統中，我們可以找到許多可以生成事件的地方，還有很多可供選擇的機制。以下是我們在Nordstrom看到並實施的一些常見模式。希望這些例子激發團隊的討論和創新！

1. 在事件發生時刻生成者立即釋出到分類賬

在綠地項（新專案）目中，您將事件溯源用作一流的架構模式，這可能是正確的模式。在您的系統中，在觀察或決定事件狀態時，會在事件流中生成事件物件。在某些系統中，單個元件（如無伺服器函式）可能只是一個事件生成器，該事件的結果由一個或多個單獨的事件使用者在其他地方處理。這種方法的好處是生產者團隊可以專注於可靠地生成具有強保證的事件，而不是實現其他邏輯。在這種模式中，即使在各種條件下，也應盡一切努力確保事件流的事件至少保證一次。

2.轉換現有遺留系統的流

您可能擁有質量較低的現有的遺留流 ： 可能包含許多特定於實現的技術上下文，重複資料或命令語法。源流也可以是非永續性佇列，或者具有較差的扇出或背壓問題，或任何其他數量的問題。使用各種流處理方法之一，您可以將此原始“遺留”流轉換為高質量的分類帳源。

3.Write-through直寫資料庫並使用更改資料捕獲

對於想要處理事務集或具有強read-after-write要求的現有系統，這種直寫生成器模式可能是一種非常實用的方法。在這些系統中，通過從資料庫中消費變更資料捕獲流，然後轉換為流上的事件來檢測與資料庫的互動。一些雲提供商擁有專門為此模式設計的資料庫解決方案，例如具有可以訂閱無伺服器函式的流的NoSQL資料庫。當您選擇資料庫時，擁有實時，低延遲的更改流甚至可能是決定性因素。例如，在撰寫本文時，Google Cloud Spanner具有一些真正令人難以置信的功能，但不支援有序事件的流出口的良好解決方案。

該模式還可以用作噪聲，部分和/或劣質事件的濾波器或電容器。單個噪聲事件會將新行建立或更新現有行，可能使用條件寫入來刪除重複項（冪等性）。然後可以讀取表的更改流，如果完成，則轉換為高質量事件併發布到事件流上。

4.輪詢現有的請求/響應服務以進行更改併發布

支援許多現有的同步請求/響應服務，獲取它們最近的更改。將其轉換為事件流的一種簡單方法是使用不斷輪詢的生產者。輪詢系統可能還需要做額外的工作來序列化和模式化資料。根據我們的經驗，測試這些服務API的資料的陳舊性和完整性非常重要，尤其是在評估第三方服務提供商的全新API時。有些系統在幕後使用批處理或縮放系統，這會給資料帶來不可接受的陳舊性。一個簡單的綜合測試套件應該能夠在各種條件下輕鬆測量這些問題。

5.訂閱Web套接字或pub / sub

許多系統都有支援訂閱更改的釋出/訂閱訊息匯流排或WebSocket。由於許多釋出/訂閱系統不提供永續性保證，因此必須注意在訂閱和轉換元件暫時不可用時如何恢復事件。這裡的一個解決方案是請求源系統通過釋出/訂閱層重新驅動資料。

6.流式化批量資料

在相對近期的實時資料流作為第一個事實來源的趨勢之前，許多系統依賴於定期批量交付的批量資料。在事件源系統中，這些批次可以在收到後立即轉換為事件流。但是，如果批次順序不合理，應注意儘可能嘗試進行資料的排序。

這種模式的一個好處是，通過可擴充套件的消費者系統，以及像Kafka或Kinesis這樣的流傳輸提供的自然解耦，每小時或每天發生大量事件通常都是完美的。此外，這為生產者系統提供了隨著時間的推移而不改變消費者的機會，可能轉向10或15分鐘批次，甚至轉向相對實時的流作為其下一個重構目標。

7.在無伺服器生態系統中使用事件觸發器

無伺服器計算產品依賴於整個雲提供商的事件觸發器生態系統。當發生任何各種事件時，會自動呼叫無伺服器函式，例如在儲存桶中建立的物件，或釋出到Pub Sub的訊息。可以利用此無伺服器事件觸發器生態系統，以便在每次世界上發生某些事件時將事件釋出到流。在許多情況下，呼叫無伺服器事件生成器函式，接收有效負載，對其進行轉換，並將其釋出到事件流。

8.監視react / redux中有價值的事件動作

在與不同背景的不同工程師交談時，事件源架構的想法可能完全是外來的不合適，或完全適合。在那些與我交談過的人中，最熟悉這個想法的是熟悉React-Redux等框架的前端工程師。在這些前端系統中，操作在發生時釋出（按鈕單擊，影象滑動），頁面上的各種元件消耗並以不同方式響應這些操作。

利用瀏覽器中的這些型別的前端操作/事件生態系統，我們可以在頁面或客戶端應用程式上建立元件，負責監聽特定操作以及建立和廣播格式正確的事件。無論事件是在客戶端上序列化為最終格式還是以某種通用格式傳遞到雲，都是一個重要的決定。

9.偶爾離線客戶端的複製表

在僅偶爾連線事件生成器的情況下，能夠首先可靠地將事件寫入到稍後與雲同步的本地儲存可能是一個很好的選擇。這些情況的示例包括物聯網裝置，行動電話或不可靠網路環境中的客戶端，或者在具有不完整WiFi覆蓋的環境中移動的裝置。

這種模式存在許多不同的選擇。在撰寫本文時，我們正在探索概念驗證專案中的幾個。這是一種令人興奮的模式，它可以提供卓越的資料保真度保證，並且在具有挑戰性的環