seata-golang 接入指南 AT 模式接入 TCC 模式接入 總結陳述

seata-golang 是一個分佈式事務框架，實現了 AT 模式和 TCC 模式，AT 模式相較 TCC 模式對代碼的入侵性更小、需要開發的接口更少；但 AT 模式對事務操作的數據持有全局鎖，從這點來說，TCC 模式性能更好。

seata 的 AT 模式將全局鎖放在 transaction coordinator 也就是事務協調器上，依賴於具體鎖接口的存儲實現方式可以是 file/db/redis 等，而不是數據庫鎖，每個分支事務提交時立即釋放數據庫鎖，這樣對數據庫的壓力也就減小了，變相得提升了數據庫的性能。seata AT 模式和 TCC 模式的原理見：[Seata 是什麼？]

下面以 seats-golang samples 爲例，就 AT 模式和 TCC 模式如何接入到業務中做一個說明。

AT 模式接入

在 samples/at 目錄下，有三個微服務：product_svc、order_svc、aggregation_svc。

• product_svc 負責創建訂單時扣減庫存。
• order_svc 負責創建訂單時寫入訂單主表和訂單明細表。
• aggregation_svc 通過 http 請求調用 order_svc 和 product _svc 的接口。

1. 全局事務代理

熟悉 seata java 框架的都知道，seata java 框架通過掃描 @GlobalTransactional 註解，動態生成 AOP 切面，代理被 @GlobalTransactional 標記的方法，實現全局事務的開啓、提交或者回滾。

不同於作爲解釋型語言的 Java，Go 是一種編譯型語言，所以 seata-golang 使用了反射技術實現動態代理功能，被代理的對象需要實現 GlobalTransactionProxyService 接口。

type GlobalTransactionProxyService interface {
    GetProxyService() interface{}
    GetMethodTransactionInfo(methodName string) *TransactionInfo
}

aggregation_svc 中的 Svc struct 有一個方法 CreateSo，該方法通過對 order_svc 和 product_svc 的調用實現了創建訂單和扣減庫存。seata-golang 要代理該 *Svc 對象，需要創建一個代理對象，被代理的方法要在代理對象中作爲一個空方法成員，等待 seata-golang 去動態實現。

type ProxyService struct {
    *Svc
    CreateSo func(ctx context.Context, rollback bool) error
}

代理對象 ProxyService 通過組合方式內置被代理對象 Svc，在開發者調用 tm.Implement(svc.ProxySvc) 方法後，seata-golang 會通過 Svc 實現<typo id="typo-1374" data-origin="的" ignoretag="true">的</typo> GlobalTransactionProxyService 接口獲取動態創建 CreateSo 方法所需要的事務信息，然後根據這些事務信息去動態創建 CreateSo 方法：開啓事務 -> 執行被代理 *Svc 對象的 CreateSo 方法邏輯 -> 根據被代理的 CreateSo 方法的返回錯誤信息決定提交還是回滾。

2. 傳遞全局事務 ID

可以通過如下三種方式傳遞全局事務 ID。

1）Http

在 aggregation_svc 這個服務裏，Seata-golang 通過 request header （req.Header.Set("XID", rootContext.GetXID())）將 XID （全局事務 ID）傳遞到了 order_svc 和 product_svc，order_svc 和 product_svc 則從 Request Header 取出 XID （c.Request.Header.Get("XID")）用於分支事務處理。

2）Dubbo

如果使用 dubbo 協議 rpc 通信，則需要把 XID 注入到 attachment 中傳遞到下游。

如果使用 dubbo-go 框架，dubbo-go 會從 context 中讀取 attachment 將其序列化傳遞給服務端。可以採用如下的方式，將 XID 傳遞出去：

