作者 | 蘇曉風

我們經(jīng)?？吹诫S著Event Sourcing一起出現(xiàn)的，還有幾個大家比較熟知的概念：CQRS， EDA(Event-driven Architecture)，當然還有DDD。在經(jīng)歷過采用Event Sourcing的項目后，我想和大家討論一下，當我們提到Event Sourcing時，我們在說什么？再簡單闡述一下這四個概念之間的關(guān)系。

Event Sourcing的概念

提到Event Sourcing，我們會聯(lián)想到一個非常相近的生活中的例子就是會計賬本，會計賬簿上的會計條目按照發(fā)生的時間順序，記錄了對賬戶余額產(chǎn)生變更的事件。通過會計賬簿的記錄，我們可以計算出任意時間點的賬戶余額。如果說有一類應(yīng)用程序需要留存對最終結(jié)果造成改變的所有事件，那Event Sourcing就像是這類應(yīng)用程序的概念抽象。所以我們看到Event Sourcing也有著和會計賬簿一樣的特征:

• 不是保留當前狀態(tài)，而是保留所有導(dǎo)致狀態(tài)改變的事件
• 事件會按發(fā)生的時間順序被記錄下來
• 通過事件重建得到狀態(tài)

聽起來Event Sourcing的概念也沒有那么難理解，更加貼合現(xiàn)實，還保存了所有真實事件，如果有審計相關(guān)的需求，顯然是很容易得到審計需要的數(shù)據(jù)。

Event Sourcing在Node.js里并不是一個被廣泛使用的成熟設(shè)計，我們很難在市面上找到成熟的Node.js的Event Sourcing框架，這意味這我們可能會面臨更多的未預(yù)知的問題。除了未預(yù)知的問題之外，開發(fā)團隊還面臨著巨大的思維轉(zhuǎn)變：系統(tǒng)中的一等公民變成了事件，所有的邏輯都是圍繞著事件展開，系統(tǒng)狀態(tài)不再是一個一定需要被持久化的元素了。這聽起來很簡單但是實踐起來卻并非只言兩語可概括般的容易。

在什么情況下需要用到Event Sourcing？

我了解到有的項目有基于命令轉(zhuǎn)化為事件，并將事件持久化到數(shù)據(jù)庫，但是在此同時他們也把command轉(zhuǎn)化為snapshot保存了下來。讀模型的構(gòu)建全部基于snapshot。該團隊確實將系統(tǒng)發(fā)生的真實事件全部留存了下來，但實際并沒有通過事件重建得到狀態(tài)，所有的狀態(tài)都是來自于另外處理得到的snapshot。嚴格上來說并不能算做是使用了Event Sourcing，系統(tǒng)中做到了留存Event，但是并沒有用到Sourcing。

基于一些背景信息，當時該項目使用Event Sourcing的出發(fā)點在于，客戶強烈要求將DDD的思想和產(chǎn)出的模型完全代碼化，特別是在Event Storming過程中的產(chǎn)出。

上面的例子不禁讓我們思考一個問題：究竟在什么情況下需要用到Event Soucing？

為了回答這個問題我們先來看看Event Sourcing中的核心概念：

• Event：發(fā)生的事實，也是唯一真實的數(shù)據(jù)來源。用過去式來表述。系統(tǒng)中的事件是immutable的，不能被更改和刪除，只能通過添加新的事件來改變當前的系統(tǒng)狀態(tài)。
• 完全重建（Rebuild）：我們可以完全丟棄系統(tǒng)狀態(tài)，在任何時間通過事件日志按照時間順序重演出當前系統(tǒng)狀態(tài)。
• 事件回放（Replay）： 就像平時瀏覽視頻一樣，如果視頻總時長是半小時，我們想回到25分，我們可以直接把進度條向后拉到25分。在Event Soucring的系統(tǒng)里，我們可以基于某個重建出來的系統(tǒng)狀態(tài)，回放后續(xù)的事件，得到我們想要的某個時間節(jié)點的系統(tǒng)狀態(tài)。

又比如： 我們的會計賬簿里保存了過去一年全部的會計條目，現(xiàn)在想要得到5月30號當天的賬戶余額，在此前因為業(yè)務(wù)要求我們已經(jīng)得到了每個季度結(jié)束的賬戶余額。那我們可以通過已知的5月31號的賬戶余額對5月31號發(fā)生的所有存款和取款進行反向的重放得到5月30號的余額。

使用Event Sourcing的好處

基于Event Sourcing的特性，我們可以來探討下它究竟能給我們的系統(tǒng)或者說業(yè)務(wù)帶來怎樣的好處？

