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

作者 ｜ Savan Kharod

譯者 ｜ 平川

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

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

什麼是 CRUD？

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

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

假如我們添加另外一個物品（如耳機），則數據庫會變成下面這樣：

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

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

CRUD 方法的侷限性

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

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

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

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

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

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

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

什麼是事件源架構？

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

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

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

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

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

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

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

採用事件源架構的好處

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

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

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

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

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

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

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

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

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

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

結    語

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

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

原文鏈接：

https://dzone.com/articles/why-do-you-need-to-move-from-crud-to-event-sourcin?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDIxNDU1NzUsImciOiJLOEdoZGtjdlF2SHkzeDhwIiwiaWF0IjoxNjQyMTQ1Mjc1LCJ1c2VySWQiOjI0MzYwNzkwfQ.yHCE5wZnN1J6Gb4eKsvz-XrB82uZpWtFq3OmKmoHzbg

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/kI1HLB5k1JvC9EvEdQH4yQ