為什麼要從 CRUD 轉向事件源架構？

如果對各種架構風格都有個透徹的理解，設計者就能夠構建新型的、反應性的、有彈性的大型應用。因此，遵循這些經過行業檢驗的標準可以節省時間、保證可靠性，並推動目標實現。畢竟，企業有什麼理由要花時間和資源來重新發明輪子？

但僅僅瞭解不同的架構，如基於 CRUD 的架構、 基於微服務的架構 和基於事件源的架構，並不足以做出全面的決策。我們需要深入瞭解細節，並理解它們各自的特性、適用性和所提供的價值。在這篇文章中，我們將看一下 CRUD 和事件源架構，思考為什麼應該考慮從前者遷移到後者。

什麼是 CRUD？

CRUD 是建立、讀取、更新和刪除的縮寫。它構成了資料庫的四個命令，四個不言自明的命令，這些命令被認為是永續性儲存管理的必備要素。這種模式被各行各業的企業廣泛用於跟蹤客戶資料、員工資訊、支付記錄、賬戶等。

讓我們快速說明一下 CRUD 的常規事件流。Gary 正在瀏覽一個電子商務網站。他把一個遊戲機、一個控制器和一個遊戲新增到購物車中。此時，購物車的資料庫看起來大概是這樣：

Customer	Product	Quantity
Gary	Sony PlayStation 5	1
Gary	Sony DualSense Wireless Controller	1
Gary	Assassin's Creed Valhalla	1

假如我們新增另外一個物品（如耳機），則資料庫會變成下面這樣：

Customer	Product	Quantity
Gary	Sony PlayStation 5	1
Gary	Sony DualSense Wireless Controller	1
Gary	Assassin's Creed Valhalla	1
Gary	Sony PULSE 3D wireless headset	1

如果 Gary 刪除了耳機，則表就會變回之前的樣子。此外，如果他另外新增一個控制器，則資料庫會變成下面這樣：

Customer	Product	Quantity
Gary	Sony PlayStation 5	1
Gary	Sony DualSense Wireless Controller	2
Gary	Assassin's Creed Valhalla	1
Gary	Sony PULSE 3D wireless headset	1

本質上，資料庫遵循建立-讀取-更新-刪除的方法來維護表。“更新”和 “刪除”功能是 CRUD 的特點。

CRUD 方法的侷限性

雖然 CRUD 方法由於其操作的輕量化和簡單性而備受青睞，但它也有自己的一系列侷限，這包括：

• 對於 CRUD，最常見的批評是原始、過時。與其說它是一種架構或設計，不如說它是一個可供遵循的迴圈步驟，不管是構建一個數據庫還是一個 API 。

• CRUD 依賴於資料庫中狀態的永續性。然而，考慮到當前資料操作事件的動態性，這種資訊的儲存可能是浪費和資源密集型的。

• 儘管 CRUD 架構很簡單，但在開始階段，它需要人們花費大量的精力編寫大量的程式碼。儘管如此，當涉及到雲負載均衡時，CRUD 卻無法勝任。

• 雖然 CRUD 程式碼開始時可能很簡單，但當它開始與其他服務或微服務共享資料時，就會出現與狀態同步和故障處理有關的問題。

• CRUD 架構所涉及的複雜性將需要同樣複雜的解決方案，這可能會延伸到故障跟蹤、手動狀態記錄、非同步批處理等。這方面的考慮在編碼和整合上都會比較艱難。

• 在 CRUD 模型中，實體例項通常是雙重表示，一是記憶體中的可變物件，二是關係資料庫表中的一個可變行。這樣的結構導致了臭名昭著的物件-關係阻抗不匹配。試圖彌合這種鴻溝的努力卻進一步增加了這一架構的複雜性。

什麼是事件源架構？

事件源是一種資料儲存技術，被認為是 CRUD 的升級版。它只關注建立和讀取功能，而完全省略了 CRUD 中更新和刪除值的操作。更簡單地說，你不能通過事件源執行破壞性的操作。

那麼，它是如何克服 CRUD 面臨的挑戰的？

這裡有個有趣的地方：與 CRUD 遵循的傳統方法不同，事件源將變化逐個記錄下來，作為當前狀態隨時間變化的一系列增量，而不是持久化當前狀態本身。通過這種方式，事件源賦予了狀態變化可追溯性。在大多數情況下，這種設計通常與領域驅動設計（DDD）和命令查詢責任分離（CQRS）設計模式相結合。

為了更好地理解事件源架構，讓我們以 Gary 的銀行賬戶為例。假設 Gary 的賬戶裡有 2400 美元。他用 499 美元購買了 PS5 遊戲機。電子商務網站為他提供了 49 美元的返現。在這種情況下，事件源表會是這樣的：

Event	Value	Remark
1	2400	(balance)
2	-499	(debit)
3	+49	(credit)

通過追蹤一段時間內的取款和存款，可以計算出他目前的賬戶餘額為 1950 美元。這種狀態的復原和事件的回放被稱為重放。

我們可以把事件源視為客戶活動的日誌。

如果我們從電子商務平臺的角度來看 Gary 的活動，新增遊戲機是第一個事件，新增控制器是第二個事件，以此類推。事實上，結賬過程也是一個獨立的事件。如果 Gary 不小心在購物車中添加了三個控制器（例如，事件 1、2 和 3），然後他又刪除了一個，那麼刪除也是一個獨立的事件：事件 4！

採用事件源架構的好處

從對事件源的基本理解來看，它似乎是一個更好更完善的替代方案，克服了 CRUD 的缺點。為了進一步說明這一點，讓我們看一下事件源已被證明了的優勢。

• 事件源遵循事件驅動的架構，方便在狀態變化時可靠地釋出事件。

• 它通過持久化事件而不是領域物件，克服了 CRUD 中出現的物件-關係阻抗不匹配問題。

• 它維護了一系列事件的記錄，可以在只限追加的狀態下進行操作。通過消除狀態跟蹤和實體關係的需求，編寫讀寫資料庫的事件原始碼更容易。

• 由於保留了實體如何到達當前事件的日誌，所以事件源保證了審計資料和交易資料的一致性，因為它們是一樣的。此外，它也是一個很好的故障保險，因為資料可以從事件日誌中重建。

• 所有的事件只是被追加到現有的資料庫中，並且更新和刪除功能已被去掉，事件源架構只關注寫入，這提高了其效能。

• 事件源允許對事件流進行分析，這有助於企業從中獲取關鍵資訊。他們可以獲得所有系統活動的頂層檢視，而不會使寫入功能複雜化。

• 遵循事件源模型的架構更容易測試和除錯，因為在引入命令和事件之前，可以對其進行模擬測試。此外，事件日誌還可以作為一個很好的除錯活動記錄，如果發現問題，可以在受控環境中重放事件日誌，以瞭解導致異常的原因。

• 它可以儲存任何型別的資訊，任何消費者只要獲得授權，就可以訪問這些資訊。它允許通過時間查詢實體在任何時候的狀態。因此，它非常靈活。

• 與單體架構相比，事件源應用程式更容易遷移，因為它們遵循基於微服務的架構。之所以如此，是因為參與事件交換的業務實體之間是松耦合的。

結語

隨著越來越多的應用程式需要以有序和非同步的方式傳遞實時資料，企業對事件源的需求也越來越大。此外，它也是在網路規模上消費和管理應用程式日誌資料的絕佳方法。在這種情況下，事件源成了一個唯一的事實來源，提高了應用程式的可靠性。

那麼，你所在的企業打算何時從 CRUD 遷移到事件源架構？

原文連結：

Why Do You Need to Move From CRUD to Event Sourcing Architecture?