一、事前

你相信嗎？曾經有一段日子，我幾乎沒接到過合格的產品需求，

開局幾句話，技術全靠猜，

總是以為簡單的需求

曾經，我從產品那里接到過這么一個需求:

對系統的用戶進行分級，不同級別的用戶有不同的福利，

依然如常，無圖無檔案，只是這么一句話，我知道，需求一句話，分析五日功嘛，為了專案能持續發展，我只好自己分析自己搞了，

從業務上看，目前的用戶物件尚無等級一說，我們先為用戶物件加上個級別屬性，又因為不同的用戶等級，可享受到不同的福利，比如：達到 3 級的用戶，可以享受購物 9.5 折優惠，物流費用全免，客服快速回復等，

所以，我做出設計如下:

首先，我把每個等級用戶該享受的福利放到一個串列里，這個用來供前端展示用戶當前可享受到的福利，

然后，在每一項福利中，我去設定一個可享受此福利的最低級別，只有用戶的級別超過這個最低級別的時候，才可以享受到此項福利，比如，支付優惠 9.5 折，我只需要在支付服務中打包個支付權利 9.5 折這種東西，然后設定個最低級別即可，

這事兒看著是如此簡單，所以，實作方案也沒什么特殊的，當用戶每次升級的時候，我只需要更新用戶級別即可，

這個時候，需求比較初級，要求也不高，在滿足升級條件后，需要用戶主動點擊升級，同時，再填寫一些相關資訊，申請一些專屬的福利就可以了，

好，設計，開發，上線一條龍走起來！

需求變成坑

過了一陣子，我們的運營們勇于探索，勤于開拓，去搞了一堆資源互換回來，當我聽說此事時，心里已經預感不妙了，

果然，沒兩天，我們的產品高高興興地通知我，由于兄弟團隊愿意和我們的專案進行合作，因此用戶的福利將得到極大的豐富，那些更加豐富的福利全都由兄弟團隊提供，

所以，請我簡單的搞一下，對接上這些合作方，進一步提升我們系統的粘性，

如常，依然沒有任何檔案，我依然只能自己分析，

現在，根據我豐富的被折騰經驗，我知道開始有坑了，當我對接合作方介面的時候，他們都需要我傳入一些特定的用戶標識過去，可以讓雙方共享用戶，

需求開始復雜了，不過慶幸的是，我改改代碼就可以了，還好還好，我松了口氣……

好，設計，開發，上線一條龍走起！

可惜，我們的業務就像一群群的蜜蜂一樣，你永遠不知道他們會給你帶來什么樣的花朵，

沒過過久，產品告訴我，幾個兄弟團隊想和我們一起搞一次超級大活動，我覺得天黑了……

沒檔案沒有產品原型，依然就是微信中的來來往往，

我知道此時，我得往深里想想了，需求是可以肆意妄為的，而我能阻止業務需求的肆意妄為嗎？不能，所以，我要考慮一整套彈性的方案，能應對這些千變萬化，又漫天飛舞的需求，

二、初見

隱患的伊始

來看看這個見鬼的大活動吧，

首先，按照設計，如果合作方們想要和我們一起大聯歡，那么我們就要把用戶升級的資訊告訴他們，這樣，合作方們才能進行驗證，并提供用戶級別對應的福利，所以，當我們的用戶升級的時候，我需要每次都把這件事同步給我們的合作方，

又因為我們是和多個兄弟團隊合作，比如，和物流團隊合作，和支付團隊合作，在這種情況下，不同合作方的互動邏輯是分布在不同的服務中的，

此時，我有兩種方案可供選擇:

1.在用戶服務里，用戶升級時，立即主動的通過介面去呼叫分布在不同的服務上的相關邏輯，把用戶升級這件事同步到合作方那里，但是，這個方案有個很大的問題——因為我們需要呼叫其他服務的介面，這就造成服務和服務之間耦合起來了，將來有點小改動，可能都需要我們改代碼，

2.在微服務里，其實是很推崇使用訊息佇列的，當用戶升級時，我只需發送訊息到訊息佇列中，然后讓相關的服務去訂閱這個訊息即可，這個方案，使用訊息佇列可以解耦服務之間的關系，

因為微服務本身的目的就是解耦和靈活，并且第二個方案和我們架構是適配的，因此我選擇了第二個方案，

在第二個方案中，正因為訊息可以把服務之間進行解耦，所以，當用戶升級的時候，我只需要操作用戶服務資料庫中的用戶表進行升級，并把升級這事兒包裹成訊息扔到訊息佇列中即可，

我甚至可以把更新用戶表和發送升級訊息到佇列包裝成一個事務，

好，設計，開發，上線一條龍走起！

這就是能應對后續不斷變化的技術方案嗎？事實證明，并不能，因為，這套方案即將會被變化的需求給徹底擊垮，

問題的大爆發

斗轉星移，時空變幻，需求如滾滾的流水般涌來，而我們的技術方案如同一套無論如何增強也不夠健壯的大壩，

