分布式链路追踪原理详解及SkyWalking、Zipkin介绍

背景：追踪调用链路，监控链路性能，排查链路故障

随着微服务架构的流行，一次请求往往需要涉及到多个服务，需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

单体架构中可以使用 AOP 在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间，使用 AOP 来 catch 住异常也可知道是哪里的调用导致的异常。

a7c6a3fc656311e26c23665d001d403f.png

基本实现原理

一个完整请求链路的追踪ID（traceid）用于查出本次请求调用的所有服务，每一次服务调用的跨度ID（spanid）用来记录调用顺序

ed0d12ec4e9e5780bb29f5560f922b09.png

上游服务parenetid用来记录调用的层级关系

67f2488ee34e506e9e17f86db98beee1.png

调用时间timestamp，把请求发出、接收、处理的时间都记录下来，计算业务处理耗时和网络耗时，然后用可视化界面展示出来每个调用链路，性能，故障

6b62894b4db835b7e5f4b6e604fe00ea.png

97bbd874c258e8860de830389c7116cc.png

还可以记录一些其他信息，比如发起调用服务名称、被调服务名称、返回结果、IP、调用服务的名称等，最后，我们再把相同spanid的信息合成一个大的span块，就完成了一个完整的调用链。

a587384d695d7c18b62ca3c4eab9e9b5.png

SkyWalking的原理及架构设计

节点数据的定时采样，采样后将数据定时上报，将其存储到 ES, MySQL 等持久化层，有了数据自然而然可根据数据做可视化分析。

9540eaab2edad233ad3a6de19ac16d82.png

skywalking的工作机制

skywalking的工作机制，需要三块协同。工作原理图大致如下:

• 一块是skywalking server，负责接收、存储并展示，所以server模块包含一个展示web子模块；
• 第二块是agent，负责代理微服务并收集需要的信息，转发给server；
• 第三块便是微服务本身，需要在启动时指定agent，以便生成代理类。

如何通过Zipkin或SKYwalking实现链路追踪

SkyWalking 核心模块介绍：

SkyWalking采用组件式开发，易于扩展，主要组件作用如下：

1. Skywalking Agent：链路数据采集tracing（调用链数据）和metric（指标）信息并上报，上报通过HTTP或者gRPC方式发送数据到Skywalking Collector

2. Skywalking Collector ： 链路数据收集器，对agent传过来的tracing和metric数据进行整合分析通过Analysis Core模块处理并落入相关的数据存储中，同时会通过Query Core模块进行二次统计和监控告警

3. Storage： Skywalking的存储，支持以ElasticSearch、Mysql、TiDB、H2等主流存储作为存储介质进行数据存储,H2仅作为临时演示单机用。

4. SkyWalking UI： Web可视化平台，用来展示落地的数据，目前官方采纳了RocketBot作为SkyWalking的主UI

怎么自动采集 span 数据

SkyWalking 采用了插件化 + javaagent 的形式来实现了 span 数据的自动采集，这样可以做到对代码的 无侵入性，插件化意味着可插拔，扩展性好

0b41572f0df68557b44e7a8bdf94409f.png

如何跨进程传递 context

我们知道数据一般分为 header 和 body, 就像 http 有 header 和 body, RocketMQ 也有 MessageHeader，Message Body, body 一般放着业务数据，所以不宜在 body 中传递 context，应该在 header 中传递 context，如图示

4493d1c4b42aff74e701b38bc6c5b2c0.png

dubbo 中的 attachment 就相当于 header ,所以我们把 context 放在 attachment 中，这样就解决了 context 的传递问题。

d1796119633d317b31c40b2cfb47c74a.png

小提示：这里的传递 context 流程均是在 dubbo plugin 处理的，业务无感知

traceId 如何保证全局唯一

要保证全局唯一 ，我们可以采用分布式或者本地生成的 ID，使用分布式话需要有一个发号器，每次请求都要先请求一下发号器，会有一次网络调用的开销，所以 SkyWalking 最终采用了本地生成 ID 的方式，它采用了大名鼎鼎的 snowflow 算法，性能很高。

421932ca83eae9bc418bf96192164dfe.png

不过 snowflake 算法有一个众所周知的问题：时间回拨，这个问题可能会导致生成的 id 重复。那么 SkyWalking 是如何解决时间回拨问题的呢。

