一、什么是事件驅動架構

事件驅動架構是一種促進生產的 軟件架構范式 。事件驅動架構在用微服務構建的現(xiàn)代應用中非常普遍，它用事件來觸發(fā)、解耦服務之間的通信。事件可以是 狀態(tài)的變更 ，比如將商品放入購物車；也可以是 某種標識 ，比如訂單的發(fā)貨通知。

在傳統(tǒng)的軟件架構中，應用邏輯是通過請求、過程驅動的。一個請求執(zhí)行一段邏輯同步返回一個響應，在業(yè)務邏輯中，將要執(zhí)行的代碼按照過程順序進行編排。

而事件驅動架構中，事件消費者會以 異步 的方式處理事件生產者產生的事件，原來過程當中的邏輯交給事件消費者去處理，解開服務之間的耦合，使應用的邏輯聚焦，應用的 職責單一 ， 代碼更加簡潔 ，也能 提升系統(tǒng)的響應能力 。

二、分布式事務的事件驅動架構

在 2020 年，本文作者開源了 Go 語言的分布式事務框架 Seata-Golang。Seata-Golang 實現(xiàn) AT 模式和 TCC 模式，這兩種模式都是過程驅動。

到了 2022 年，隨著對云原生技術的理解深入，從 Kubernetes Control-Loop 思想中獲得靈感，全新設計了高性能、無侵入、事件驅動的 Go 語言分布式事務框架 hptx ，以及支持跨語言分布式事務、讀寫分離、分庫分表的 Mesh 方案 DBPack 。這兩款產品都能解決分布式事務問題， 前者只支持 Go 語言 ， 后者支持任意編程語言 。他們采用了相同的事件驅動架構。下面進行詳細的說明。

過程驅動

在 Seata 的設計中，事務發(fā)起者發(fā)起全局提交后，首先會判斷該事務是否允許異步提交，如果允許，則直接返回提交成功，然后 由  ?AsyncCommittingSessionManager? 來異步地通知每個分支事務提交，AT 事務默認允許異步提交。

如果不允許異步提交，事務協(xié)調者會依次通知全局事務參與者即每個分支事務提交，所有分支事務提交成功后，同步返回給事務發(fā)起者全局事務提交的結果，如上圖。事務協(xié)調者通知事務參與者提交過程中發(fā)生了異常，會將該全局事務標記為  CommitRetrying? 狀態(tài)，將會有一個  RetryCommittingSessionManager 定時從持久存儲中撈取標記的全局事務重試提交。

全局回滾的過程與上圖類似，全局回滾時，AT 模式和 TCC 模式都是同步執(zhí)行，依次通知每個分支事務回滾，然后再響應回滾結果給事務發(fā)起者。如果回滾失敗，則將全局事務標記為 RollbackRetrying? ，由  RetryRollbackingSessionManager 定時撈取標記的全局事務數(shù)據(jù)重試回滾。

Seata-Golang 的用戶經常會問一個問題，事務協(xié)調者 TC Server 怎么做高可用？

Seata 包括 Seata-Golang 默認推薦使用 Mysql 數(shù)據(jù)庫作為 TC 狀態(tài)數(shù)據(jù)的持久化存儲。TC Server 本身則是無狀態(tài)應用，可以部署多個副本，但這里就存在一個問題：多個對等副本里的 

AsyncCommittingSessionManager? 、 RetryCommittingSessionManager? 、 RetryRollbackingSessionManager  都會從數(shù)據(jù)庫去撈取對應的數(shù)據(jù)執(zhí)行，會導致事務的提交、回滾重復執(zhí)行，雖然 AT 模式天然做到冪等，TCC 模式由用戶保證冪等，但總是存在一定的資源浪費，且不夠優(yōu)雅。

事件驅動

上圖展示了 hptx 和 dbpack 的事務協(xié)調邏輯，事務發(fā)起者 AggregationSvc 發(fā)起全局事務提交、回滾，僅僅是修改 ETCD 中的數(shù)據(jù)狀態(tài)，然后立即返回。訂單服務和商品服務使用前綴  bs/${appid}?  Watch 存儲在 ETCD 中的分支事務數(shù)據(jù)，當分支事務的數(shù)據(jù)發(fā)生過變更后，ETCD 馬上推送一個變更事件給相應服務，訂單服務和商品服務收到變更事件后，將數(shù)據(jù)加入  workqueue  去執(zhí)行提交或回滾的邏輯。

AggregationSvc 提交、回滾時不會調用 OrderSvc、ProductSvc 的接口，整個過程通過 ETCD 解耦后異步執(zhí)行。

事務分支提交或者回滾失敗后，會重新進入到 workqueue? 當中繼續(xù)消費，直至提交、回滾成功，或回滾超時（AT 模式回滾操作涉及到全局鎖的釋放，需要設置超時時間，即  retry_dead_threshold ）。

在這個架構中，已經沒有中心化事務協(xié)調者 TC Server，用戶只需要關心自身應用的高可用，如果應用多副本部署，hptx 和 dbpack 會通過 etcd 選主，只有選為 master 的副本才能 watch 自身產生的分支事務數(shù)據(jù)去做提交、回滾，避免了提交、回滾邏輯重復執(zhí)行的問題。

集成 hptx，只需要依賴相應的 sdk，而不需要部署額外的 TC Server，但狀態(tài)數(shù)據(jù)的存儲由原來的 Mysql 換成了 ETCD。

三、新架構帶來的好處

全新的、云原生的、事件驅動架構，更加簡潔，性能更強。采用 hptx 的應用事務協(xié)調性能比 Seata-Golang 提升 1 倍，通過 dbpack 以 mesh 方式協(xié)調分布式事務性能比 seata-golang 提升了百分之 50。下面是一些測試數(shù)據(jù)：

hptx 是當前性能最強的云原生、無侵入分布式事務解決方案，選擇其他內存型存儲組件理論上可以得到更高的性能，但綜合可靠性和性能，ETCD 是目前最好的選擇。

四、結語

經過持續(xù)地在分布式事務領域的研究總結，使分布式事務框架不斷進化，從最初的兼容 java seata 的 seata-golang v1 版本，到云原生的、無侵入的、基于 grpc 的 seata-golang v2 版本，到基于 ETCD watch 機制的、事件驅動的 hptx，再到跨語言的 dbpack，分布式事務一直在進化，能力也在進一步增強。