「系统架构」什么是链路追踪？分布式系统如何实现链路追踪？( 三 ) 在分布式系统

文章插图
但在生产上，每次服务调用基本不可能都在同一时间点调用，因为期间有网络调用延时等，实际调用情况很可能是下图这样：
文章插图
这样的话就会导致某些调用在服务 A 上被采样了，在服务 B ， C 上不被采样，也就没法分析调用链的性能。
那么 SkyWalking 是如何解决的呢？
它是这样解决的：如果上游有携带 Context 过来（说明上游采样了），则下游将强制采集数据，这样可以保证链路完整。
SkyWalking 的基础架构SkyWalking 的基础如下架构，可以说几乎所有的的分布式调用都是由以下几个组件组成的。
文章插图
首先当然是节点数据的定时采样，采样后将数据定时上报，将其存储到 ES, MySQL 等持久化层，有了数据自然而然可根据数据做可视化分析。
SkyWalking 的性能如何如下是官方的测评数据：
文章插图
图中蓝色代表未使用 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为例来介绍链路追踪系统，但是并不是说其他链路追踪系统一点不适用。具体选择什么样的，大家可按实际场景灵活选择。