3．分布式事務實戰

如何在項目中運用servicecomb-pack，需要進行以下步驟：

alpha-server配置

編譯alpha-server

1．環境準備

? 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

在執行玩命令之后，可在alpha/alpha-server/target/saga/alpha-server-${version}-exec.jar中找到alpha-server的可執行jar包

5．初始化數據庫

可在alpha\alpha-server\src\main\resources目錄下找到schema-mysql.sql和schema-postgresql.sql兩個sql文件，可自行根據所選數據庫進行初始化即可。

6．啟動alpha-server

注意：請在執行命令前將${saga_version}和${host_address}更改為實際值

至此，alpha-server全局事務管理器已經啟動成功。

替換postgresql為mysql

目前alpha-server支持pg和mysql兩種數據庫，默認為pg，如需改為mysql，需要進行如下操作：

1．安裝并運行mysql

2．修改pom文件，添加依賴

alpha-server/pom.xml，添加mysql依賴

3．修改配置文件

找到alpha-server/src/main/resource/application.yaml，修改datasource信息為本地信息即可

注意：${username}，${password}，${host_address}，${port}，${database_name}需替換為實際值

4．本地構建alpha-server（和上面步驟一致）

5．啟動alpha-server

注意：請在執行命令前將${saga_version}和${host_address}更改為實際值

自此，alpha-server端已經配置編譯完成

Omega配置

配置完alpha-server之后，就相當于分布式事務的協調器已經配置完成，剩下的就是omega的配置，也就是在實際開發中如何運用servicecomb-pack去處理分布式事務。本次講解會結合一個實際案例：購物系統中的下單流程和刪除產品流程來分別講解saga模式和tcc模式如何使用的。

環境準備

本次案例：購物系統是采用分布式微服務架構，整體分為三個微服務應用：orderManage訂單管理應用、productManage產品管理應用、stockManage庫存管理應用

1．添加依賴

分別在三個應用的pom文件中添加Omega所需的依賴：

注意：請將${servicecomb-pack.version}更改為實際的版本號（推薦版本為0.4.0）

注意：如需做集群，omega-spring-cloud-consul-starter和omega-spring-cloud-eureka-starter二選一，視項目的注冊中心而定。

2．修改配置文件

分別在三個應用的application.yml配置文件中添加alpha-server配置，具體配置如下：

注意：application.name一定不要過長，因為instanceId的格式是application.name+IP，并且長度為36，否則alpha-server事務持久化會報錯

以上兩個屬性配置為必填，因為alpha-server會依據application.name去查找對應的Omega，其他應用配置自行添加，address可根據alpha-server中的配置實際添加

自此，環境準備已經完畢，下面開始進行應用代碼編寫

saga模式代碼編寫

在本次案例中，我們以一個下單流程來講解saga模式下代碼是如何編寫的。下單流程包括：點擊下單、查詢庫存、支付、更新庫存；訂單應用作為起始服務，調用庫存應用和產品應用，這兩個應用對應的服務作為參與服務（子事務），在訂單應用下單，訂單應用使用rest template向產品應用發起調用校驗產品庫存，然后訂單應用向庫存應用發起支付請求（子事務1），支付成功后訂單應用再向庫存應用發起請求更新庫存（子事務2）。

1．@SagaStart

首先需要在應用代碼中描述出saga事務的邊界，作為分布式事務的起始點，因此我們需要在訂單應用中的createOrder（）方法上添加該注解@SagaStart：

2．@ Compensable

@Compensable所代表的是本地子事務，因此需要在創建支付和更新庫存的方法上添加此注解來標注該邏輯為子事務，并且在Compensable的compensationMethod屬性中描述補償方法。注意補償方法和本地事務方法的參數必須一致，否則Omega在系統啟動進行參數檢查的時候報找不到恢復方法的錯誤：

支付：

支付對應補償方法：

更新庫存：

更新庫存補償方法：

注意：實現的服務和補償方法必須滿足冪等的要求

注意：默認情況下，超時需要顯示聲明

注意：若全局事務起點與子事務重合，需同時聲明@SagaStart和@Compensable注解

注意：補償方法的入參必須與try方法入參一致，否則啟動時會報錯（alpha-server找不到補償方法）

tcc模式代碼編寫

下面我們會以刪除庫存流程來講解tcc模式是如何編寫代碼的。刪除庫存流程：由產品應用發起（分布式事務起始），調用庫存應用刪除對應產品的庫存信息（tcc子事務）.

本次調用使用的是feign的方式，因此需要在產品應用中的pom文件添加相應的依賴：

1．@TccStart

我們以產品應用中的delete方法作為分布式事務起始點，因此在該方法上添加注解@TccStart:

2．@ Participate

在子事務所處的方法上添加該注解，并通過confirmMethod以及cancelMethod屬性定義相關確認以及取消方法名。這里需要注意的是這里提到的confirm，cancel方法的參數必須和try方法的相同。

Confirm邏輯：

Cancel邏輯：

注意：confirm和cancel方法的入參必須和try方法一致

目前tcc模式還不支持timeout

事件信息獲取

默認情況下，8080端口用來處理Omega處發起的grpc請求，用來做事務上下文等操作；而8090端口則用于處理查詢alpha處的事件信息。

1．saga-事件信息查詢api

http://${alpha-server.address:port}/saga/stats：統計所有事件狀態

http://${alpha-server.address:port}/saga/recent：統計最近事件狀態

http://${alpha-server.address:port}/saga/transactions：根據事件狀態查詢事件列表

http://${alpha-server.address:port}/saga/findTransactions：根據服務名稱查詢對應的分布式事件列表

2．tcc-事件信息查詢api

Tcc目前沒有提供正式的查詢接口。但是有測試接口，在AlphaTccEventController中，可自行根據測試接口修改源碼，重新編譯即可

目前alpha-server提供的事件查詢api不多，若有其他需求，用戶可自行編寫接口對數據庫進行查詢。

以上就是分布式事務實戰微課堂的整個內容，本次文章是基于華為servicecomb-pack來總結了一些使用心得和實際項目經驗，希望能對正在分布式事務上摸索的同仁們提供一些幫忙。本文章所有觀點都出自個人見解，疏漏、錯誤之處在所難免，歡迎大家指正，希望能夠與大家一起交流和進步。

[i] 引用自：http://servicecomb.apache.org/cn/docs/distributed-transaction-of-services-1/

[ii] 引用自：http://servicecomb.apache.org/cn/docs/distributed-transaction-of-services-1/

分布式及高可用元數據采集原理

一文讀懂微服務監控之分布式追蹤

分布式架構中數據一致性常見的幾個問題

關于作者：花無缺，普元信息Java開發工程師，擅長微服務開發、網關拓展開發；曾參與普元EOS MS 5.0微服務產品開發。愛鉆研的"技術控"，微服務專家、分布式事務解決方案專家。