
隨著業務的不斷發展,單體架構已經無法滿足我們的需求,分布式微服務架構逐漸成為大型互聯網平臺的首選,但所有使用分布式微服務架構的應用都必須面臨一個十分棘手的問題,那就是“分布式事務”問題。
在分布式微服務架構中,幾乎所有業務操作都需要多個服務協作才能完成。對于其中的某個服務而言,它的數據一致性可以交由其自身數據庫事務來保證,但從整個分布式微服務架構來看,其全局數據的一致性卻是無法保證的。
(資料圖片)
Seata 是一個分布式事務處理框架,也是一款開源的分布式事務解決方案,由阿里巴巴和螞蟻金服共同開源的分布式事務解決方案,能夠在微服務架構下提供高性能且簡單易用的分布式事務服務,致力于提供高性能和簡單易用的分布式事務服務。
阿里巴巴作為國內最早一批進行應用分布式(微服務化)改造的企業,很早就遇到微服務架構下的分布式事務問題,阿里巴巴對于分布式事務問題先后發布了以下解決方案:
2014 年,阿里中間件團隊發布 TXC(Taobao Transaction Constructor),為集團內應用提供分布式事務服務。2016 年,TXC 在經過產品化改造后,以 GTS(Global Transaction Service) 的身份登陸阿里云,成為當時業界唯一一款云上分布式事務產品。在阿云里的公有云、專有云解決方案中,開始服務于眾多外部客戶。2019 年起,基于 TXC 和 GTS 的技術積累,阿里中間件團隊發起了開源項目 Fescar(Fast & EaSy Commit And Rollback, FESCAR),和社區一起建設這個分布式事務解決方案。2019 年 fescar 被重命名為了seata(simple extensiable autonomous transaction architecture)。TXC、GTS、Fescar以及seata一脈相承,為解決微服務架構下的分布式事務問題交出了一份與眾不同的答卷。
分布式事務的基本原則可以理解成一個包含了若干個分支事務的全局事務。
分布式事務主要涉及以下概念
本地事務:本地事務由本地資源管理器(通常指數據庫管理系統 DBMS,例如 MySQL、Oracle 等)管理,嚴格地支持 ACID 特性,高效可靠。全局事務:全局事務指的是一次性操作多個資源管理器完成的事務,由一組分支事務組成。分支事務:在分布式事務中,就是一個受全局事務管轄和協調的本地事務。注意:本地事務不具備分布式事務的處理能力,隔離的最小單位受限于資源管理器,即本地事務只能對自己數據庫的操作進行控制,對于其他數據庫的操作則無能為力。
全局事務的職責是協調其管轄的各個分支事務達成一致,要么一起成功提交,要么一起失敗回滾。此外,通常分支事務本身就是一個滿足 ACID特性的本地事務。
Seata對分布式事務的協調和控制,主要是通過XID和3個核心組件實現的。
XID是全局事務唯一標識,可以在服務的調用鏈路中傳遞,綁定到服務的事務上下文中。
Seata定義了3個核心組件
TC(Transaction Coordinator):事務協調器,它是事務的協調者(這里指的是 Seata服務器),主要負責維護全局事務和分支事務的狀態,驅動全局事務提交或回滾。TM(Transaction Manager):事務管理器,它是事務的發起者,負責定義全局事務的范圍,并根據TC維護的全局事務和分支事務狀態,做出開始事務、提交事務、回滾事務的決議。RM(Resource Manager):資源管理器,它是資源的管理者(這里可以將其理解為各服務使用的數據庫)。它負責管理分支事務上的資源,向TC注冊分支事務,匯報分支事務狀態,驅動分支事務的提交或回滾。以上三個組件相互協作,TC 以 Seata 服務器(Server)形式獨立部署,TM 和 RM 則是以 Seata Client的形式集成在微服務中運行。
Seata 的整體工作流程如下
TM向TC申請開啟一個全局事務,全局事務創建成功后,TC會針對這個全局事務生成一個全局唯一的XID;XID 通過服務的調用鏈傳遞到其他服務;RM向TC注冊一個分支事務,并將其納入XID對應全局事務的管轄;TM根據TC收集的各個分支事務的執行結果,向TC發起全局事務提交或回滾決議;TC調度XID下管轄的所有分支事務完成提交或回滾操作。目前Seata為用戶提供了 AT、TCC、SAGA 和 XA 事務模式,為用戶打造一站式的分布式解決方案,可以快速有效地對分布式事務進行控制。
在這四種事務模式中使用最多,最方便的就是 AT 模式。與其他事務模式相比,AT 模式可以應對大多數的業務場景,且基本可以做到無業務入侵,開發人員能夠有更多的精力關注于業務邏輯開發。
接下來會針對于Seata的每種事務模式進行實戰指南。