563d68e3661b782cfbcb0be2096ab97f.png

每生成一个 id，都会记录一下生成 id 的时间(lastTimestamp)，如果发现当前时间比上一次生成 id 的时间(lastTimestamp)还小，那说明发生了时间回拨，此时会生成一个随机数来作为 traceId。

请求量这么多，全部采集会不会影响性能?

如果对每个请求调用都采集，那毫无疑问数据量会非常大，但反过来想一下，是否真的有必要对每个请求都采集呢，其实没有必要，我们可以设置采样频率，只采样部分数据，SkyWalking 默认设置了 3 秒采样 3 次，其余请求不采样,如图示

b671a36afff7451681e34fe35d323fb1.png

这样的采样频率其实足够我们分析组件的性能了，按 3 秒采样 3 次这样的频率来采样数据会有啥问题呢。理想情况下，每个服务调用都在同一个时间点(如下图示)这样的话每次都在同一时间点采样确实没问题。

ba7581e2e90b4651fe402809f8b30362.png

但在生产上，每次服务调用基本不可能都在同一时间点调用，因为期间有网络调用延时等，实际调用情况很可能是下图这样。

e03d1f761c18c22724b56510ce72d7b7.png

这样的话就会导致某些调用在服务 A 上被采样了，在服务 B，C 上不被采样，也就没法分析调用链的性能，那么 SkyWalking 是如何解决的呢。

它是这样解决的：如果上游有携带 Context 过来(说明上游采样了)，则下游强制采集数据。这样可以保证链路完整。

SkyWalking 各模块组件视图简介

Skywalking已经支持从6个可视化维度剖析分布式系统的运行情况。

• 总览视图(Global view)是应用和组件的全局视图，其中包括组件和应用数量，应用的告警波动，慢服务列表以及应用吞吐量；
• 拓扑图(topology view)从应用依赖关系出发，展现整个应用的拓扑关系；
• 应用视图则是从单个应用的角度，展现应用的上下游关系，TopN的服务和服务器，JVM的相关信息以及对应的主机信息。
• 服务视图关注单个服务入口的运行情况以及此服务的上下游依赖关系，依赖度，帮助用户针对单个服务的优化和监控；
• 调用链(trace)展现了调用的单次请求经过的所有埋点以及每个埋点的执行时长；
• 告警视图(alarm)根据配置阈值针对应用、服务器、服务进行实时告警。

1、仪表盘：查看全局服务基本性能指标

仪表盘主要包含Service Dashboard和Database Dashboard

• Service Dashboard：有Global、Service、Endpoint、Instance面板，展示了全局以及服务、端点、实例的详细信息
• Database Dashboard：展示数据库的响应时间、响应时间分布、吞吐量、SLA、慢SQL等详细信息，便于直观展示数据库状态

在这里插入图片描述

在这里插入图片描述

2、拓扑图：展示分布式服务之间调用关系：

SkyWalking能够根据获取的数据自动绘制服务之间的调用关系图，并能识别常见的服务显示在图标上，例如图上的tomcat、CAS服务

每条连线的颜色反应了服务之间的调用延迟情况，可以非常直观的看到服务与服务之间的调用状态，连线中间的点能点击，可显示两个服务之间链路的平均响应时间、吞吐率以及SLA等信息

在这里插入图片描述

展示服务的性能数据:

在这里插入图片描述

如何通过Zipkin或SKYwalking实现链路追踪

选中其中一个服务，可以查看调用关系及服务基础状态。

如何通过Zipkin或SKYwalking实现链路追踪

拓扑图还有个扁平展示效果

如何通过Zipkin或SKYwalking实现链路追踪

3、链路追踪：可以根据需求，查看链路调用过程

显示请求的响应内部执行情况，一个完整的请求都经过了哪些服务、执行了哪些代码方法、每个方法的执行时间、执行状态等详细信息，快速定位代码问题。

在这里插入图片描述

失败调用还有错误日志：

如何通过Zipkin或SKYwalking实现链路追踪

4、告警提示：

如何通过Zipkin或SKYwalking实现链路追踪

如何通过Zipkin或SKYwalking实现链路追踪

5、指标数据对比

在这里插入图片描述

Zipkin原理

