重新理解事件和數據 -《微服務與事件驅動架構》讀後感

理解事件驅動型微服務架構，需要重新思考數據是什麼以及服務要如何訪問和使用數據。

事件驅動的核心是把事件作為唯一的事實，為此就需要把全部操作的事件流持久化存儲，下遊服務消費事件，計算出應用業務邏輯當前的狀态，服務自己維護的數據，隻是狀态的物化視圖。通過Flink這樣的流式計算框架，指定偏移量，幂等的下遊服務，就可以重建所有狀态。

微服務不是零成本的，微服務稅是與實現微服務架構的工具和組建相關的成本總和，包括财務、人力和機會成本;包含了管理、部署、操作事件代理、CMS、監控和日志的開銷。

業務的界限上下文，是拆分事件和微服務的标準，而不是技術邊界和服務治理的需要。作者建議采用混合和漸進式的方式。

要從業務代碼中解放事件流可以用查詢、日志和中間表等方式，從底層數據存儲中提取數據并創建事件流。當然這一切是以事件代理為核心的。

...

事件驅動中的編制器模式

剛知道SAGA的時候，覺得很高大上。但是如果回到計算機系統運行的基本原理，其實并沒有什麼神奇的力量在裡面。

在事件驅動的語境下，這一類的分布式異步操作的順序執行過程，被作者稱之為編制模式。

我的理解是這樣的。如果我們有一系列操作，是異步而且獨立執行的，最後有一個業務邏輯的結果，又依賴所有操作的執行結果，那麼毫無疑問，必須要有一個中間的協調者，也就是編制器，負責觸發事件流或者發起請求，監控執行過程，并且确認結果。

編制器用自己的内存、支持事務或者鎖機制的外部存儲，就可以實現對整體執行過程的管理，通過狀态持久化，還可以在異常發生時重新恢複現場。

對應的就會要求消費者或者執行器，能夠對操作有幂等和回滾的支持，這樣就可以作為原子操作，整體撤銷。

如果不影響業務邏輯和産品交互，可以從存儲中直接物理或者邏輯删除數據，重置狀态。但是更符合現實世界的方式，可能是像會記記賬一樣，用沖銷的方式來回滾，下單成功的訂單加一個取消操作，就可以采用一緻性的方式完成回滾撤銷。

微服務和微服務團隊

微服務可以根據自身需要存儲和管理數據，并且能達到之前僅限于批處理大數據解決方案的規模。

微服務本身是微小且定制的，能在兩周内實現，應該像是出自一個人。

作者提出了兩種微服務團隊的結構，一種是後端微服務，一種是微前端，我覺得應該叫做全棧微服務，但是這種拆分的邊界，應該是組織的溝通結構，産品形态決定如何組織開發團隊，不可能從技術角度去拆分，雖然服務治理需要通過度量發現瓶頸，然後拆分數據庫、拆分計算資源，但是隻有業務的邊界才是決定系統演進方向最重要的決定性力量。

微服務的結構

就像鳳凰架構這本書裡說的，微服務帶來的是整個組織和系統的反脆弱能力，微服務的确可以為架構帶來健壯性，獨立正交的上下線服務和裁剪擴展團隊，降低複雜性，但是這種複雜性是架構和團隊層面。

與代碼如何組織是正交的，有清晰的結構設計、良好的約定和規範，并且能夠堅定執行，同一個代碼倉庫，同樣可以構建大型複雜的系統。

微服務每個代碼服務獨立代碼庫，最佳的場景，一定是業務之間正交非常少，而且沒有非常複雜的聚合層的情況。

關于健壯性，從硬件領域的RAID磁盤陣列我們就知道，冗餘帶來健壯性，代價就是我們所知道的微服務稅，要先交稅才能享受微服務帶來的反脆弱性。

冗餘這個詞，本身就充滿矛盾，既可以是褒義詞，帶來健壯性；也可以是貶義詞，帶來重複和降低單位效率，取決于觀察的角度。

說到代碼拆分的冗餘，我覺得至少對領域和界限上下文的業務建模，是不可消除的元信息。信息系統顧名思義就是對特定領域業務知識的數字化，業務架構，需要把業務邏輯轉化成計算機可以理解的文本、代碼，隻有充分才能反映業務本身，這就是必不可少的工作量，無論如何，就是要把這些領域相關術語和關系，一個字一個字的打出來，寫到代碼裡。

多一個系統需要領域知識，就要根據對業務的理解和需要，完成建模。有了元數據，才能編寫代碼然後運行。

事件驅動結構中的數據

在作者所推崇的事件驅動架構中，所有事件流隻能有一個唯一的生産者這是非常重要的選擇，表流二元性是創建狀态的基礎，事件都必須以不可變數據的方式存儲，這樣系統才能将事件流物化成當前的狀态。

整本書看下來，是對數據存儲的重新理解，非常不同于數據庫為核心的系統的，共享數據庫帶來了遷移和查詢的便利，不過任何共享必然都會帶來耦合，不耦合就隻能用冗餘，隻能根據項目和業務的實際情況來判斷，适應當前情況才是最好的。

還有一點是關于Schema固然可以有代碼生成器支持和自動檢查，但是本身也帶來了一定耦合，尤其是變化很快的地方，這也是需要權衡，schema本身隻是活文檔，純文本是計算機可以運行人類也可以理解的，但是要在schema上加多少約束和擴展，是需要權衡取舍的，不然SOAP這樣的重量級架構早就到處都是，微服務就不會是用微來修飾。

...