事件溯源（Event Sourcing）
事件溯源模式是一種軟體設計思路。這種設計思路通常與傳統的採用增刪查改（CRUD）為主的系統設計思路相區別。CRUD 應用通常存在一些局限性：
- 通常來說 CRUD 應用會採用直接操作數據存儲的做法。這樣的實現方式可能會由於對數據庫優化不足而導致性能瓶頸，並且這種做法會較難實現應用伸縮。
- 在特定的領域通常存在一些數據需要注意對併發問題進行處理，以防止數據更新的錯誤。這通常需要引入“lock”、“Transaction”等相關的技術來避免此類問題。但這樣又有可能引發性能上的損失。
- 除非增加額外的審計手段，否則通常來說數據的變更歷史是不可追蹤的。因為數據存儲中通常保存的是數據最終的狀態。
與 CRUD 做法對比，事件溯源則從設計上避免了上述描述的局限性。接下來圍繞上文中提到的“轉賬”業務場景簡述事件溯源的基礎工作方式。
採用 CRUD 的方法實現“轉賬”。
採用事件溯源的方式實現“轉賬”。
如上圖所示，通過事件溯源模式將轉賬業務涉及的余額變動採用事件的方式進行存儲。同樣也實現了業務本身，而這樣卻帶來了一些好處：
- 通過事件，可以還原出賬號任何階段的余額，這就一定程度實現了對賬號余額的跟蹤。
- 由於兩個賬號的事件是獨立處理的。因此，兩個賬號的處理速度不會相互影響。例如，賬號 B 的轉入可能由於需要額外的處理，稍有延遲，但賬號 A 仍然可以的轉出。
- 可以通過訂閱事件來做一些業務的異步處理。例如：更新數據庫中的統計數據，發送短信通知等其他的一些異步操作。
當然引入事件溯源模式之後也就引入了事件溯源相關的一些技術問題。例如：事件所消耗的存儲可能較為巨大；不得不應用最終一致性；事件具備不可變性，重構時可能較為困難等。相關的這些問題在一些文章中會有較為細緻的說明。讀者可以閱讀後續的延伸閱讀內容，進而進行了解與評估。
參考資料