一、什么是事件驅(qū)動(dòng)架構(gòu)

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

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

而事件驅(qū)動(dòng)架構(gòu)中，事件消費(fèi)者會(huì)以 異步 的方式處理事件生產(chǎn)者產(chǎn)生的事件，原來過程當(dāng)中的邏輯交給事件消費(fèi)者去處理，解開服務(wù)之間的耦合，使應(yīng)用的邏輯聚焦，應(yīng)用的 職責(zé)單一 ， 代碼更加簡潔 ，也能 提升系統(tǒng)的響應(yīng)能力 。

二、分布式事務(wù)的事件驅(qū)動(dòng)架構(gòu)

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

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

過程驅(qū)動(dòng)

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

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

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

Seata-Golang 的用戶經(jīng)常會(huì)問一個(gè)問題，事務(wù)協(xié)調(diào)者 TC Server 怎么做高可用？

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

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

事件驅(qū)動(dòng)

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

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

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

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

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

三、新架構(gòu)帶來的好處

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

hptx 是當(dāng)前性能最強(qiáng)的云原生、無侵入分布式事務(wù)解決方案，選擇其他內(nèi)存型存儲(chǔ)組件理論上可以得到更高的性能，但綜合可靠性和性能，ETCD 是目前最好的選擇。

四、結(jié)語

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