最近做了一些分布式链路追踪有关的东西,写篇文章来梳理一下思路,或许可以帮到想入门的同学。下面我将从原理到demo为大家一一进行讲解,欢迎评论区交流~。
讲解分布式链路追踪出现的原因,分析dapper论文中给出的分布式链路追踪系统dapper的实现方式
Dapper论文翻译版:https://bigbully.github.io/Dapper-translation/
互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要一些可以帮助理解系统行为、用于分析性能问题、追踪请求传递过程的工具。
Dapper—Google生产环境下的分布式跟踪系统,其运作两年之后,Google发布了基于Dapper的论文,重点介绍Dapper的设计思想,为后续分布式链路追踪相关分析工具的产生提供理论支持。
接下来先介绍Dapper论文中是如何实现分布式链路追踪,并提炼核心概念—span。
左图展现的是一个和5台服务器相关的一个服务,包括:前端(A),两个中间层(B和C),以及两个后端(D和E)。当一个用户(这个用例的发起人)发起一个请求时,首先到达前端,然后发送两个RPC到服务器B和C。B会马上做出反应,但是C需要和后端的D和E交互之后再返还给A,由A来响应最初的请求。对于这样一个请求,简单实用的分布式跟踪的实现,就是为服务器上每一次你发送和接收动作来收集跟踪标识符(message identifiers)和时间戳(timestamped events)。
为了将所有记录条目与一个给定的发起者(例如,图中的RequestX)关联上并记录所有信息,Dapper倾向于应用程序或中间件明确地标记一个全局ID,从而连接每一条记录和发起者的请求,该方案最主要的缺点是,很明显,需要代码植入。但dapper开发者认为,可以把代码植入限制在一个很小的通用组件库中,从而实现了监测系统的应用对开发人员是有效地透明。
从形式上看,Dapper跟踪模型使用的树形结构,且Dapper中称追踪树上的每一个节点为span,span代表分布式链路追踪中的节点。
在Dapper跟踪树结构中,树节点是整个架构的基本单元,而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。
左图中说明了span在一个大的跟踪过程中是什么样的。Dapper记录了span名称,以及每个span的ID和父ID,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id(在图中未示出)。在一个典型的Dapper跟踪中,我们希望为每一个RPC对应到一个单一的span上,而且每一个额外的组件层都对应一个跟踪树型结构的层级。
左图给出了一个更详细的典型的Dapper跟踪span的记录点的视图。图中这种某个span表述了两个“Helper.Call”的RPC(分别为server端和client端)。span的开始时间和结束时间,以及任何RPC的时间信息都通过Dapper在RPC组件库的植入记录下来。如果应用程序开发者选择在跟踪中增加他们自己的注释(如图中“foo”的注释)(业务数据),这些信息也会和其他span信息一样记录下来。
Annotation:上述植入点足够推导出复杂的分布式系统的跟踪细节,使得Dapper的核心功能在不改动Google应用的情况下可用。然而,Dapper还允许应用程序开发人员在Dapper跟踪的过程中添加额外的信息,以监控更高级别的系统行为,或帮助调试问题。我们允许用户通过一个简单的API定义带时间戳的Annotation,这些Annotation可以添加任意内容。
Dapper的跟踪记录和收集管道的过程分为三个阶段(参见左图)。首先,span数据写入(1)本地日志文件中。然后Dapper的守护进程和收集组件把这些数据从生产环境的主机中拉出来(2),最终写到(3)Dapper的Bigtable仓库中。一次跟踪被设计成Bigtable中的一行,每一列相当于一个span。Bigtable的支持稀疏表格布局正适合这种情况,因为每一次跟踪可以有任意多个span。
Zipkin是Twitter开源出来的一个Trace系统组件,通过将前两张图虚线框中的zipkin的结构与第三张图的dapper结构进行对比,明显可以印证:zipkin的实现中就参考了Google Dapper。如图1,每个instrumented节点会将链路追踪信息发送给zipkin的collector,然后由zipkin存储数据,提供ui显示链路监测情况。
注意:每个需要链路追踪的节点为span,每个span的信息都是独立发送给collector的(因为span中有统一的全局traceId,以及父spanId,因此,跟踪树是在等某次trace相关的所有span都发送到zipkin之后,由zipkin构件成树结构提供ui展示的)
摘自Jaeger官方文档:Jaeger, inspired by Dapper and OpenZipkin, is a distributed tracing system released as open source by Uber Technologies
Jaeger与Zipkin一样可以作为分布式链路追踪组件,但是后出现,使用Go语言开发,二者的技术选择取决于具体的项目需要,这里按下不表,但需要明确的是二者都是基于Dapper的分布式链路追踪组件,铭记下方左侧的Dapper结构图
显然无论是Dapper、Zipkin、Jaeger在工作时都是在一个端口接收Collector发送的span数据,然后构建跟踪树并展示,必然需要被监听服务主动发送span数据,而发送span数据到指定追踪组件的行为必然需要相应api支持。
OpenCensus目前提供了一些语言的库,允许你捕捉、操作和导出指标和分布式跟踪到你选择的后端。因此关键在于如何构建span(使span之间建立上下游联系),以及如何将span发送到指定后端,接下来细谈
创建span的方法OpenCensus api提供了两个,参数中:Context.Context是一个接口类型,用于存放trace数据,用于在内存中层层传递,第二个方法多了一个名为parent的SpanContext类型,表示基于给定父span(来自外部request)创建一个span
这里如果在调用startSpanInternal()方法的时候hasParent为false(为nil)则会自动生成随机的traceId,显然不是我们想要的,而上面说明startSpan()方法是从ctx中获取parent,而startSpanWithRemoteParent()从形参中获取parent,因此我们使用第二方法用于在获取前端的traceId之后创建我们整个trace链路的第一个span,之后将span信息存入ctx于内存中传递,此后都调用startSpan()方法创建以后的span
刚刚讲解了span如何创建,并且也说明span在golang中将存放于context.Context接口描述的类型中,那么span在 一个微服务节点上,以及微服务节点之间的传递是如何实现的呢?下面引用一段字节运维团队的文章节选:
换言之span是追踪树的最小单位,一个微服务节点上可以随服务处理流程提取多个span(利用context于内存传递Span信息),而跨微服务节点的context传递将由微服务框架实现,比如grpc在pb文件生成后,调用的方法中就自带context这个参数选项,只需要传入即可在微服务间传递context
注意trace最初的traceId是通过一个http request请求放在http header中传递到后端http server的,在此之后都将使用微服务框架去自动 传递span(context)信息
Exporter将trace信息(span)发送到任何有能力消费它们的后端。Exporter本身可以改变而不需要改变你的客户端代码。这就是OpenCensus真正与供应商无关的原因。只需收集一次trace(span)信息,就可以同时导出到不同的后端。
整体的使用流程 :1. 注册Exporter(相当于声明要发送给哪个后端zipkin、jaeger等);2. 使用opencensus提供api构建span;3. 发送span(发送过程就会遍历所有注册的Exporter,将构建的span挨个发送到每个exporter指向的后端)。
其中2、3两个步骤的代码不用变动,每次如果需要添加或者置换目标后端,只需要修改Exporter即可。
项目结构
目录结构
•main函数
•sendHttp
•callGrpcServer
•Zipkin
•Jaeger