为什么要做调用链监控
随着互联网技术的发展,微服务架构已经成为每个互联网公司的标配。伴随着服务粒度的细化,服务应用数量极速上涨。与此同时,服务与服务之间的调用也变得错综复杂。伴随着调用链路的复杂化,我们也会碰到各种难题,例如:
加班加点的做了功能,上线发布后,如何确认服务一切正常?客户端收到了错误的提示,但是到底是哪个服务抛出的这个错误?程序性能有问题,但是具体是哪个环节成了性能的瓶颈?接口响应很慢,到底是网络问题还是代码问题?服务调用链路长,每个环节都可能是一个出问题的风险点?做技术优化,如何丈量我们的服务质量呢?如果面对这些问题,你一脸茫然。那么我想说,是时候将调用链监控引入你的项目了。
调用链监控原理
说起调用链监控,不得不提Google在年发表的Dapper论文。它可以算是调用链的鼻祖了,在该论文发布后,大量的调用链监控产品依据该论文阐述的原理进行了实现。让我们来一起看看调用链监控中的几个重要概念:
Trace一次分布式调用的链路Span一次本地或者远程方法的调用Annotation附加在Span上的日志信息Sampling采样率(客户端按照比例将埋点信息提交给服务端)上面四个术语为调用链中的核心概念,这么说还是有点抽象,我们用图来具体展示一下:
如上我们图示了一次分布式调用的全过程,图中有三个分布式服务ServiceA、ServiceB、ServiceB,每个方法的调用链信息中涉及到如下三个标记:
tid:tid即为traceid,代表该次调用的唯一ID,在一次分布式调用中,所有方法的tid都相同。如上图中的Tid:1。sid:sid即为spanid,代表的是一个本地/远程方法调用的唯一ID。如上图中每个绿色框代表的是一次方法调用,每次调用都有自己的sid。pid:pid其实也是一个spanid,但是它代表的是当前方法的父级方法的spanid。如上图中第一方法调用由客户端发起,是没有pid的。在上图中所示的调用链中总共包含了7个方法(本地/远程)调用,依次如下:
用客户端发起调用请求后,首先请求进入到A服务。此时会产生调用链信息tid:1,sid:1。接着发生了一次远程调用Tid:1,pid:1,sid:2,pid为1代表父级方法的spanid为1即为sid=1的方法,同理本次redis远程调用的spanid为2。Redis远程调用结束后发生了对ServiceB的远程调用Tid:1,pid:1,sid:3,与方法2类似,不同的是本次方法调用的spanid为3。在ServiceB中,首先是一个本地方法调用Tid:1,pid:3,sid:4,从pid=3可以得出它的父级方法正是方法3。接着发生了一次对Mysql的远程调用Tid:1,pid:4,sid:5,pid=4代表父级方法为方法4,spanid为5。Mysql远程调用结束后,ServiceB对ServiceC进行了一次远程调用Tid:1,pid:4,sid:6,同样通过pid和tid我们可以将本次方法调用与整个调用链关联起来。最后是ServiceC的一个本地方法调用Tid:1,pid:6,sid:7,至此整个调用链到达最远端,这是本次分布式调用链最深处的一个方法。如上我们对GoogleDapper论文中几个核心概念进行了讲解,相信你已经大致了解了调用链的实现原理。如果觉得还不够过瘾的同学可以通过链接继续阅读,如果你的英语不是很好,也可参考GitHub上的这份中文翻译版本Dapper,大规模分布式系统的跟踪系统。说到这里,我想问问大家,市场上的调用链产品都是基于GoogleDapper来实现的吗?其实不是的,接下来我们一起来看看调用链的发展历史。
调用链监控的前世今生
年GoogleDapper问世,其实早在年eBay已经有了自己的调用链监控产品,它叫CAL(CentralApplicationLogging)。当时eBay中国研发中心的一位资深工程师作为CAL的核心维护人员,对CAL的方方面面都非常熟悉。
后来他去了美团点评,在年的时候,他带领团队研发出了CAT(CentralApplicationTracing),CAT继承了CAL的优点,也增加了很多自己的特色功能,并且它已经在GitHub开源,也在美团点评经受了大流量,高并发应用的检验,是目前业界应用比较广泛和成熟的生产级别调用链监控产品。
随后由于GoogleDapper论文的发布,也伴随着互联网产品的迅速发展,各个大厂依据Dapper纷纷实现了自己的调用链监控产品。在年就诞生了3款产品,携程的CTrace,韩国公司Naver的PinPoint,Twitter的Zipkin。
随后在年,阿里研发了Eagleye,京东研发了Hydra。接着诞生了调用链监控的标准规范OpenTracing,面对各大厂的调用链监控产品,他们使用不兼容的API来实现各自的应用需求。尽管这些分布式追踪系统有着相似的API语法,但各种语言的开发人员依然很难将他们各自的系统(使用不同的语言和技术)和特定的分布式追踪系统进行整合,OpenTracing希望可以解决这个问题,因此颁布了这套标准。于此也诞生了Uber的Jaeger,国人吴晟做的SkyWalking(现在已经捐赠给了Apache)均实现了OpenTracing标准,对OpenTracing感兴趣的可以去