• 審計追蹤：首先它留存所有真實事件的設(shè)計天然地為后期審計追蹤提供了便利，因為系統(tǒng)里留存下了所有現(xiàn)實中產(chǎn)生的痕跡，并且這些痕跡都不被允許修改;
• 適應(yīng)多樣的查詢需求：我們的系統(tǒng)狀態(tài)都是來自于事件，那意味著我們可以根據(jù)不同的查詢需求構(gòu)建出不同的讀模型，以適應(yīng)業(yè)務(wù)需求。這也是為什么我們看到Event Sourcing會經(jīng)常伴隨CQRS出現(xiàn)的一個原因。因為在Event Sourcing的系統(tǒng)里我們可以利用其特性，分離讀寫模型;
• 調(diào)試：這個優(yōu)點的來源同樣是保存了所有的事件，這意味著當我們線上環(huán)境出問題時，我們可以把線上環(huán)境的所有event拿到一個類線上環(huán)境下測試, 找到問題出在哪兒;
• 可以得到系統(tǒng)任何時間點的狀態(tài);
• 系統(tǒng)狀態(tài)可以是內(nèi)存內(nèi)的，不一定要持久化到數(shù)據(jù)庫：任何事情發(fā)生時，就像服務(wù)崩潰的時候，我們都可以通過事件重建得到系統(tǒng)狀態(tài)。這樣你就不需要考慮持久化到數(shù)據(jù)庫會涉及到的各種Data Mapping的邏輯了;
• 領(lǐng)域事件是有價值的，存下產(chǎn)生的領(lǐng)域事件，不丟失所有的現(xiàn)實痕跡，為支撐后期業(yè)務(wù)擴展，提供商業(yè)數(shù)據(jù)分析的數(shù)據(jù)源。

從它能帶來的優(yōu)點來看，當我們的業(yè)務(wù)需求有：

• 能夠保留下所有的事件以適應(yīng)審計的需求；
• 客戶認為系統(tǒng)中發(fā)生的事實都是很有價值的，一定要保存下來，以便支撐后續(xù)業(yè)務(wù)擴張的商務(wù)分析；
• 需要經(jīng)常查詢不固定時間點的系統(tǒng)狀態(tài)；
• 多種多樣的基于不同維度的查詢需求時，不妨考慮一下Event Sourcing。

當然決定用它之前我們還是得考慮一下它的缺點：

• 事件的版本： 對于不同類型或者不同聚合根下的事件我們有著不一樣的Event Handler, 而當業(yè)務(wù)演進的過程中，相應(yīng)地對事件的處理也會不同。這意味著我們在業(yè)務(wù)擴展的時候需要考慮兼容舊的事件;
• 業(yè)務(wù)發(fā)生改變后，為適應(yīng)業(yè)務(wù)需求我們需要replay出的application state也會可能發(fā)生改變，那我們要如何兼容舊的事件rebuild或replay出新結(jié)構(gòu)的application state?
• 讓開發(fā)團隊感到陌生的設(shè)計思想;
• 較少成熟的Event Sourcing的框架支持;
• 在Event store中需要序列化Event。

Event Sourcing和其他架構(gòu)之間的關(guān)系

回到文章開頭提到的四個經(jīng)常被拿來一起說的概念：當我們決定使用Event Sourcing作為架構(gòu)選擇之時，通常我們也會選擇DDD去構(gòu)建得到領(lǐng)域事件。DDD里提到的Event指的是對系統(tǒng)狀態(tài)產(chǎn)生改變的現(xiàn)實事件，同樣我們在Event Sourcing的系統(tǒng)中存儲的也是會導(dǎo)致系統(tǒng)狀態(tài)改變的事件。似乎這兩種不同的軟件開發(fā)思想，對Event的認識有著不謀而合的默契。

用到Event Sourcing的系統(tǒng)又絕大部分都會采用CQRS。因為我們持久化的event和查詢所需的結(jié)構(gòu)很顯然是有區(qū)別的，與其每次查詢都通過Rebuild或者Replay去得到查詢所需的狀態(tài)，我們一般都會根據(jù)查詢需求構(gòu)建出查詢需要且方便的讀模型。即便如此，當我們決定選用CQRS時，還是得考慮引入后會增加的的復(fù)雜度。這也意味著不是所有的Event Sourcing的系統(tǒng)都需要采用CQRS。

至于EDA那其實是完全沒有太大關(guān)系的概念了，不過我們經(jīng)常在處理服務(wù)之間通信的問題的時候會用到。當我們的項目恰好是微服務(wù)，又采用了DDD，還加上Event Sourcing和CQRS那我們還需要引入EDA的時候，就要小心我們平時的技術(shù)討論中一定要分清楚我們所說的Event是在怎樣的上下文下的。想要更多的了解EDA的概念可以參看Martin Fowler“當提到“事件驅(qū)動”時，我們在說什么？”的文章，其中也提到了我們經(jīng)常會混用Event Sourcing，EDA，CQRS中的一些概念。

希望這篇文章能夠引發(fā)你對Event Sourcing的設(shè)計思想的一些思考。也期望后續(xù)我還能再完成一篇Event Sourcing實戰(zhàn)的文章。這篇文章其實還是有些遺漏的地方，比如在Event Sourcing架構(gòu)選擇決策的缺點部分，但是考慮到實際選用Event Sourcing架構(gòu)的情況下通常還會選用其他的設(shè)計以及架構(gòu)，比如文中反復(fù)提到的CQRS和DDD，在最終決定的架構(gòu)下也會引入除了本文所提的缺點之外的其他問題，但因為我認為這并不算是Event Sourcing架構(gòu)本身帶來的問題故沒有在文中深究。但是如果大家真的決定選用Event Sourcing作為系統(tǒng)設(shè)計思想的一部分的話還是需要對Event Sourcing的應(yīng)用做更多的探索，本文還是旨在闡明Event Sourcing的概念，消除大家對于Event Sourcing的部分誤解。