作者:赵禹光,Seata Contributor,SkyWalking PMC
正如所看到的文章题目,就在此时,Seata与SkyWalking两个生态融合,取得了阶段性成果。下面就结合文章内容,给你徐徐道来。
事情的起因是这样的,Seata、SkyWalking分别是分布式事务领域、一站式APM领域的的佼佼者,这一点通过Github Star排名就可以知道,也就不再赘述了。所以早在2019年,Seata的用户就提出了使用SkyWalking观测的诉求。
Seata融入SkyWalking监控后,就有了APM特性,用户在定位Seata分布式事务的问题时,可以通过分布式链路、机器指标、日志内容等多个维度进行问题剖析,实现定位问题的提效。
那结合这个诉求,两个社区感兴趣的同学就开始展开了初步讨论和实践,但是由于当时Seata的传输协议中,没有类似于HTTP Header的面向传输的消息头部
,所以实现的第一版虽然实现了监控观测,但是兼容性非常不友好,这在解决分布式事务的监控中,显然是有欠缺的。故此,我们开启了二番讨论,结论是兼容性的前置条件是必须的,所以,Seata要实现传输协议升级,就此Seata将此事放在了RoadMap中。SkyWalking社区这边也暂时搁置了这件事。
时光荏苒,转眼1年多就过去了,Seata社区在过程中已经完成了传输协议的升级,那我们就重启此事。
背景已经叙述完了,由于时间有些久,可能大家对两个生态融合之后带来的效果,也不是很清晰了,这里就我的个人的理解,介绍下两个生态融合后,给用户带来的益处:
Seata的性能可被更好的观测:
我看到很多Seata的分享的时候都有用户提问,Seata性能消耗数据,因为分布式事务的性能消耗与场景关系非常大,所以用户通过SkyWalking可以更简单的观测自己的场景,自己给自己答案。
分布式事务执行过程有痕迹
在AT模式下,Seata通过面向传输的消息头部,传递全局事务XID,全局事务执行完成后,每个在DB中的执行过程都会被清理掉,这在回溯执行过程的时候非常不友好,这些海量数据Seata可不会存储,这严重增加分布式事务关联数据库表的空间,带来不必要的性能消耗。所以两个生态融合后,SkyWalking相关的数据库监控,就可以记录这些执行过程的海量数据。
定位问题的提效
在日志中打印XID的同时打印TraceId,当出现问题想回溯XID相关联的全局链路时,在SkyWalking的展示端输入TraceId即可,通过Seata整体监控融入SkyWalking,不仅拥有全链路领域的监控,还在仪表盘、拓扑图、在线剖析和报警都得到了监控。
入门Seata提高一个维度
分布式事务一直被炒得很热,但真正能在市场上落地的也只有Seata,所以Seata并没有开源的学习范本,所以快速带领大家入门的资料也比较少。而且Seata有3个角色、4中经典模式,可以多种组合,综上所诉,不由得让使用者云里雾里,两个生态融合后,用户可以清晰从上帝(监控)知道Seata的执行过程,进而透析工作原理。
下面就官方AT模式的Demo,展示下接入后的APM特性。
用户请求交易服务
交易服务锁定库存
交易服务创建账单
账单服务进行扣款
官网 SkyWalking APM: http://seata.io/zh-cn/docs/user/apm/skywalking.html
社区讨论群
常用链接
Seata: https://github.com/seata/seata
Samples: https://github.com/seata/seata-samples
Release: https://github.com/seata/seata/releases
官网: https://seata.io
投稿
欢迎大家将 Seata 相关的实践文章投稿至:slievrly@gmail.com