作者 | 蘇曉風(fēng)

我們經(jīng)常看到隨著Event Sourcing一起出現(xiàn)的，還有幾個(gè)大家比較熟知的概念：CQRS， EDA(Event-driven Architecture)，當(dāng)然還有DDD。在經(jīng)歷過(guò)采用Event Sourcing的項(xiàng)目后，我想和大家討論一下，當(dāng)我們提到Event Sourcing時(shí)，我們?cè)谡f(shuō)什么？再簡(jiǎn)單闡述一下這四個(gè)概念之間的關(guān)系。

Event Sourcing的概念

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

• 不是保留當(dāng)前狀態(tài)，而是保留所有導(dǎo)致?tīng)顟B(tài)改變的事件
• 事件會(huì)按發(fā)生的時(shí)間順序被記錄下來(lái)
• 通過(guò)事件重建得到狀態(tài)

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

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

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

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

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

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

為了回答這個(gè)問(wèn)題我們先來(lái)看看Event Sourcing中的核心概念：

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

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

使用Event Sourcing的好處

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

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

從它能帶來(lái)的優(yōu)點(diǎn)來(lái)看，當(dāng)我們的業(yè)務(wù)需求有：

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

當(dāng)然決定用它之前我們還是得考慮一下它的缺點(diǎn)：

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

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

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

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

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

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