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

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

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

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

 

基本实现原理

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

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

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

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

 

SkyWalking的原理及架构设计

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

skywalking的工作机制

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

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

SkyWalking 核心模块介绍：

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

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

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

3. Storage