一、事前
你相信嗎？曾經有一段日子，我幾乎沒接到過合格的產品需求。
開局幾句話，技術全靠猜。
總是以為簡單的需求
曾經，我從產品那里接到過這么一個需求:
對系統的用戶進行分級，不同級別的用戶有不同的福利。
依然如常，無圖無文檔，只是這么一句話。我知道，需求一句話，分析五日功嘛。為了項目能持續發展，我只好自己分析自己搞了。
從業務上看，目前的用戶對象尚無等級一說，我們先為用戶對象加上個級別屬性。又因為不同的用戶等級，可享受到不同的福利。比如：達到 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.事件這東西本身可能因為業務原因需要各種傳遞，而在這期間，不管使用什么方式去傳播事件，沒人會給你保證事件不會重復傳播。這時候，就得考慮處理事件的冪等性。這也是事件溯源帶來的麻煩。
五、結尾
事件溯源模式雖然解決了我的很多問題，但是同時又因為引入這個模式，我又增加了很大的工作量。真是金無足赤啊。
也許這世上根本不存在什么溯源模式，有的只是防止背鍋的無奈罷了。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百余人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注之后還可以獲取算法、高並發等干貨學習資料。
我建了一個讀者交流群，里面大部分是程序員，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
