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