說服您的CTO使用事件溯源 -Event Store Blog

banq發表於2020-05-30
事件

事件溯源 是一個簡單但功能強大的概念，它允許將應用程式的狀態表示為事件序列，而不是當前狀態的快照。換句話說，可以隨時從表示已影響系統的每個更改的有序事實列表中推斷當前狀態。

1.免費稽核跟蹤
我們不僅透過應用所發生的每個事件來達到相同的結果，而且我們還記錄了對狀態產生影響的每個步驟，其中包括對開發人員和企業有用的資訊。隨著事件的溯源，我們能夠知道如何系統除了取得了一定的狀態什麼是狀態。
事件在發生時以有序的方式儲存在事件儲存或事件日誌中，並按與生成事件的原因相關的流進行邏輯分組。為了更好地探索和關聯這些事件，可以再次讀取它們以提取其資訊並將其投影為適合需要的形狀。
想象一下一個傳統的系統，它在應用程式崩潰的情況下發生了令人不快的情況，但是由於開發人員忘記新增一些跟蹤資訊，我們無法重現以前發生的情況。

2.更輕鬆的測試
自動化測試是必須的。當在程式碼中重構，維護或新增更多功能時，它為開發人員提供了安全性；它有助於整體上使軟體更加可靠；並且，它是有關當前系統功能的可靠且最新的文件。
為了測試功能性，我們採用了一種給定的 方法，即準備場景，執行功能並對結果進行斷言，以確保其達到了預期的目的，並且沒有達到預期的目的。
使用事件源時，這些方案變得更易於準備和更具可讀性，因為可以以自描述的方式從一組事件中構建系統的前提條件。請記住，系統中所有可能的變異都由一個事實表示。
此外，重播所有事件直到特定的時間點，將為我們提供與當時相同的系統狀態，從而使我們基本上可以按時旅行。

3.零資料丟失
誰敢說某些交易或資訊是無關緊要的？我們可能不會想到某些資料的當前用法，但這並不意味著以後這些資料將不再有價值。事件資料來源 具有零資料丟失的特性，因此對於企業而言可能是非常有價值的。
一些企業承認資訊是要收集和保護的最重要的事物之一，但是已經實施瞭解決方案，其中可變性可能意味著資料丟失。對於傳統的CRUD系統，每次執行寫操作以更新或刪除記錄時，都會丟失資料，除非可以恢復突變之前的先前狀態。但是，如前所述，如果無法從其日誌中重建系統的狀態，則無法保證實際發生的情況。

4.報告就像恢復到以前一樣
假設您是一家線上服裝店的軟體工程師，客戶可以在其中瀏覽文章，選擇尺寸和顏色，新增配件等。當使用者對購物籃中的內容感到滿意時，他們可以繼續結帳並輸入付款明細。相當熟悉的場景，不是嗎？
有一次會議討論更好的分析客戶行為的方法：營銷部門的一位成員建議，一個在結帳之前從購物車中刪除一些物品的顧客可能是這些物品潛在的客戶。
與會人員認為該想法很有潛力，因此決定在他們的網站上開始跟蹤這種情況，他們將建立一個包含這些情況的詳細資訊的報告，管理人員迫不及待地想看到報告中顯示的資料。但是該報告尚未顯示任何資訊，因為自新版本釋出以來尚未進行任何結帳。他們必須等待更長的時間才能看到第一個資料。
由於採用了事件溯源，您可以將此報告建立為新的閱讀模型，從頭開始重播所有事件以建立新的預測，然後重放完成的時間，可以檢視報告中的所有資料，而不必等待新的購買，就好像報告從第一天開始就一直在那兒一樣！


 

相關文章