什么是链路追踪？分布式体系怎样实现链路追踪？

藏宝库编辑 · 2024-9-8 15:11:06

在分布式体系，尤其是微服务体系中，一次外部哀求通常须要内部多个模块，多个中心件，多台呆板的相互调用才气完成。在这一系列的调用中，大概有些是串行的，而有些是并行的。在这种情况下，我们怎样才气确定这整个哀求调用了哪些应用？哪些模块？哪些节点？以及它们的先后次序和各部门的性能怎样呢？
这就是涉及到链路追踪。
什么是链路追踪?

链路追踪是分布式体系下的一个概念，它的目标就是要办理上面所提出的问题，也就是将一次分布式哀求还原成调用链路，将一次分布式哀求的调用情况会集展示，比如，各个服务节点上的耗时、哀求详细到达哪台呆板上、每个服务节点的哀求状态等等。

链路追踪的原理

衡量一个接口，我们一样平常会看三个指标：
1、接口的 RT（Route-Target）你怎么知道?
2、接口是否有非常相应?
3、接口哀求慢在那里?
1、单体架构期间
在创业初期，我们的系同一样平常是单体架构，如下：
对于单体架构，我们可以利用 AOP（切面编程）来统计这三个指标，如下：

利用 AOP（切面编程），对原本的逻辑代码侵入更少，我们只须要在调用详细的业务逻辑前后分别打印一下时间即可盘算出团体的调用时间。别的，利用 AOP（切面编程）来捕获非常也可知道是那里的调用导致的非常。
2、微服务架构
随着业务的快速发展，单体架构越来越不能满足须要，我们的体系逐步会朝微服务架构发展，如下：
在微服务架构下，当有用户反馈某个页面很慢时，固然我们知道这个哀求大概的调用链是 A -----> C -----> B -----> D，但服务这么多，而且每个服务都有好几台呆板，怎么知道问题详细出在哪个服务？哪台呆板呢？

这也是微服务这种架构下的几个痛点：
1、排查问题难度大，周期长
2、特定场景难复现
3、体系性能瓶颈分析较难
分布式调用链就是为相识决以上几个问题而生，它紧张的作用如下：
1、主动采取数据
2、分析数据，产生完备调用链：有了哀求的完备调用链，问题有很大概率可复现
3、数据可视化：每个组件的性能可视化，能资助我们很好地定位体系的瓶颈，及时找出问题所在
通太过布式追踪体系，我们能很好地定位哀求的每条详细哀求链路，从而轻易地实现哀求链路追踪，进而定位和分析每个模块的性能瓶颈。
3、分布式调用链标准（OpenTracing）
OpenTracing 是一个轻量级的标准化层，它位于应用步调/类库和追踪或日记分析步调之间。它的出现是为相识决差别的分布式追踪体系 API 不兼容的问题。

OpenTracing 通过提供与平台和厂商无关的 API，使得开辟职员可以大概方便地添加追踪体系，就像单体架构下的AOP（切面编程）一样。
说到这里，各人是否想过 Java 中类似的实现？还记得 JDBC 吧？JDBC 就是通过提供一套标准的接口让各个厂商去实现，步调员即可面临接口编程，不消关心详细的实现。这里的接口实在就是标准。以是，订定一套标准非常紧张，可以实现组件的可插拔。
OpenTracing 的数据模子，紧张有以下三个：

Trace：一个完备哀求链路
Span：一次调用过程（须要有开始时间和竣事时间）
SpanContext：Trace 的全局上下文信息，如内里有traceId

为了让各人更好地明确这三个概念，我特意画了一张图：
如图所示，一次下单的完备哀求就是一个 Trace。TraceId是这个哀求的全局标识。内部的每一次调用就称为一个 Span，每个 Span 都要带上全局的 TraceId，如许才可把全局 TraceId 与每个调用关联起来。这个 TraceId 是通过 SpanContext 传输的，既然要传输，显然都要遵照协议来调用。如图所示，如果我们把传输协议比作车，把 SpanContext 比作货，把 Span 比作路应该会更好明确一些。
明确了这三个概念，接下来我们就看看分布式追踪体系是怎样收罗图中的微服务调用链。
我们可以看到底层有一个 Collector 不停在岑寂无闻地网络数据，那么每一次调用 Collector 会网络哪些信息呢。
1、全局 trace_id：这是显然的，如许才气把每一个子调用与最初的哀求关联起来
2、span_id: 图中的 0，1，1.1，2，如许就能标识是哪一个调用
3、parent_span_id：比如 b 调用 d 的 span_id 是 1.1，那么它的 parent_span_id 即为 a 调用 b 的 span_id 即 1，如许才气把两个紧邻的调用关联起来。
有了这些信息，Collector 网络的每次调用的信息如下：

根据这些图表信息显然可以据此来画出调用链的可视化视图如下：

于是一个完备的分布式追踪体系就实现了。
以上实现看起来确实简朴，但有以下几个问题须要我们细致思考一下：
1、怎么主动收罗 span 数据：主动收罗，对业务代码无侵入
2、怎样跨进程通报 context
3、traceId 怎样包管全局唯一
4、哀求量这么多采集会集会不会影响性能
接下来，我们来看看链路追踪体系 SkyWalking 是怎样办理以上四个问题的。
链路追踪体系SkyWalking的原理