Zipkin 分为两端，Zipkin 服务端和Zipkin 客户端，客户端也就是微服务的应用。客户端配置服务端的 URL 地址，一旦发生服务间的调用的时候，会被配置在微服务里面的 Sleuth 的监听器监听，并生成相应的 Trace 和 Span 信息发送给服务端。发送的方式主要有两种，一种是 HTTP 报文的方式，另一种是消息总线的方式如 RabbitMQ。

不论哪种方式，我们都需要：一个 Eureka 服务注册中心，先看下Zipkin运行架构：

如何通过Zipkin或SKYwalking实现链路追踪

左侧应用服务，同时也是Zipkin-clinet，Eureka-client， 中间是依赖，包括Zipkin-server和Eureka-server，最右侧是WebUI展示及开发接口。

方案比较

Google的Dapper，阿里的鹰眼，大众点评的CAT，Twitter的Zipkin，LINE的pinpoint，国产的skywalking。

市面上的全链路监控理论模型大多都是借鉴Google Dapper论文，本文重点关注以下三种APM组件：

• Zipkin ：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。
• Pinpoint ：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。
• Skywalking ：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。

以上三种全链路监控方案需要对比的项提炼出来 ：

1. 探针的性能 主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显
2. collector的可扩展性 能够水平扩展以便支持大规模服务器集群。 zipkin支持多个实例订阅MQ，异步消费监控信息。skywalking支持单机和集群模式，使用RPC通信。
3. 全面的调用链路数据分析 提供代码级别的可见性以便轻松定位失败点和瓶颈。 zipkin的链路监控粒度到接口级别。skywalking 支持众多的中间件、框架、类库。pinpoint数据分析最完备，提供代码级别的可见性以便轻松定位失败点和瓶颈
4. 对于开发透明，容易开关 添加新功能而无需修改代码，容易启用或者禁用。 Zipkin它要求在需要时修改代码。skywalking和pinpoint基于字节码增强的方式，不需要修改代码，并且可以收集到字节码中的更多精确的信息 。
5. 完整的调用链应用拓扑 自动检测应用拓扑，帮助你搞清楚应用的架构。 pinpoint界面显示的更加丰富，具体到调用的DB名，zipkin的拓扑局限于服务于服务之间 。

接下来大家肯定比较关心 SkyWalking 的性能，那我们来看下官方的测评数据

fec1bf33519179837e2ba08f17ee5f2a.png

图中蓝色代表未使用 SkyWalking 的表现，橙色代表使用了 SkyWalking 的表现，以上是在 TPS 为 5000 的情况下测出的数据，可以看出，不论是 CPU，内存，还是响应时间，使用 SkyWalking 带来的性能损耗几乎可以忽略不计。

接下来我们再来看 SkyWalking 与另一款业界比较知名的分布式追踪工具 Zipkin, Pinpoint 的对比(在采样率为 1 秒 1 个，线程数 500，请求总数为 5000 的情况下做的对比),可以看到在关键的响应时间上， Zipkin(117ms),PinPoint(201ms)远逊色于 SkyWalking(22ms)

bcb6a6b55e1125bdd7f1ab31a972b7df.png

从性能损耗这个指标上看，SkyWalking 完胜！

对代码无任何侵入，除了性能和对代码的侵入性上 SkyWaking 表现不错外，它还有以下优势几个优势

对多语言的支持，组件丰富：目前其支持 Java, .Net Core, PHP, NodeJS, Golang, LUA 语言，组件上也支持dubbo, mysql 等常见组件，大部分能满足我们的需求。

扩展性：对于不满足的插件，我们按照 SkyWalking 的规则手动写一个即可，新实现的插件对代码无入侵。

参考：

skywalking原理_微服务链路追踪原理：https://blog.csdn.net/weixin_39595621/article/details/111574769

skywalking原理_40张图看懂：分布式追踪系统原理及实践：https://blog.csdn.net/weixin_39866487/article/details/111581322

分布式全链路追踪 SkyWalking基本原理（一）：https://www.pianshen.com/article/87011016639/

如何通过Zipkin或SKYwalking实现链路追踪：https://blog.51cto.com/u_10705830/2433647

Pinpoint、SkyWalking、Zipkin，哪个好：https://xcbeyond.blog.csdn.net/article/details/114683836