背景

当用户在使用系统界面交互时，会不时触发事件发起对后端服务的调用。
可能大家都听说过一句话，如果响应超过3秒以上的话，用户就会感受到系统很慢，并且内心达到不可接受的程度。
这样的用户体验通常会使用户通过暴力的方式，提前结束等待（除非很特别的场景让用户认为值得等待）。
对于开发该系统的运维人员，需要想办法监控系统所提供服务的质量，对不满足性能要求的服务提供给开发。
开发人员根据运维人员所提供的服务性能指标，对服务进行分析并进行优化、上线。
运维人员再次监控优化结果......如此不断的优化下去。
如上所示，要想优化系统性能，就得有技术组件对应用的服务进行监控。及APM<Application Performance Monitor>【应用性能监控】 。

技术选型

业界有成熟的开源技术组件可以实现该功能，主流的组件有zipkin、pinpoint、skywalking。
下面对相关技术组件进行比较：

性能比较

image

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

其它比较

组件	优点	缺点
Zipkin	与spring-cloud项目整合非常方便，而且支持以spring-boot的方式部署zipkin-collector	功能比较少，而且有代码入侵(jar包和配置项)
Pinpoint	功能比较全，UI比较好，而且调用链的跟踪粒度非常细，并且依靠HBase强大的存储能力适合日志量非常庞大的场景	由于采集信息太过详细所以对性能的损耗最大，并且HBase的维护代价有点大，需要有能力hold住一套HBase集群
Skywalking	功能比较全，UI比较好，性能损耗较少，主流中间件和数据库的监控基本都支持	es强在检索能力但存储能力偏弱

选型

根据项目情况，选择使用Skywalking。

Skywalking

介绍

SkyWalking开源项目由吴晟2015年创建，同年10月在GitHub上作为个人项目开源。SkyWalking项目的核心目标，是针对微服务、Cloud Native、容器化架构，提供应用性能监控和分布式调用链追踪能力。 目前已加入Apache孵化器。目前支持链路追踪和监控应用组件如下，基本涵盖主流框架和容器，如国产PRC Dubbo和motan等，国际化的spring boot,spring cloud。提供以下主要功能：

• 分布式追踪和上下文传输
• 应用、实例、服务性能指标分析
• 根源分析
• 应用拓扑分析
• 应用和服务依赖分析
• 慢服务检测
• 性能优化

架构图

下面是 SkyWalking 6.x的架构图

image

工作原理

在应用程序中添加 SkyWalking Agent，就可以将接口、服务、数据库、MQ等进行追踪，将追踪结果通过 HTTP 或 gRPC 发送到 OAPServer，经过分析和聚合，将结果存储到 Elasticsearch 或 H2，SkyWalking 同时提供了一个 SkyWalking UI 的可视化界面，UI 以 GraphQL + HTTP 方式获取存储数据进行展示。