1.1.3　SkyWalking的适用场景

SkyWalking是一个为微服务、容器化和分布式系统而生的高度组件化的APM项目。

早在2010年SOA开始兴起时，应用系统开发人员就注意到，系统的调试过程越来越复杂，在线运行程序出现故障时，面临的问题定位已经很难使用传统日志进行排查。之后随着微服务的兴起，去IOE及分布式架构的广泛采用，程序性能的监控和问题定位需求也越来越急迫。

这正是SkyWalking项目诞生的出发点，SkyWalking受Google Dapper论文启发，整合多位初创成员在APM和互联网公司的工作经验，设立了基于分布式追踪的应用性能监控解决方案。同时，针对中国业务流量大和系统研发团队的特点，SkyWalking首先提出在生产大流量环境下支持100%追踪采样。SkyWalking也是目前唯一一个提出此支持的APM系统。

1. SkyWalking不是一个单纯的追踪系统

如1.1.1节所述，SkyWalking首先是一个应用性能监控工具，它的目标是应用性能。很多人把SkyWalking和Zipkin、Jaeger作为开源界的竞争对手，而实际上这三个社区的核心成员都不这么看。

SkyWalking在语言探针的场景下，具有自动化分布式追踪（distributed tracing）的能力，但这个能力是为应用性能监控服务的。它提供了高性能、自动探针解决方案，支持轻量级分析拓扑图、应用性能指标等功能。而Zipkin和Jaeger都专注于追踪本身，得到尽可能细致的调用链，并建议在高流量时开启采样。大家深入使用后会发现，双方系统提供的追踪结构有较大差别。

2. SkyWalking不是一个以大数据为基础的APM系统

提到APM，就不得不提早在2012年由韩国Naver公司开源的APM项目Pinpoint。Pinpoint曾经是GitHub star数最多的APM项目，直到2019年被SkyWalking超过。初看Pinpoint和SkyWalking，大家会感觉功能有些类似，毕竟都是在APM领域，但是两者采用的技术栈反映了其本质差别：Pinpoint立足于HBase；SkyWalking使用包括Elasticsearch在内的多种存储，却不支持任何一种大数据技术。

SkyWalking在3之后的版本中就完全放弃了大数据技术栈，根本原因是，作为Ops的核心系统之一，轻量级和灵活性被放在首要位置上。SkyWalking以监控千亿级流量为基础要求，自己不能反而成为整个大型分布式系统的部署和运维难点，而大数据技术却适得其反，会大幅增加运维和部署难度。

同时，SkyWalking在超过5000 TPS下超级优良的性能，也是其与Pinpoint的较大区别。无论是官方测试还是网上大量的性能对比都能反映出巨大差异。SkyWalking在设计之初，也是要保证探针能够在单进程1万TPS级别系统中，提供稳定的100%采样，以及合理的性能消耗（小于10%增幅）。高起点也要求SkyWalking必须能够完全控制自己的技术栈和运算模型，使其完全符合APM计算的要求。

除了类似的项目比较，还有一些比较核心的运用场景，可以帮助大家了解SkyWalking。

3. SkyWalking不是方法诊断系统

首先，从技术角度上说，方法级别追踪是SkyWalking技术栈能够做到的技术，但是官方并不推荐这样使用，特别是在生产环境中。方法级别追踪是性能诊断工具的工作，而不是APM系统要做的。APM系统要求在有限性能消耗下，在生产环境长时间低消耗运行，而方法监控会消耗大量的内存和性能，并不适合大流量系统。

当然，SkyWalking考虑到不同团队的使用场景，在可选插件中提供了对Spring 托管的类进行方法级别追踪。

作为APM系统，SkyWalking不建议做常规性新加span的方法诊断，而提供了更为高效合理的方式——性能剖析，用于生产环境的性能诊断。感兴趣的读者可以阅读14.2节，了解SkyWalking 7的这个新特性。

4. SkyWalking能够追踪方法参数

参数追踪和方法追踪类似，即使是针对HTTP请求的方法参数追踪，也会对应用系统和APM造成较大的压力。虽然目前SkyWalking的部分插件（如MySQL）支持用户手动开启参数追踪，但依然提醒用户，要注意考虑性能消耗。

此外，SkyWalking 7新推出了性能诊断功能，方法参数会被自动捕捉。