让我们来一步一步地探索Skywalking

共 3406字，需浏览 7分钟

· 2021-06-23

聊技术，不止于技术

系统拆分微服务后，为了便于监控理解系统的行为，微服务之间的调用链监控是必不可少的。提到调用链监控，Skywalking又是不得不提的，本文是我对Skywalking初步调研后的内容整理，包括Skywalking的系统架构、性能影响、Agent集成部署等内容。希望能够对初次接触Skywalking的同学有所帮助。

Skywalking初探

之前写过一篇文章介绍了软件选型的一些内容，对于新技术的调研选型，个人主要关注系统架构、文档完善度、社区活跃度、功能特性是否符合需求及其他一些内容，今天也照着这个步骤来调研一番。

（1）Skywalking架构

Skywalking的架构图如下所示，其实官方提供了一个更加完整的架构图，但对于大多数人来讲，下面的架构图可能理解起来更加方便，简洁但也同样完整。

其实监控系统一般来说可以分成四个部分，数据产生、数据收集、数据存储、数据可视化。上述架构图中四个组件其实分别对应了不同的部分。

UI：Skywalking的可视化界面，在上面可以看到应用的各类指标信息，调用链信息，拓扑图信息等。官方也提供了在线demo，大家上去看看点点可能更加直观。地址：http://demo.skywalking.apache.org/ 用户名/密码：skywalking/skywalking。

Agent/Probe：调用链等监控数据产生的地方。毫无疑问，监控数据肯定是在你的应用程序中产生，Skywalking通过特定语言特性，可以实现代码零侵入的情况下生成监控数据。比如对于Java来说，通过字节码增强技术，可以在应用代码的相应方法前，方法后，增加相应监控数据生成逻辑，来产生监控数据。

Backend：Backend主要有两方面的作用，一是用来收集处理Agent/Probe端发送过来的监控数据，并持久化到存储中，二是提供GraphQL服务，为UI提供展示数据。监控数据的收集可以通过推或拉的方式。Skywalking主要是通过推的方式来收集监控数据，也就是上图中的Agent/Probe主动发送监控数据到Backend。

Storage：用来存储监控数据，以便UI查询展示。Skywalking对于数据存储抽象了一层接口，可以有不同的接口实现。所以能够支持不同的数据存储系统，用的最多的可能还是Elasticsearch。

上面就是Skywalking的系统架构，应用的系统架构在短时间内不会改变的，所以调研的过程中需要重点关注。可以看出Skywalking的架构整体设计还是比较清晰的，模块间功能划分清晰，相互间依赖也挺简单。

（2）Skywalking文档

Skywalking的文档还是很详细的，通读一遍，你想知道的，不想知道的，都能够知道。

通读一遍文档当然会花费你很多的时间，其实第一遍我们不需要细读，但最起码的应该把文档各个部分都浏览一遍，这样基本有个大概的了解。有感兴趣的部分，也可以知道在哪个部分能够找到，然后再细读。

这里我尝试列出一些大家可能感兴趣的部分文档链接：

Agent/Probe快速开始：http://skywalking.apache.org/docs/main/v8.6.0/en/setup/service-agent/java-agent/readme/

Backend快速开始：http://skywalking.apache.org/docs/main/v8.6.0/en/setup/backend/backend-setup/

UI快速开始：http://skywalking.apache.org/docs/main/v8.6.0/en/setup/backend/ui-setup/

UI界面的用户说明：http://skywalking.apache.org/docs/main/v8.6.0/en/ui/readme/

探针性能测试：https://skyapmtest.github.io/Agent-Benchmarks/

有时间的话，建议大家还是通读一遍。

（3） Skywalking社区

Skywalking的社区还是很活跃的，从Github的提交记录以及Issue等情况中可以看出来。

Skywalking也提供了QQ交流群，这对于国内开发者应该是比较友好的。QQ群中提问几乎是有问必答，Skywalking作者本人也会经常作答。

大家在调研过程中遇到问题不妨去交流交流，毕竟你遇到的问题可能其他人已经遇到并解决过了。

（4）其他

1）性能影响

很多人可能会担心通过探针的方式来收集应用监控信息会影响应用的性能。毕竟每次调用前都需要收集相关的监控信息，并且还需要将监控数据发送到后端服务，当然发送监控数据到后端这块是异步处理的，监控信息会先存在内存中，然后有一个线程实时拉取数据发送到后端。

毫无疑问，性能影响肯定是会有的，想要获取系统的可观测性，当然需要付出点代价，关键在于能不能容忍相应的性能损耗。

如果想要降低探针对应用的性能影响，我们可以通过配置抽样率来解决。有同学可能会说，配置了抽样率，有些问题可能就发现不了了。其实对于一个调用频率很高的系统来讲，即使配置了1/1000的抽样率，绝大多数通用的问题也是能够体现出来的。而且APM系统全称是Application Performance Monitor，更多用来定位系统性能问题，所以对于调用频率很高的系统来说，即使配置了抽样率，绝大多数性能问题也是能够看出来的，谷歌在Dapper论文中也证实了这一点，即使1/1000的抽样率，也足以发现系统性能问题了。对于更进一步的系统问题排查，我们还有ELK系统呢。

2）开源协议

Skywalking基于Apache 2.0协议，是比较商业友好的协议了。即使修改代码后再闭源，也是没有问题的。

当然还是希望大家都能够参与到开源中来。

Skywalking搭建部署

及基本功能验证

软件是否能够满足业务需求才是我们选型的关键。

对于一款调用链监控系统来说，调用链数据的正确处理展示，对应用的透明度，以及对性能的影响应该是我们需要着重关注的。

按照官方文档的快速开始，可以简单快速的搭建部署一套Skywalking验证环境，具体的步骤配置文档里已经写的比较详细了，我就不再复制粘贴了。具体大家可以看上文中我列出的文档链接。

基本功能验证其实对于大多数人来讲就是访问个请求，看看调用链信息能否正确在UI中显示出来。

下图展示的便是一个请求的调用链信息详情：

如果请求的调用链信息能够正确展示出来了，说明基本功能已经具备了。

当然对于线上生产来说，我们可能还需要更进一步的功能验证，比如疲劳测试，性能测试等。这些对于不同公司要求都不一样，所以需要大家根据实际去验证。

Agent与应用的集成部署

Agent需要与应用部署在一起，才能够生成监控数据。

Agent与应用的集成部署有两种方式：

（1）将Agent放在程序源码指定文件夹中，通过打包将Agent与程序打包在一起，然后通过脚本的方式启动应用。

（2）基于Agent基本镜像构建应用Docker镜像的方式。

当然不同的公司也有不同的部署流程，但大概思路就是上面所讲的两种。

写在最后

今天跟着大家一起一步一步地调研了Skywalking软件。

Skywalking的架构设计、文档完善度、社区成熟度都是不错的。

对于监控系统来说，Skywalking同样有着对应用的低侵入，低性能损耗的特性。

Skywalking也同样适合大规模部署。

另外，如果想对调用链追踪系统有更深入的了解，建议读一读Google的Dapper论文。

论文搜索比较烦？不用担心，我也为你们准备好了，对话框回复【Dapper】即可获取，是不是很贴心？

希望今天的内容对大家有所帮助。