Version: Next

事件溯源(Event Sourcing)

事件溯源模式係一種軟體設計嘅思路。呢種設計思路通常跟傳統用到以CRUD為主嘅系統設計思路有啲唔同。CRUD 系統通常存在一哋局限性:

  1. 通常黎講 CRUD 系統會採用直接操作數據存儲嘅做法。咁樣嘅實現方式可能會因為Database優化唔夠而發生性能瓶頸,並且呢種做法會較難實現應用伸縮。
  2. 喺特定嘅領域通常存在一哋數據併發嘅問題需要進行處理,防止數據更新引致嘅錯誤。通常我地會引入“Lock”、“Transaction”呢哋相關嘅技術嚟避免此類問題。但咁做又有可能引發性能上嘅損失。
  3. 除非增加額外的審計手段,否則通常來說數據的變更歷史是不可追蹤的。因為數據存儲中通常保存嘅係數據最終狀態。

跟 CRUD 做法對比,事件溯源則由設計上避免咗上述描述嘅局限性。跟住落黎圍繞上文中提到嘅“轉賬”業務場景簡述一下事件溯源嘅基礎工作方式。

採用 CRUD 嘅方法實現“轉賬”。

採用CRUD的方法實現“轉賬”

採用事件溯源嘅方式實現“轉賬”。

採用事件溯源的方法實現“轉賬”

如上圖所示,通過事件溯源模式將轉賬業務涉及嘅余額變動採用事件方式進行存儲。同樣亦實現咗業務本身,但係就帶嚟咗一哋好處:

  • 通過事件,可以還原出賬號任何階段嘅余額,咁就一定程度實現咗對賬號余額嘅跟蹤。
  • 由於兩個賬號事件是係獨立處理嘅。因此,兩個賬號嘅處理速度唔會相互影響。例如,賬號 B 嘅轉入可能由於需要額外處理,稍有延遲,但賬號 A 仍然可以繼續轉出。
  • 可以通過訂閱事件嚟做一哋業務的嘅異步處理。例如:更新數據庫入面嘅統計數據,發送SMS通知等其他一些異步嘅操作。

當然引入事件溯源模式之後也就引入了事件溯源相關嘅一些技術問題。例如:事件所消耗的存儲可能較為巨大;不得不應用最終一致性;事件具備不可變性,重構時可能較為困難等。相關的這些問題在一些文章中會有較為細緻的說明。讀者可以閱讀後續嘅延伸閱讀內容,更進一步了解及評估可行性。

參考資料