分布式链路追踪-SkyWalking

本文内容讲述分布式链路追踪系统SkyWalking的使用

以下：

简介

在了解 Skywalking 之前，我们需要先知道 APM 的概念

APM 全称 Application Performance Management/Monitor 应用性能管理（监控），目的是通过各种探针采集数据，收集关键指标，同时搭配数据呈现以实现对应用程序性能管理和故障管理的系统化解决方案。APM 系统则更重视程序内部执行过程指标和服务之间链路调用情况的监控，APM更有利于深入代码找到请求响应“慢”的根本问题。

那么什么是 Skywalking 呢

官方有两句话介绍SkyWalking：
SkyWalking是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案
Skywalking 是一款分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器架构而设计。

Skywalking Agent：

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

Skywalking Collector ：

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

Storage：

Skywalking 的存储，支持以 ElasticSearch、Mysql、TiDB、H2 等作为存储介质进行数据存储

UI：

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

为什么要用 Skywalking ?

随着微服务的大行其道，系统的功能越来越丰富，各类服务之间的调用错综复杂，这就给我们带来了很大的困扰，下面是两个常见的场景。

场景1

开发 A 编写了一段代码，代码依赖了很多的接口。一个调用下去没出结果，或者超时了，Debug 之后发现是接口 M 挂了，然后找到这个接口 M 的负责人B ，告知 B 接口挂了。B 拉起自己的调用和 Debug 环境，按照之前传过来的调用方式重新 Debug 了一遍自己的接口，发现NND是自己依赖的接口 N 挂了，然后找到接口 N 负责人 C 。C同样Debug了自己的接口（此处省略一万个‘怎么可能呢，你调用参数不对吧’），最终发现是某个空判断错误，修复bug，转告给B说我们bug修复了，B再转告给A说，是C那个傻x弄挂了，现在Ok了，你试一下。

场景2

哪一天系统完成了开发，需要进行性能测试，发现哪些地方调用比较慢，影响了全局。A工程师拉起自己的系统，调用一遍，就汇报给老板，时间没啥问题。B工程师拉起自己的系统，调用了一遍，也没啥问题，同时将结果汇报了给老板。C工程师这时候发现自己的系统比较慢，debug发现原来是自己依赖的接口慢了，于是找到接口负责人。。balabala，和场景1一样，弄好了。老板一一把这些都记录下来，满满的一本子。哪天改了个需求，又重新来一遍，劳民伤财。

这里就要说一下 Skywalking 的作用了：