随着业务的快速发展、业务复杂度越来越高,微服务作为最佳解决方案之一,它解耦服务,降低复杂度,增加可维护性的同时,也带来一部分新问题。
当我们需要跨服务保证数据一致性时,原先的数据库事务力不从心,无法将跨库、跨服务的多个操作放在一个事务中。这样的应用场景非常多,我们可以列举出很多:
面对这些本地事务无法解决的场景,我们需要分布式事务的解决方案,保证跨服务、跨数据库更新数据的一致性。
go-zero 与 dtm 强强联合,推出了在 go-zero 中无缝接入 dtm 的极简方案,让分布式事务的使用从未如此简单。
需要框架源码的朋友可以看我个人简介联系我。推荐分布式
我们来看一个可运行的例子,然后再看如何自己开发完成一个完整的分布式事务
下面以 etcd 作为注册服务中心,可以按照如下步骤运行一个 go-zero 的示例:
当你在 trans 的日志中看到
那就是事务正常完成了
参考 的代码
整个开发接入的过程很少,前面的注释已经很清晰,就不再赘述了。
在开发接入的过程中,去找
*.pb.go 的文件中的
grpc 访问的方法路径时候,一定要找
invoke 的路径
在 go-zero 使用 dtm 的分布式事务时,许多的调用是从 dtm 服务器发起的,例如 TCC 的
Confirm/Cancel,
SAGA/MSG 的所有调用。
dtm无需知道组成分布式事务的相关业务api的强类型,它是动态的调用这些api。
grpc的调用,可以类比于HTTP的POST,其中:
c.BuildTarget() 产生的 target 类似于 URL 中的 Host/trans.TransSvc/TransOut 相当于 URL 中的 Path&busi.BusiReq{Amount: 30, UserId: 1} 相当于 Post 中 Bodypb.Response 相当于 HTTP 请求的响应通过下面这部分代码,dtm 就拿到了完整信息,就能够发起完整的调用了
Add(busiServer+"/trans.TransSvc/TransOut", &busi.BusiReq{Amount: 30, UserId: 1})
go-zero 的微服务还有非
etcd 的其他方式,我们依次说明他们的接入方式
对于直连这种方式,您只需要在上面
dtm 的
etcd 配置基础上,将
Target 设置为空字符串即可。
直连的情况,不需要将
dtm 注册到注册中心。
对于
K8S 这种方式,您只需要在上面
dtm 的
etcd 配置基础上,将
Target 设置为空字符串即可。
在
K8S 中,将服务注册到
K8S 中,是由
deployment.yaml 完成的,应用内部,不需要进行注册。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70006413/viewspace-2849860/ ,如需转载,请注明出处,否则将追究法律责任。