經過幾度需求的變換，此時用戶升級已經變成了滿足條件后自動升級；我們合作的兄弟團隊也日益增多；我們的服務也越拆越多……在這些汩汩涌出的變化中，問題已經如同潛伏在水底的鱷魚，即將爬上岸來獵取幾個程式員來祭天了，

問題的跡象一開始出現在用戶升級的資料上，那時，我們接連被運營們提的問題所困擾，

有些運營人員發現，某些用戶升級過快了，用戶的升級速度已經遠遠超出了當初設計時預估的速度了，

而這種過快的升級不僅使得運營人員無法及時構思和設計后續的運營活動，還使得我們的運營成本快速的上漲，并因此給公司經營帶來了一定的損失，

當然，如同以往一樣，業務是從來不會出錯的，出錯的永遠是技術，這不，出問題的原因都給我們安排的明明白白了：

很可能是程式出了 bug，因為出了某些技術性的故障，導致用戶升級的時候沒有一級級的升上去，出現了跳躍性的升級…………

在追蹤問題的時候，我們猛然發現了這個技術方案的一個缺陷：由于根本沒有預料到用戶升級的重要性，我們的很多用戶升級相關的日志并未開啟，并且沒有存盤任何用戶升級的歷史記錄，

這瞬間成了一筆糊涂賬，我無 fuck 可說，

雪上加霜的是，又有用戶們投訴，他們總是在某些時候會出現一些卡頓，我們再一查，發現是用戶升級導致的資料庫問題，

最早的設計是用戶升級直接更新資料庫表，但是大意了：

當用戶數量出現大漲的時候，
新用戶初期升級難度小，所以升級很頻繁，

忽略了這兩個因素，這就造成了我們的資料庫有點承受不住這種頻繁的更新，

而且，在查這些問題的時候，以前有些用戶投訴的問題也隨之被挖了出來，比如，用戶升級后有些福利卻沒有給他們，悲催的是這些痕跡也沒有被完整的留下來……

糊涂賬加糊涂賬成了筆爛賬，

啊，我要被祭天了嗎？

跺腳后智商重新占領高地

現在來看看我們要面臨的問題吧，

首先出場的是用戶升級沒法追根溯源的問題，因為我們每次用戶升級，需要通知相關的服務，然后還得保證每個相關的服務處理成功了，到此時，用戶升級才算真正的成功，所以，為了能還技術們一個清白，能別搞得成為爛賬，就必須把用戶的每次升級給記錄下來，并且還得把每個相關服務對升級事件的處理也記錄在案，

下一個要解決的小兄弟是資料庫更新的問題，這個資料庫更新該怎么辦？快取后同步？那快取本身的更新出現了問題怎么辦？驗證唄！怎么驗證？每次升級時候去和歷史記錄核對一遍嗎？

這時候，我的腦袋里開始進入了混沌狀態，不知道該怎么辦了，

有點著急啊，怎么辦呢？只好去看看網上有沒有什么方案可以提供一些思路，

最終，這就促成了我對事件溯源(Event Sourcing)模式的初見，

當我看到事件溯源的時候，我腳一跺，我感覺我的智商回來了，

事件溯源拯救快被祭天的我

首先，咱們看看事件溯源是什么樣的，

以咱們現在搞得用戶升級為例，說一下事件溯源模式：

用戶升級時，我們只需要把用戶升級這件事通過 Event Store 這個中間件傳給支付服務、物流服務等這些相關的服務，然后，支付服務、物流服務之類的處理完用戶升級通知給他們的事件后，會也創建一個事件物件，放到 Event Store 里，

這里的 Event Store 其實主要是用來做兩件事:

傳遞事件
存盤事件歷史

那么，事件溯源是怎么來搞定我面臨的這些問題的呢？

首先，如果我們要追根溯源，就需要把用戶升級和用戶升級后相關服務做得處理都要存起來，形成一個完整的業務鏈條，有了這個鏈條，才能被稱為追根溯源，

事件溯源模式正好告訴大家，有事兒就要存起來！

其次，當我們用戶升級的時候把事件存盤下來之后，我們還需要實時去更新級別嗎？

我們來分析一下:用戶升級的真正目的是什么？從業務角度來說，其實就是通過提供各種福利去提升用戶的活躍度，那么，這件事需要實時嗎？似乎不必須，因為用戶幾乎不太可能升級后馬上去使用對應的福利，

好，如果可以不實時，那么用戶升級這件事兒就能避免實時更新資料庫了，

如果我們在開始把歷史事件存盤下來了之后，其實可以在凌晨的時候去定時根據用戶級別發生的事件，去把用戶的級別升級到正確的級別，

所以可以看到了，事件溯源在這事兒上把我的兩個問題全解決了，

這就是我和事件溯源模式的初見，而在今后的技術生涯中，它將會經常陪伴著我，

三、認識

