1、事前
你相信嗎？曾經有一段日子，我幾乎沒接到過合格的產品需求。前端
開局幾句話，技術全靠猜。程序員
老是覺得簡單的需求
曾經，我從產品那裏接到過這麼一個需求:數據庫
對系統的用戶進行分級，不一樣級別的用戶有不一樣的福利。緩存
依然如常，無圖無文檔，只是這麼一句話。我知道，需求一句話，分析五日功嘛。爲了項目能持續發展，我只好本身分析本身搞了。安全
從業務上看，目前的用戶對象尚無等級一說，咱們先爲用戶對象加上個級別屬性。又由於不一樣的用戶等級，可享受到不一樣的福利。好比：達到 3 級的用戶，能夠享受購物 9.5 折優惠，物流費用全免，客服快速回復等。微信
因此，我作出設計以下:多線程
首先，我把每一個等級用戶該享受的福利放到一個列表裏。這個用來供前端展現用戶當前可享受到的福利。架構
而後，在每一項福利中，我去設定一個可享受此福利的最低級別。只有用戶的級別超過這個最低級別的時候，才能夠享受到此項福利。好比，支付優惠 9.5 折，我只須要在支付服務中打包個支付權利 9.5 折這種東西，而後設定個最低級別便可。微服務
這事兒看着是如此簡單，因此，實現方案也沒什麼特殊的。當用戶每次升級的時候，我只須要更新用戶級別便可。性能
這個時候，需求比較初級，要求也不高。在知足升級條件後，須要用戶主動點擊升級。同時，再填寫一些相關信息，申請一些專屬的福利就能夠了。
好，設計，開發，上線一條龍走起來！
需求變成坑
過了一陣子，咱們的運營們敢於探索，勤於開拓，去搞了一堆資源互換回來。當我據說此事時，內心已經預感不妙了。
果真，沒兩天，咱們的產品高高興興地通知我，因爲兄弟團隊願意和咱們的項目進行合做，所以用戶的福利將獲得極大的豐富，那些更加豐富的福利全都由兄弟團隊提供。
因此，請我簡單的搞一下，對接上這些合做方，進一步提高咱們系統的粘性。
如常，依然沒有任何文檔，我依然只能本身分析。
如今，根據我豐富的被折騰經驗，我知道開始有坑了。當我對接合做方接口的時候，他們都須要我傳入一些特定的用戶標識過去，可讓雙方共享用戶。
需求開始複雜了，不過慶幸的是，我改改代碼就能夠了，還好還好，我鬆了口氣……
好，設計，開發，上線一條龍走起！
惋惜，咱們的業務就像一羣羣的蜜蜂同樣，你永遠不知道他們會給你帶來什麼樣的花朵。
沒過太久，產品告訴我，幾個兄弟團隊想和咱們一塊兒搞一次超級大活動。我以爲天黑了……
沒文檔沒有產品原型，依然就是微信中的來來每每。
我知道此時，我得往深裏想一想了。需求是能夠肆意妄爲的，而我能阻止業務需求的肆意妄爲嗎？不能，因此，我要考慮一整套彈性的方案，能應對這些變幻無窮，又漫天飛舞的需求。
2、初見
隱患的伊始
來看看這個見鬼的大活動吧。
首先，按照設計，若是合做方們想要和咱們一塊兒大聯歡，那麼咱們就要把用戶升級的信息告訴他們。這樣，合做方們才能進行驗證，並提供用戶級別對應的福利。因此，當咱們的用戶升級的時候，我須要每次都把這件事同步給咱們的合做方。
又由於咱們是和多個兄弟團隊合做，好比，和物流團隊合做，和支付團隊合做。在這種狀況下，不一樣合做方的互動邏輯是分佈在不一樣的服務中的。
此時，我有兩種方案可供選擇:
1.在用戶服務裏，用戶升級時，當即主動的經過接口去調用分佈在不一樣的服務上的相關邏輯，把用戶升級這件事同步到合做方那裏。可是，這個方案有個很大的問題——由於咱們須要調用其餘服務的接口，這就形成服務和服務之間耦合起來了。未來有點小改動，可能都須要咱們改代碼。
2.在微服務裏，實際上是很推崇使用消息隊列的。當用戶升級時，我只需發送消息到消息隊列中，而後讓相關的服務去訂閱這個消息便可。這個方案，使用消息隊列能夠解耦服務之間的關係。
由於微服務自己的目的就是解耦和靈活，而且第二個方案和咱們架構是適配的，所以我選擇了第二個方案。
在第二個方案中，正由於消息能夠把服務之間進行解耦，因此，當用戶升級的時候，我只須要操做用戶服務數據庫中的用戶表進行升級，並把升級這事兒包裹成消息扔到消息隊列中便可。
我甚至能夠把更新用戶表和發送升級消息到隊列包裝成一個事務。
好，設計，開發，上線一條龍走起！
這就是能應對後續不斷變化的技術方案嗎？事實證實，並不能，由於，這套方案即將會被變化的需求給完全擊垮。
問題的大爆發
斗轉星移，時空變幻。需求如滾滾的流水般涌來，而咱們的技術方案如同一套不管如何加強也不夠健壯的大壩。
通過幾度需求的變換，此時用戶升級已經變成了知足條件後自動升級；咱們合做的兄弟團隊也日益增多；咱們的服務也越拆越多……在這些汩汩涌出的變化中，問題已經如同潛伏在水底的鱷魚，即將爬上岸來獵取幾個程序員來祭天了。
問題的跡象一開始出如今用戶升級的數據上。那時，咱們接連被運營們提的問題所困擾。
有些運營人員發現，某些用戶升級過快了，用戶的升級速度已經遠遠超出了當初設計時預估的速度了。
而這種過快的升級不只使得運營人員沒法及時構思和設計後續的運營活動，還使得咱們的運營成本快速的上漲，並所以給公司經營帶來了必定的損失。
固然，如同以往同樣，業務是歷來不會出錯的，出錯的永遠是技術。這不，出問題的緣由都給咱們安排的明明白白了：
極可能是程序出了 bug，由於出了某些技術性的故障，致使用戶升級的時候沒有一級級的升上去，出現了跳躍性的升級…………
在追蹤問題的時候，咱們猛然發現了這個技術方案的一個缺陷：因爲根本沒有預料到用戶升級的重要性，咱們的不少用戶升級相關的日誌並未開啓，而且沒有存儲任何用戶升級的歷史記錄。
這瞬間成了一筆糊塗帳，我無 fuck 可說。
雪上加霜的是，又有用戶們投訴，他們老是在某些時候會出現一些卡頓。咱們再一查，發現是用戶升級致使的數據庫問題。
最先的設計是用戶升級直接更新數據庫表，可是大意了：
- 當用戶數量出現大漲的時候。
- 新用戶初期升級難度小，因此升級很頻繁。
忽略了這兩個因素，這就形成了咱們的數據庫有點承受不住這種頻繁的更新。
並且，在查這些問題的時候，之前有些用戶投訴的問題也隨之被挖了出來。好比，用戶升級後有些福利卻沒有給他們，悲催的是這些痕跡也沒有被完整的留下來……
糊塗帳加糊塗帳成了筆爛帳。
啊，我要被祭天了嗎？
跺腳後智商從新佔領高地
如今來看看咱們要面臨的問題吧。
首先出場的是用戶升級無法追根溯源的問題。由於咱們每次用戶升級，須要通知相關的服務，而後還得保證每一個相關的服務處理成功了，到此時，用戶升級纔算真正的成功。因此，爲了能還技術們一個清白，能別搞得成爲爛帳，就必須把用戶的每次升級給記錄下來，而且還得把每一個相關服務對升級事件的處理也記錄在案。
下一個要解決的小兄弟是數據庫更新的問題。這個數據庫更新該怎麼辦？緩存後同步？那緩存自己的更新出現了問題怎麼辦？驗證唄！怎麼驗證？每次升級時候去和歷史記錄覈對一遍嗎？
這時候，個人腦殼裏開始進入了混沌狀態。不知道該怎麼辦了。
有點着急啊，怎麼辦呢？只好去看看網上有沒有什麼方案能夠提供一些思路。
最終，這就促成了我對事件溯源(Event Sourcing)模式的初見。
當我看到事件溯源的時候，我腳一跺，我感受個人智商回來了。
事件溯源拯救快被祭天的我
首先，我們看看事件溯源是什麼樣的。
以我們如今搞得用戶升級爲例，說一下事件溯源模式：
用戶升級時，咱們只須要把用戶升級這件事經過 Event Store 這個中間件傳給支付服務、物流服務等這些相關的服務。而後，支付服務、物流服務之類的處理完用戶升級通知給他們的事件後，會也建立一個事件對象，放到 Event Store 裏。
這裏的 Event Store 其實主要是用來作兩件事:
- 傳遞事件
- 存儲事件歷史
那麼，事件溯源是怎麼來搞定我面臨的這些問題的呢？
首先，若是咱們要追根溯源，就須要把用戶升級和用戶升級後相關服務作得處理都要存起來，造成一個完整的業務鏈條。有了這個鏈條，才能被稱爲追根溯源。
事件溯源模式正好告訴你們，有事兒就要存起來！
其次，當咱們用戶升級的時候把事件存儲下來以後，咱們還須要實時去更新級別嗎？
咱們來分析一下:用戶升級的真正目的是什麼？從業務角度來講，其實就是經過提供各類福利去提高用戶的活躍度。那麼，這件事須要實時嗎？彷佛沒必要須，由於用戶幾乎不太可能升級後立刻去使用對應的福利。
好，若是能夠不實時，那麼用戶升級這件事兒就能避免實時更新數據庫了。
若是咱們在開始把歷史事件存儲下來了以後，其實能夠在凌晨的時候去定時根據用戶級別發生的事件，去把用戶的級別升級到正確的級別。
因此能夠看到了，事件溯源在這事兒上把個人兩個問題全解決了。
這就是我和事件溯源模式的初見。而在從此的技術生涯中，它將會常常陪伴着我。
3、認識
真正認識下事件溯源模式吧
事件溯源總結下來其實只有以下二個核心特色:
1.把觸發業務數據變化的緣由包裝成了事件對象——若是把這件事兒抽象的看待一下，就是咱們能夠把業務中任何須要注意的狀況發生變化時，均可以包裝成事件。
2.這些包裝成事件的業務數據會按照事件發生的順序，被持久化存儲到專門的地方——須要專門說一下這個事件按照順序存放的問題，在事件溯源模式中，按照事件發生的順序持久化存儲是很是重要的一件事。若是一個模式中的事件沒有嚴格按照事件順序進行持久化存儲，其實很難說這個模式會是一個合格的事件溯源模式。
因此事件溯源模式就作了兩件事：
- 定義什麼樣的業務邏輯能夠被定義爲事件；
- 把定義好的事件在發生後給按順序記錄下來。
事件溯源常伴吾身
認識到了事件溯源的核心特色後，我在後面的開發生涯裏反覆的使用了這個模式去幫我解決不一樣業務的特定場景的問題。好比訂單的狀態更新，再好比秒殺活動的性能問題。
在不斷地使用事件溯源過程當中，我總結出了須要使用事件溯源的一些場景。當遇到相似的場景時，我老是會第一時間嘗試用事件溯源模式來解決問題。
這些場景是:
-
想知道關鍵數據被更改時，意圖、緣由或者目的時；
-
更新數據確實性能出現了問題，一時之間也沒辦法經過硬件升級或者大規模集羣去解決這個問題；
-
還原某些現場，或者想經過一些數據重複的還原線上環境是很是重要的事情；
而事實證實，在這些場景中使用事件溯源也確實不負我望，而且還帶來了不少額外的好處:
1.因爲事件能夠按照順序存儲，因此能夠搞成追加方式去持久化，而這種追加操做來持久化事件的方式能夠放到前臺，對用戶體驗或者性能要求很高的地方。這樣不會引起前臺卡頓。同時呢，可讓事件能跟水流同樣，被引入到後臺任務中慢慢處理。
2.事件自己是一種場景記錄，因此，利用這些記錄的時候，能夠根據自身狀況，在任何合適的時間，合適的環境，去根據事件去實施或者復現某些業務狀態。
3.事件的存儲自己能夠被當成一種審計日誌，只要記錄的信息夠全，事件溯源自己就會自然的變成可靠安全的審計數據。
4.事件溯源自己能夠和各類事件驅動的系統相融合，很是適合擴展和對接各種靠事件驅動的應用和系統。
5.事件溯源不會給已經很是複雜的業務對象增長複雜度。好比，一個訂單對象，根據訂單對象設計訂單表的時候，可能還得搞個備註字段用來存儲一些更新時的說明；可能還得搞個最近更新時間記錄下最近更新發生在何時；甚至可能因爲自己業務狀態的複雜，還得特地拆解成幾個不一樣的狀態字段……
總之，隨着我對事件溯源認識的逐漸加深，我以爲自身已經開始有了微服務專家的氣質。
4、不滿
固然，太陽底下沒啥新鮮事兒。任何新東西的引入總會帶來一些不足，同時呢，隨着使用事件溯源模式的次數增多，我也愈發認識到了這個模式的不足。
1.要存儲的事件數據太多了，致使查詢得引入另外一個查詢職責分離模式（CQRS），才能解決大部分的查詢問題。
2.使用事件溯源的時候因爲事件發生的順序存儲很是重要，因此，使用多線程，多進程，集羣的時候，就必需要嚴格保證事件順序存儲的正確性，通常來講，得給事件對象搞個時間戳不說，可能還得引入全局惟一標識符產生器去產生事件 ID。
3.因爲事件自己是個業務對象了，因此，你知道了，它自身必定會進化的。因此，還得考慮老版本新版本的共存問題，這種通常至少得給事件結構弄個版本字段去標識事件對象的版本。
4.事件存下來了，並且大部分時候都是附加形式的順序存儲。這就致使查詢事件的時候沒辦法，只能按照事件標識符和事件的時間之類的作查詢，而這樣的話，其實就是查詢出來了一個事件流。若是要場景重現和分析業務對象狀態的時候，就非得把這個事件流給整個從新處理一遍。
5.事件溯源這事兒其實就是人爲的鬆綁了業務的一致性要求。可是，業務須要的一致性問題依然仍是須要另外的處理。好比，咱們搞了電商網站，同時呢，又經過事件溯源模式去落地了庫存商品數量更新的業務，又恰巧把庫存的存貨減小的各類緣由給設計成了不一樣的事件，那麼，當庫存由於非客戶下單減小發生時，又剛好客戶在下單，這時候，就須要單獨的處理他們之間的衝突，去保證狀態的一致性。
6.事件這東西自己可能由於業務緣由須要各類傳遞，而在這期間，無論使用什麼方式去傳播事件，沒人會給你保證事件不會重複傳播。這時候，就得考慮處理事件的冪等性。這也是事件溯源帶來的麻煩。
5、結尾
事件溯源模式雖然解決了個人不少問題，可是同時又由於引入這個模式，我又增長了很大的工做量。真是金無足赤啊。
也許這世上根本不存在什麼溯源模式，有的只是防止背鍋的無奈罷了。
你好，我是四猿外，一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把本身的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注個人公衆號或者加我微信交流。