context.WithValue(ctx, "attachment", map[string]string{
        "XID": rootContext.GetXID(),
}

dubbo-go 服務端則從 attachment 中取出 XID，再注入到 context 中，分支事務的業務方法則可以從 context 中獲取 XID 用於分支事務處理。

// SeataFilter ...
type SeataFilter struct {
}

// Invoke ...
func (sf *SeataFilter) Invoke(ctx context.Context, invoker protocol.Invoker, invocation protocol.Invocation) protocol.Result {
    xid := invocation.AttachmentsByKey("XID", "")
    if xid != "" {
        return invoker.Invoke(context.WithValue(ctx, "XID", xid), invocation)
    }
    return invoker.Invoke(ctx, invocation)
}

// OnResponse ...
func (sf *SeataFilter) OnResponse(ctx context.Context, result protocol.Result, invoker protocol.Invoker, invocation protocol.Invocation) protocol.Result {
    return result
}

// GetSeataFilter ...
func getSeataFilter() filter.Filter {
    return &SeataFilter{}
}

上面的 filter 通過 extension.SetFilter("SEATA", getSeataFilter) 方法可將其注入到 dubbo-go 的 filter 鏈。

3）GRPC

grpc 可通過 metadata 傳遞 XID。

客戶端首先將 XID 放入 md := metadata.Pairs("XID", rootContext.GetXID())，再將 metadata 傳入 context：metadata.NewOutgoingContext(context.Background(), md)。

服務端則通過 md, ok := metadata.FromIncomingContext(ctx) 獲取到 metadata，再從中取出 XID。

3. 事務分支處理

AT 模式除了要對發起全局事務的方法做代理，還需要對數據源做代理。

seata 通過代理數據源，對 sql 語句進行解析，來獲取修改數據的修改前和修改後的數據，供 transaction coordinator 回滾時使用。對數據源的代理，只需要將你創建的 sql driver 實例注入到 seata-golang 的 db 操作對象中：

db, err := exec.NewDB(config.GetATConfig(), {你的 sql driver 實例})

如果你使用了 xorm 或者 gorm，則可從 xorm 對象或者 gorm 對象中取出 sql driver 實例，用上面的方法構造出 seata-golang 的 db 操作對象。這意味着你可以同時使用 orm 框架和 seata-golang 框架，當你的操作需要用到事務時，用 seata-golang 的 db 操作對象去執行 sql 語句。

通過上一節的介紹，開發者已經可以在服務端拿到上游傳遞過來的 XID 了。爲了將分支事務加入到全局事務組中，開發者需要使用獲取的 XID 構造一個 RootContext：

rootContext := &context.RootContext{Context: ctx}
rootContext.Bind("{上游獲取到的 XID}")

開啓分支事務時，調用流程如下：

• 調用 seata-golang 的 db 操作對象的 Begin 方法獲取分支事務對象 tx, err := dao.Begin(ctx)。
• 執行 sql 語句則使用該分支事務對象 tx 的 Exec 方法 func (tx *Tx) Exec(query string, args ...interface{}) (sql.Result, error)。
• 執行完 sql 操作邏輯後，可根據返回的結果，調用 tx.Commit() 或 tx.Rollback() 來提交或回滾分支操作。

最後，整個分支事務是否成功提交，執行成功還是失敗需要返回結果給調用方，也就是全局事務的發起方，transaction manager 會根據返回的結果決定是否提交或回滾整個全局事務。

TCC 模式接入

TCC 模式相較 AT 模式，約束會多一些。TCC 模式首先要求開發者實現 TccService 接口，還要求接口三個方法的參數都封裝到一個 BusinessActionContext 裏。

開發者調用 Try 方法，seata-golang 框架調用 Confirm/Cancel 方法。框架根據所有分支事務 Try 方法是否都執行成功，來決定發起全局提交或回滾。全局提交則由框架自動調用每個事務分支的 Confirm 方法，全局回滾則調用加入事務組的所有事務分支的 Cancel 方法。

type TccService interface {
    Try(ctx *context.BusinessActionContext) (bool, error)
    Confirm(ctx *context.BusinessActionContext) bool
    Cancel(ctx *context.BusinessActionContext) bool
}

在調用 Try 方法之前，事務分支要加入事務組，且需要把 Try 方法執行的上下文即 BusinessActionContext 存到 Transaction coordinator，這樣框架在提交或回滾時，才能把 BusinessActionContext 參數傳遞給 confirm、cancel 方法，這部分邏輯仍然通過代理實現。所以開發者還需要創建一個代理類，並實現接口 TccProxyService：

type TccProxyService interface {
    GetTccService() TccService
}

通過調用 tcc.ImplementTCC({代理類實例}) 方法，框架會爲代理類實現上述邏輯。開發者可在 samples/tcc 目錄查看 tcc 模式的示例。

總結陳述

除了項目結構目錄內的 samples，還有一個 dubbo-go 的例子 dubbo-go-seata。對於上文講述的接入方法，還希望讀者結合代碼多多理解，<typo id="typo-5022" data-origin="融匯貫通" ignoretag="true">融匯貫通</typo>。

當前 seata-golang 與最新的 seata java 1.4 版本協議上完全打通，如果有公司在技術棧上既有使用 java 語言也有使用 golang 語言，可接入 seata 框架來解決您的分佈式事務後顧之憂。

作者 | 劉曉敏

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。