真正認識下事件溯源模式吧

事件溯源總結下來其實只有如下二個核心特點:

1.把觸發業務資料變化的原因包裝成了事件物件——如果把這件事兒抽象的看待一下，就是我們可以把業務中任何需要注意的情況發生變化時，都可以包裝成事件，

2.這些包裝成事件的業務資料會按照事件發生的順序，被持久化存盤到專門的地方——需要專門說一下這個事件按照順序存放的問題，在事件溯源模式中，按照事件發生的順序持久化存盤是非常重要的一件事，如果一個模式中的事件沒有嚴格按照事件順序進行持久化存盤，其實很難說這個模式會是一個合格的事件溯源模式，

所以事件溯源模式就做了兩件事：

定義什么樣的業務邏輯可以被定義為事件；
把定義好的事件在發生后給按順序記錄下來，

事件溯源常伴吾身

認識到了事件溯源的核心特點后，我在后面的開發生涯里反復的使用了這個模式去幫我解決不同業務的特定場景的問題，比如訂單的狀態更新，再比如秒殺活動的性能問題，

在不斷地使用事件溯源程序中，我總結出了需要使用事件溯源的一些場景，當遇到類似的場景時，我總是會第一時間嘗試用事件溯源模式來解決問題，

這些場景是:

想知道關鍵資料被更改時，意圖、原因或者目的時；
更新資料確實性能出現了問題，一時之間也沒辦法通過硬體升級或者大規模集群去解決這個問題；
還原某些現場，或者想通過一些資料重復的還原線上環境是非常重要的事情；

而事實證明，在這些場景中使用事件溯源也確實不負我望，并且還帶來了很多額外的好處:

1.由于事件可以按照順序存盤，所以可以搞成追加方式去持久化，而這種追加操作來持久化事件的方式可以放到前臺，對用戶體驗或者性能要求很高的地方，這樣不會引發前臺卡頓，同時呢，可以讓事件能跟水流一樣，被引入到后臺任務中慢慢處理，

2.事件本身是一種場景記錄，所以，利用這些記錄的時候，可以根據自身情況，在任何合適的時間，合適的環境，去根據事件去實施或者復現某些業務狀態，

3.事件的存盤本身可以被當成一種審計日志，只要記錄的資訊夠全，事件溯源本身就會天然的變成可靠安全的審計資料，

4.事件溯源本身可以和各種事件驅動的系統相融合，非常適合擴展和對接各類靠事件驅動的應用和系統，

5.事件溯源不會給已經非常復雜的業務物件增加復雜度，比如，一個訂單物件，根據訂單物件設計訂單表的時候，可能還得搞個備注欄位用來存盤一些更新時的說明；可能還得搞個最近更新時間記錄下最近更新發生在什么時候；甚至可能由于本身業務狀態的復雜，還得特意拆解成幾個不同的狀態欄位……

總之，隨著我對事件溯源認識的逐漸加深，我覺得自身已經開始有了微服務專家的氣質，

四、不滿

當然，太陽底下沒啥新鮮事兒，任何新東西的引入總會帶來一些不足，同時呢，隨著使用事件溯源模式的次數增多，我也愈發認識到了這個模式的不足，

1.要存盤的事件資料太多了，導致查詢得引入另一個查詢職責分離模式（CQRS），才能解決大部分的查詢問題，

2.使用事件溯源的時候由于事件發生的順序存盤非常重要，所以，使用多執行緒，多行程，集群的時候，就必須要嚴格保證事件順序存盤的正確性，一般來說，得給事件物件搞個時間戳不說，可能還得引入全域唯一識別符號產生器去產生事件 ID，

3.由于事件本身是個業務物件了，所以，你知道了，它自身一定會進化的，所以，還得考慮老版本新版本的共存問題，這種一般至少得給事件結構弄個版本欄位去標識事件物件的版本，

4.事件存下來了，而且大部分時候都是附加形式的順序存盤，這就導致查詢事件的時候沒辦法，只能按照事件識別符號和事件的時間之類的做查詢，而這樣的話，其實就是查詢出來了一個事件流，如果要場景重現和分析業務物件狀態的時候，就非得把這個事件流給整個重新處理一遍，

5.事件溯源這事兒其實就是人為的松綁了業務的一致性要求，但是，業務需要的一致性問題依然還是需要另外的處理，比如，我們搞了電商網站，同時呢，又通過事件溯源模式去落地了庫存商品數量更新的業務，又恰巧把庫存的存貨減少的各種原因給設計成了不同的事件，那么，當庫存因為非客戶下單減少發生時，又恰好客戶在下單，這時候，就需要單獨的處理他們之間的沖突，去保證狀態的一致性，

6.事件這東西本身可能因為業務原因需要各種傳遞，而在這期間，不管使用什么方式去傳播事件，沒人會給你保證事件不會重復傳播，這時候，就得考慮處理事件的冪等性，這也是事件溯源帶來的麻煩，