Skywalking理论与实践

链路追踪是什么?

随着服务的越来越多，对调用链的分析会越来越复杂 通常会遇到下面一些问题，比如：

1. 如何串联整个调用链路，快速定位问题？

2. 如何缕清各个微服务之间的依赖关系？

3. 如何进行各个微服务接口的性能分折？

链路追踪框架对比

1. Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。

2. Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无 代码侵入。

3. SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端 无代码侵入。目前已加入Apache孵化器。

4. CAT是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

性能对比

模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即 100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合 起来，一共有12种。

下面看下汇总表： 从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的 影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器 进行的压测，对CPU和memory的影响都差不多在10%之内。

skywalking是什么?

根据官方的解释，Skywalking 是一个可观测性分析平台(Observability Analysis Platform，简称 OAP)和应用性能管理系统(Application Performance Management 简称 APM)。

Skywalking主要功能特性

1 , 多种监控手段，可以通过语言探针和service mesh获得监控的数据；

2、支持多种语言自动探针，包括 Java，.NET Core 和 Node.JS；

3、轻量高效，无需大数据平台和大量的服务器资源；

4、模块化，UI、存储、集群管理都有多种机制可选；

5、支持告警；

6、优秀的可视化解决方案；

社区相当活跃。Skywalking 已经进入 Apache 孵化，目前的 star 数已经超过 11k，最新版本 6.5.0 已经发布。开发者是国人，可以直接和项目发起人交流进行问题的解决。

探针无倾入性**。**对比 CAT 具有倾入性的探针，优势较大。不修改原有项目一行代码就可以进行集成。

探针性能优秀。有网友对 Pinpoint 和 Skywalking 进行过测试，由于 Pinpoint 收集的数据过多，所以对性能损耗较大，而 Skywalking 探针性能十分出色。

支持组件较多。特别是对 RPC 框架的支持，这是其它框架所不具备的。Skywalking 对 Dubbo、gRPC 等有原生的支持，甚至连小众的 motan 和 sofarpc 都支持。

Skywalking三大模块

Agent（探针）：Agent 运行在各个服务实例中，负责采集服务实例的 Trace 、Metrics 等数据，然后通过 gRPC 方式上报给 SkyWalking 后端。

OAP：SkyWalking 的后端服务，其主要责任有两个。

一个是负责接收 Agent 上报上来的 Trace、Metrics 等数据，交给 Analysis Core （涉及 SkyWalking OAP 中的多个模块）进行流式分析，最终将分析得到的结果写入持久化存储中。SkyWalking 可以使用 ElasticSearch、H2、MySQL 等作为其持久化存储，一般线上使用 ElasticSearch 集群作为其后端存储。

另一个是负责响应 SkyWalking UI 界面发送来的查询请求，将前面持久化的数据查询出来，组成正确的响应结果返回给 UI 界面进行展示。

UI 界面：SkyWalking 前后端进行分离，该 UI 界面负责将用户的查询操作封装为 GraphQL 请求提交给 OAP 后端触发后续的查询操作，待拿到查询结果之后会在前端负责展示。

Skywalking怎么用?

Skywalking理论

APM（应用性能管理）与Dapper原理介绍_zhaohong_bo的博客-CSDN博客_dapper原理

• Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
  span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
• Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
• Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束

• • cs - Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
  • sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
  • ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
  • cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

将Span和Trace在一个系统中使用Zipkin注解的过程图形化：

参考文档

1.微服务链路追踪SkyWalking(1).pdf2 Skywalking UI介绍(1).pdfskywalking原理_Skywalking 从入门到精通_weixin_39603265的博客-CSDN博客