作者 | 刘晓敏
起源 | 阿里巴巴云原生公众号

seata-golang 是一个分布式事务框架，实现了 AT 模式和 TCC 模式，AT 模式相较 TCC 模式对代码的入侵性更小、须要开发的接口更少；但 AT 模式对事务操作的数据持有全局锁，从这点来说，TCC 模式性能更好。

seata 的 AT 模式将全局锁放在 transaction coordinator 也就是事务协调器上，依赖于具体锁接口的存储实现形式能够是 file/db/redis 等，而不是数据库锁，每个分支事务提交时立刻开释数据库锁，这样对数据库的压力也就减小了，变相得晋升了数据库的性能。seata AT 模式和 TCC 模式的原理见：[[Seata 是什么？]](http://seata.io/zh-cn/docs/ov…

上面以 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 实现的 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。对于上文讲述的接入办法，还心愿读者联合代码多多了解，融汇贯通。

以后 seata-golang 与最新的 seata java 1.4 版本协定上齐全买通，如果有公司在技术栈上既有应用 java 语言也有应用 golang 语言，可接入 seata 框架来解决您的分布式事务后顾之忧。

如果你有任何疑难，欢送钉钉退出交换群【钉钉群号 33069364】。

参考资料

• seata 官网：https://seata.io
• java 版 seata：https://github.com/seata/seata
• seata-golang 我的项目地址：https://github.com/opentrx/seata-golang
• seata-golang go 夜读 b 站分享：https://www.bilibili.com/video/BV1oz411e72T
• 基于 getty 的 seata-golang 通信模型详解：http://seata.io/zh-cn/blog/seata-golang-communication-mode.html

作者简介

刘晓敏 (GitHubID dk-lockdown)，目前就任于 h3c 成都分公司，善于应用 Java/Go 语言，在云原生和微服务相干技术方向均有涉猎，目前专攻分布式事务。