您好,登錄后才能下訂單哦!
轉載本文需注明出處:微信公眾號EAWorld,違者必究。
引言:
目錄:
1.分布式事務講解
2.分布式事務解決方案-servicecomb-pack
3.分布式事務實戰(zhàn)講解
1. 分布式事務講解
1.1事務原理
在講分布式事務之前,先聊一下事務。簡單講事務是數(shù)據庫管理系統(tǒng)執(zhí)行過程中的一個邏輯單元,它能保證要么一組數(shù)據庫操作全部執(zhí)行成功,要么全部失敗,而做到這些的原理就是事務的ACID四大特性。
A. Atomic原子性的簡稱,事務作為一個整體來執(zhí)行,要么全部成功,要么全部失敗。
C. Consistency一致性的簡稱,事務應確保數(shù)據從一個一致的狀態(tài)轉變?yōu)榱硪粋€一致的狀態(tài)。
I. Isolation隔離性的簡稱,多個事務并發(fā)執(zhí)行時,一個事務的執(zhí)行不影響其他事務的執(zhí)行。
D.Durability持久性的檢查,已提交的事務修改數(shù)據會被持久保存。
1.2傳統(tǒng)單機數(shù)據庫事務
在傳統(tǒng)單體應用架構中,我們的業(yè)務數(shù)據通常都是存儲在一個數(shù)據庫中的,應用中的各個模塊對數(shù)據庫直接進行操作。在這種場景中,事務是由數(shù)據庫提供的基于ACID特性來保證的。
例如,在一個用戶購物下單的場景中,涉及到用戶、訂單、支付、庫存等模塊的一系列協(xié)同操作,如果其中一個模塊出現(xiàn)問題,我們就可以通過數(shù)據庫提供的事務特性來保證本次下單操作要么都成功,要么都失敗。因為這些模塊用的是同一個數(shù)據庫,所處的是同一個事務管理器,不需要做額外的其他操作就能保證事務的特性。
從廣義上來講,分布式事務其實也是事務,只是區(qū)別于單機事務不同之處是:由于業(yè)務上的定義和系統(tǒng)微服務架構的設計,很多大型的業(yè)務流程都被拆分成了多個單一的基礎服務,而為了保證每個微服務都能獨立進行開發(fā)和部署運行,通常都會采用一個微服務一個數(shù)據庫的架構配套,然后將內部服務進行封裝,以Rest api方式對外暴露。這樣以往基于數(shù)據庫來實現(xiàn)的數(shù)據操作,就變成了多個對外提供微服務的微服務系統(tǒng)之間的協(xié)同操作。在這種情況下,原有的單機事務方式已經不能夠使用了,因為多個服務就意味著存在多個事務管理器和多個資源,單個微服務的本地事務管理器只能保證本地事務的ACID,為了在多個服務之間能保證業(yè)務的事務性,參與分布式事務的微服務通常會依托協(xié)調器來完成相關的一致性協(xié)調操作。
那我們在微服務系統(tǒng)實際開發(fā)中,如何去實現(xiàn)協(xié)調器以處理分布式事務呢,這里的解決方案是采用華為提供的servicecomb-pack框架來解決這一問題。
2. 分布式事務解決方案:
servicecomb-pack
2.1補償方式
在講servicecomb-pack之前先了解兩個概念:不完美補償(saga)和完美補償(tcc)。
saga:不完美補償,一般在系統(tǒng)中我們會專門為業(yè)務邏輯對應寫一個補償邏輯,如果業(yè)務邏輯執(zhí)行失敗,就會去執(zhí)行這個補償邏輯,我們稱這個補償邏輯為反向操作,這個反向操作同樣會留下操作痕跡,例如:在銀行系統(tǒng)中,客戶去ATM取錢,銀行會先對用戶賬戶進行扣款操作,如果本次取錢不成功,銀行系統(tǒng)會發(fā)出一筆沖正操作,將之前扣除的款項打回用戶賬戶,這個沖正操作在交易記錄里面是開源查詢到的。
tcc:完美補償,cancel階段會徹底清楚之前的業(yè)務邏輯操作,用戶是感知不到的。例如:在一個交易平臺去發(fā)起交易,首先在try階段不會直接去扣除賬戶余額,而且去檢查用戶的額度并刷新額度,然后在confirm階段才去真正操作賬戶。如果出現(xiàn)異常,那么在cancel階段就需要去執(zhí)行業(yè)務邏輯來取消try階段產生的后果,釋放在try階段被占用的額度。整個過程只有等confirm執(zhí)行完畢,交易才算完成。
2.2servicecomb-pack
servicecomb-pack出自于華為微服務框架servicecomb,是一個開源的分布式事務最終一致性解決方案,該項目已交由Apache軟件基金會孵化,目前已經在apache畢業(yè)了。0.3.0版本之前叫servicecomb-saga,現(xiàn)版本已經改名為servicecomb-pack。
servicecomb-pack架構主要包含兩個組件:alpha和Omega
alpha:alpha其實就是一個server端,需要用戶自行編譯運行,它的作用就是上述中的分布式事務協(xié)調器,主要作用是和Omega客戶端進行通訊,接收omega發(fā)過來的事務事件,然后進行持久化存儲事務以及修改協(xié)調子事務的狀態(tài),從而保證全局事務中的所有子事務狀態(tài)都一致,即要么全執(zhí)行完成,要么全執(zhí)行失敗。
omega:Omega端其實可以看成是一個微服務中內嵌的agent,主要作用是監(jiān)控本地子事務的執(zhí)行情況并向alpha-server端發(fā)送子事務執(zhí)行事件以及傳遞全局事務ID,并在異常情況下會根據alpha下發(fā)的操作事件進行相應的補償操作。
Omega會以切面編程的方式向應用程序注入相關的處理模塊,幫助我們構建分布式事務調用的上下文。Omega在事務處理初始階段處理事務的相關準備的操作,在事務執(zhí)行完畢做一些清理的操作,例如創(chuàng)建分布式事務起始事件,以及相關的子事件,根據事務的執(zhí)行的成功或者失敗生產相關的事務終止或者失敗事件。這樣帶來的好處是用戶的代碼只需要添加幾個annotation 來描述分布式事務執(zhí)行范圍,以及與本地的事務處理恢復的相關函數(shù)信息,Omega就能通過切面注入的代碼能夠追蹤與本地事務的執(zhí)行情況。Omega會將本地事務執(zhí)行的情況以事件的方式通知給Alpha。由于單個Omega不可能知曉一個分布式事務下其他參與服務的執(zhí)行情況, 這樣就需要Alpha扮演一個十分重要的協(xié)調者的角色。Alpha將收集到的分布式事務事件信息整理匯總,通過分析這些事件之間的關系可以了解到分布式事務的執(zhí)行情況, Alpha通過向Omega下發(fā)相關的執(zhí)行指令由Omega執(zhí)行相關提交或恢復操作,實現(xiàn)分布式事務的最終一致性。
在了解的Pack實現(xiàn)的部分細節(jié)之后, 我們可以從下圖進一步了解ServiceComb Pack架構下,Alpha與Omega內部各模塊之間的關系圖[1]。
整個架構分為三個部分,一個是Alpha協(xié)調器,另外一個就是注入到微服務實例中的Omega,以及Alpha與Omega之間的交互協(xié)議, 目前ServiceComb Pack支持Saga 以及TCC兩種分布式事務協(xié)調協(xié)議實現(xiàn)。
Omega包含了與分析用戶分布式事務邏輯相關的事務注解模塊(Transaction Annotation)以及事務攔截器(Transaction Interceptor);分布式事務執(zhí)行相關的事務上下文(Transaction Context),事務回調(Transaction Callback) ,事務執(zhí)行器(Transaction Executor);以及負責與Alpha進行通訊的事務傳輸(Transaction Transport)模塊。
事務注解模塊是分布式事務的用戶界面,用戶將這些標注添加到自己的業(yè)務代碼之上用以描述與分布式事務相關的信息,這樣Omega就可以按照分布式事務的協(xié)調要求進行相關的處理。如果大家擴展自己的分布式事務,也可以通過定義自己的事務標注來實現(xiàn)。
事務攔截器這個模塊我們可以借助AOP手段,在用戶標注的代碼基礎上添加相關的攔截代碼,獲取到與分布式事務以及本地事務執(zhí)行相關的信息,并借助事務傳輸模塊與Alpha進行通訊傳遞事件。
事務上下文為Omega內部提供了一個傳遞事務調用信息的一個手段,借助前面提到的全局事務ID以及本地事務ID的對應關系,Alpha可以很容易檢索到與一個分布式事務相關的所有本地事務事件信息。
事務執(zhí)行器主要是為了處理事務調用超時設計的模塊。由于Alpha與Omega之間的連接有可能不可靠,Alpha端很難判斷Omega本地事務執(zhí)行超時是由Alpha與Omega直接的網絡引起的還是Omega自身調用的問題,因此設計了事務執(zhí)行器來監(jiān)控Omega的本地的執(zhí)行情況,簡化Omega的超時操作。目前Omega的缺省實現(xiàn)是直接調用事務方法,由Alpha的后臺服務通過掃描事件表的方式來確定事務執(zhí)行時間是否超時。
事務回調在Omega與Alpha建立連接的時候就會向Alpha進行注冊,當Alpha需要進行相關的協(xié)調操作的時候,會直接調用Omega注冊的回調方法進行通信。由于微服務實例在云化場景啟停會很頻繁,我們不能假設Alpha一直能找到原有注冊上的事務回調, 因此我們建議微服務實例是無狀態(tài)的,這樣Alpha只需要根據服務名就能找到對應的Omega進行通信。
事務傳輸模塊負責Omega與Alpha之間的通訊,在具體的實現(xiàn)過程中,Pack通過定義相關的Grpc描述接口文件定義了TCC 以及Saga的事務交互方法, 同時也定義了與交互相關的事件[2]。
3. 分布式事務實戰(zhàn)
3.1 alpha-server配置
3.1.1編譯alpha-server
1. 環(huán)境準備
JDK1.8
Maven3.x
2. 源碼獲取
Github地址:https://github.com/apache/servicecomb-pack
$ git clone:https://github.com/apache/servicecomb-pack.git
$ git checkout 0.4.0
3. 修改配置文件
找到alpha-server/src/main/resource/application.yaml,修改datasource信息為本地信息即可
4. 本地構建alpha-server
$ cd servicecomb-pack
$ mvn clean install -DskipTests -Pspring-boot-2
在執(zhí)行完命令后,可在alpha/alpha-server/target/saga/alpha-server-${version}-exec.jar中找到alpha-server的可執(zhí)行jar包
5. 初始化數(shù)據庫
可在alpha\alpha-server\src\main\resources目錄下找到schema-mysql.sql和schema-postgresql.sql兩個sql文件,可自行根據所選數(shù)據庫進行初始化即可。
6. 啟動alpha-server
java -Dspring.profiles.active=prd -D"spring.datasource.url=jdbc:postgresql://${host_address}:5432/saga?useSSL=false" -jar alpha-server-${saga_version}-exec.jar
*注意:請在執(zhí)行命令前將${saga_version}和${host_address}更改為實際值
至此,alpha-server全局事務管理器已經啟動成功。
3.1.2替換postgresql為mysql
目前alpha-server支持pg和mysql兩種數(shù)據庫,默認為pg,如需改為mysql,需要進行如下操作:
1. 安裝并運行mysql
2. 修改pom文件,添加依賴
alpha-server/pom.xml,添加mysql依賴
ependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> <version>8.0.15</version> </dependency>
3. 修改配置文件
找到alpha-server/src/main/resource/application.yaml,修改datasource信息為本地信息即可
spring: profiles: mysql datasource: username: ${username} password: ${password} url: jdbc:mysql://${host_address}:${port}/${database_name}?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=UTF-8&useSSL=false platform: mysql continue-on-error: false driver-class-name: com.mysql.cj.jdbc.Driver
(左右滑動查看全部代碼)
4. 本地構建alpha-server(和上面步驟一致)
5. 啟動alpha-server
java -Dspring.profiles.active=mysql -Dloader.path=./plugins -D"spring.datasource.url=jdbc:mysql://${host_address}:3306/${database_name}? serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=UTF-8&useSSL=false " -jar alpha-server-${saga_version}-exec.jar
3.2 Omega配置
配置完alpha-server之后,就相當于分布式事務的協(xié)調器已經配置完成,剩下的就是omega的配置,也就是在實際開發(fā)中如何運用servicecomb-pack去處理分布式事務。本次講解會結合一個實際案例:購物系統(tǒng)中的下單流程和刪除產品流程來分別講解saga模式和tcc模式如何使用的。
3.2.1 環(huán)境準備
本次案例:購物系統(tǒng)是采用分布式微服務架構,整體分為三個微服務應用:orderManage訂單管理應用、productManage產品管理應用、stockManage庫存管理應用
1. 添加依賴
分別在三個應用的pom文件中添加Omega所需的依賴:
<dependency> <groupId>org.apache.servicecomb.pack</groupId> <artifactId>omega-spring-starter</artifactId> <version>${servicecomb-pack.version}</version> </dependency> <dependency> <groupId>org.apache.servicecomb.pack</groupId> <artifactId>omega-transport-resttemplate</artifactId> <version>${servicecomb-pack.version}</version> </dependency> <!--非必需 --> <dependency> <groupId>org.apache.servicecomb.pack</groupId> <artifactId>omega-spring-cloud-consul-starter</artifactId> <version>${servicecomb-pack.version}</version> </dependency> <dependency> <groupId>org.apache.servicecomb.pack</groupId> <artifactId>omega-spring-cloud-eureka-starter</artifactId> <version>${servicecomb-pack.version}</version> </dependency>
*注意:請將${servicecomb-pack.version}更改為實際的版本號(推薦版本為0.4.0)
*注意:如需做集群,omega-spring-cloud-consul-starter和omega-spring-cloud-eureka-starter二選一,視項目的注冊中心而定。
2. 修改配置文件
分別在三個應用的application.yml配置文件中添加alpha-server配置,具體配置如下:
#配置alpha-server地址 alpha: cluster: address: 10.15.15.172:8080 omega: enabled: true
注意:application.name一定不要過長,因為instanceId的格式是application.name+IP,并且長度為36,否則alpha-server事務持久化會報錯
以上兩個屬性配置為必填,因為alpha-server會依據application.name去查找對應的Omega,其他應用配置自行添加,address可根據alpha-server中的配置實際添加
至此,環(huán)境準備已經完畢,下面開始進行應用代碼編寫。
3.2.2 saga模式代碼編寫
在本次案例中,我們以一個下單流程來講解saga模式下代碼是如何編寫的。下單流程包括:點擊下單、查詢庫存、支付、更新庫存;訂單應用作為起始服務,調用庫存應用和產品應用,這兩個應用對應的服務作為參與服務(子事務),在訂單應用下單,訂單應用使用rest template向產品應用發(fā)起調用校驗產品庫存,然后訂單應用向庫存應用發(fā)起支付請求(子事務1),支付成功后訂單應用再向庫存應用發(fā)起請求更新庫存(子事務2)。
1. @SagaStart
首先需要在應用代碼中描述出saga事務的邊界,作為分布式事務的起始點,因此我們需要在訂單應用中的createOrder()方法上添加該注解@SagaStart:
2. @ Compensable
支付對應補償方法:
更新庫存:
更新庫存補償方法:
*注意:實現(xiàn)的服務和補償方法必須滿足冪等的要求
*注意:默認情況下,超時需要顯示聲明
*注意:若全局事務起點與子事務重合,需同時聲明@SagaStart和@Compensable注解
*注意:補償方法的入參必須與try方法入參一致,否則啟動時會報錯(alpha-server找不到補償方法)
3.2.3 tcc模式代碼編寫
下面我們會以刪除庫存流程來講解tcc模式是如何編寫代碼的。刪除庫存流程:由產品應用發(fā)起(分布式事務起始),調用庫存應用刪除對應產品的庫存信息(tcc子事務)。
本次調用使用的是feign的方式,因此需要在產品應用中的pom文件添加相應的依賴:
1. @TccStart
我們以產品應用中的delete方法作為分布式事務起始點,因此在該方法上添加注解@TccStart:
2. @ Participate
在子事務所處的方法上添加該注解,并通過confirmMethod 以及cancelMethod屬性定義相關確認以及取消方法名。這里需要注意的是這里提到的confirm,cancel方法的參數(shù)必須和try方法的相同。
Cancel邏輯:
*注意:confirm和cancel方法的入參必須和try方法一致
*注意:目前tcc模式還不支持timeout
3.2.4事件信息獲取
默認情況下,8080端口用來處理Omega處發(fā)起的grpc請求,用來做事務上下文等操作;而8090端口則用于處理查詢alpha處的事件信息。
1. saga-事件信息查詢api
統(tǒng)計所有事件狀態(tài):
http://${alpha-server.address:port}/saga/stats
統(tǒng)計最近事件狀態(tài):
http://${alpha-server.address:port}/saga/recent
根據事件狀態(tài)查詢事件列表:
http://${alpha-server.address:port}/saga/transactions
根據服務名稱查詢對應的分布式事件列表:
http://${alpha-server.address:port}/saga/findTransactions
2. tcc-事件信息查詢api
Tcc目前沒有提供正式的查詢接口。但是有測試接口,在AlphaTccEventController中,可自行根據測試接口修改源碼,重新編譯即可。
目前alpha-server提供的事件查詢api不多,若有其他需求,用戶可自行編寫接口對數(shù)據庫進行查詢。
本文所有觀點都出自個人見解,疏漏、錯誤之處在所難免,歡迎大家指正,希望能夠與大家一起交流和進步。
[1]引用自:
http://servicecomb.apache.org/cn/docs/distributed-transaction-of-services-1/
[2]引用自:
http://servicecomb.apache.org/cn/docs/distributed-transaction-of-services-1/
精選提問:
問1:TCC實現(xiàn)的是強一致事務么?
問2:全局事務起點與子事務重合這個怎么理解?
問3:cancel操作是怎么做到的?是通過undo log做的,還是通過補償語句呢?
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。