1、怎么主动收罗 span 数据
SkyWalking 采取了插件化 + javaagent 的情势来实现了 span 数据的主动收罗，如许可以做到对代码的无侵入性。插件化意味着可插拔，扩展性好。如下图所示：

2、怎样跨进程通报 context
我们知道数据一样平常分为 header 和 body，就像 http 有 header 和 body，RocketMQ 也有 MessageHeader，Message Body。body 一样平常放着业务数据，以是不宜在 body 中通报 context，应该在 header 中通报 context，如图所示：
dubbo 中的 attachment 就相当于 header，以是我们把 context 放在 attachment 中，如许就办理了 context 的通报问题。
3、traceId 怎样包管全局唯一
要包管全局唯一，我们可以采取分布式大概当地天生的 ID。利用分布式的话，须要有一个发号器，每次哀求都要先哀求一下发号器，会有一次网络调用的开销。以是 SkyWalking 终极采取了当地天生 ID 的方式，它采取了台甫鼎鼎的 snowflow 算法，性能很高。
不外 snowflake 算法有一个众所周知的问题：时间回拨，这个问题大概会导致天生的 id 重复。那么 SkyWalking 是怎样办理时间回拨问题的呢。
每天生一个 id，都会记录一下天生 id 的时间（lastTimestamp），如果发现当前时间比上一次天生 id 的时间（lastTimestamp）还小，那说明发生了时间回拨，此时会天生一个随机数来作为 traceId。这里大概就有同砚要较真了，大概会觉得天生的这个随机数也会和已天生的全局 id 重复，是否再加一层校验会好点。
这里要说一下体系操持上的方案弃取问题了，起首如果针对产生的这个随机数作唯一性校验无疑会多一层调用，会有肯定的性能消耗，但其及时间回拨发生的概率很小（发生之后由于呆板时间紊乱，业务会受到很大影响，以是呆板时间的调解肯定要慎之又慎），再加上天生的随机数重合的概率也很小，综合思量这里确实没有须要再加一层全局唯一性校验。对于技能方案的选型，肯定要克制过度操持，矫枉过正。
4、哀求量这么多，全部采集会集会不会影响性能?
如果对每个哀求调用都收罗，那毫无疑问数据量会非常大，但反过来想一下，是否真的有须要对每个哀求都收罗呢？实在没有须要，我们可以设置采样频率，只采样部门数据，SkyWalking 默认设置了 3 秒采样 3 次，其余哀求不采样，如图所示：

如许的采样频率实在充足我们分析组件的性能了，按 3 秒采样 3 次，如许的频率来采样数据会有啥问题呢。理想情况下，每个服务调用都在同一个时间点，如许的话每次都在同一时间点采样确实没问题。如下图所示：
但在生产上，每次服务调用根本不大概都在同一时间点调用，由于期间有网络调用延时等，实际调用情况很大概是下图如许：
如许的话就会导致某些调用在服务 A 上被采样了，在服务 B，C 上不被采样，也就没法分析调用链的性能。
那么 SkyWalking 是怎样办理的呢？
它是如许办理的：如果上游有携带 Context 过来（说明上游采样了），则卑鄙将陵暴收罗数据，如许可以包管链路完备。
SkyWalking 的根本架构

SkyWalking 的根本如下架构，可以说险些全部的的分布式调用都是由以下几个组件构成的。

起首固然是节点数据的定时采样，采样后将数据定时上报，将其存储到 ES, MySQL 等恒久化层，有了数据天然而然可根据数据做可视化分析。
[图片上传失败...(image-a9fec9-1673754852336)]
SkyWalking 的性能怎样
[图片上传失败...(image-45d20d-1673754852336)]
如下是官方的测评数据：
图中蓝色代表未利用 SkyWalking 的表现，橙色代表利用了 SkyWalking 的表现，以上是在 TPS 为 5000 的情况下测出的数据，可以看出，岂论是 CPU，内存，照旧相应时间，利用 SkyWalking 带来的性能消耗险些可以忽略不计。
接下来我们再来看 SkyWalking 与另一款业界比力着名的分布式追踪工具 Zipkin、Pinpoint 的对比（在采样率为 1 秒 1 个，线程数 500，哀求总数为 5000 的情况下做的对比）。
可以看到在关键的相应时间上， Zipkin（117ms），PinPoint（201ms）远逊于 SkyWalking（22ms）！从性能消耗这个指标上看，SkyWalking 完胜！
再看下另一个指标：对代码的侵入性怎样。
ZipKin 是须要在应用步调中埋点的，对代码的侵入强，而 SkyWalking 采取 javaagent + 插件化这种修改字节码的方式可以做到对代码无任何侵入。除了性能和对代码的侵入性上 SkyWaking 表现不错外，它另有以下上风几个上风：

对多语言的支持，组件丰富：如今其支持 Java、 .Net Core、PHP、NodeJS、Golang、LUA 语言，组件上也支持dubbo, mysql 等常见组件，大部门能满足我们的需求。
扩展性：对于不满足的插件，我们按照 SkyWalking 的规则手动写一个即可，新实现的插件对代码无入侵。

以上固然紧张以SkyWalking为例来先容链路追踪体系，但是并不是说其他链路追踪系同一点不实用。详细选择什么样的，各人可按实际场景机动选择。

什么是链路追踪？分布式体系怎样实现链路追踪？

所属分类: 问答交流

新帖推荐: 30日

推荐作品