【SkyWalking从入门到精通】第05篇：SkyWalking凭啥比Pinpoint快——性能优势的深层原因

上一篇【第004篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化
下一篇【第06篇】JavaAgent原理——SkyWalking无侵入探针的魔法秘密（明日更新，敬请期待）

摘要

在APM领域，Pinpoint曾经是GitHub Star数最多的开源项目，直到2019年被SkyWalking超越。两者功能看起来相似，但性能差距却非常显著。不是Pinpoint差，而是两者的设计出发点完全不同：Pinpoint为"能用"而设计，SkyWalking为"高并发生产环境稳定运行"而设计。本篇从设计目标、技术选型到具体实现，带你看清楚SkyWalking性能优势的本质。

一、先把"性能"定义清楚

谈性能必须先定义衡量维度，否则对话会变成"我们系统很快！"“快多少？”“感觉快！”

对于APM探针来说，性能维度有两个：

1. 探针端性能损耗：给业务系统加上APM后，业务系统本身的性能下降了多少？
2. OAP端吞吐能力：APM后端能处理多少TPS的监控数据？

SkyWalking的设计目标非常明确：

┌─────────────────────────────────────────────────────────────┐ │ SkyWalking 性能设计目标（明文写在官方文档里） │ │ │ │ 探针端： │ │ 单进程 1万TPS 下，支持 100% 采样 │ │ 业务系统性能损耗 < 10% │ │ │ │ OAP端： │ │ 常规处理能力：百亿级别 │ │ 支持 15 个OAP节点处理 250个服务、每天3TB 监控数据 │ │ │ │ 这不是PPT指标，是生产案例验证的数字！ │ └─────────────────────────────────────────────────────────────┘

1万TPS，100%采样——这意味着什么？意味着你的应用每秒处理1万个请求，SkyWalking全量记录每一个请求的追踪链路，对业务系统的性能影响不超过10%。这个指标在APM领域是非常高的标准。

二、SkyWalking的性能优势来源

优势1：DataCarrier——异步非阻塞的内存队列

探针在业务线程中收集数据后，最关键的一步是：怎么把数据发给OAP Server而不阻塞业务线程？

方案A（差）：直接在业务线程里发送gRPC请求——业务线程会等待网络I/O完成，严重影响业务响应时间。

方案B（SkyWalking实际用的）：使用DataCarrier内存队列，业务线程只把数据写入内存队列（纳秒级），然后立刻返回。另有专门的发送线程池异步消费队列，批量打包发送给OAP。

┌─────────────────────────────────────────────────────────────┐ │ DataCarrier异步队列的工作流程 │ │ │ │ 业务线程 │ │ │ │ │ ├─ 处理HTTP请求（主业务逻辑） │ │ │ │ │ ├─ SkyWalking拦截：创建Span ←──── 极低开销（纳秒级） │ │ │ │ │ ├─ Span写入DataCarrier内存队列 ←── 极低开销（纳秒级） │ │ │ │ │ └─ 返回HTTP响应（业务线程不等待数据发送） │ │ │ │ ↕ │ │ DataCarrier 内存队列 │ │ ↕ │ │ │ │ 发送线程（独立线程池） │ │ ├─ 批量拉取队列中的Span数据 │ │ ├─ 序列化为Protocol Buffers格式 │ │ └─ 通过gRPC异步发送给OAP Server │ └─────────────────────────────────────────────────────────────┘

这是SkyWalking探针低性能损耗的核心原因：数据采集与数据传输完全异步解耦。

优势2：OAL轻量级流计算引擎

接到探针上报的Trace数据后，OAP需要聚合计算出各种指标（平均响应时间、错误率等）。

Pinpoint的方案：依赖HBase的强大存储和Scatter Chart等可视化，但所有数据都存储后再查询，实时性差，而且HBase本身运维复杂。

SkyWalking的方案：自研OAL（Observability Analysis Language）流式计算引擎，数据在内存中实时聚合，只把聚合结果持久化到存储。

原始Trace数据流： 每秒10,000条 TraceSegment Pinpoint方式： 10,000条 → HBase存储 → 查询时聚合计算 → 慢！ SkyWalking方式： 10,000条 → 内存L1聚合 → 内存L2聚合 → 写入ES的是聚合结果 存储的数据量对比： Pinpoint：所有原始数据 （10,000条） SkyWalking：聚合后的指标（可能只有几十条）

这就是为什么SkyWalking在相同硬件下能处理更高吞吐量的根本原因。

优势3：不强制100%写入

传统APM（包括很多Pinpoint部署方案）会把所有Trace数据持久化，这带来了巨大的I/O压力。

SkyWalking通过采样模型解决了这个问题：

• 指标数据（Metrics）：100%采集并聚合，因为存的是聚合结果，量很小
• Trace明细数据：支持可配置的采样率（服务器端采样），默认采样率可以设置
• 慢请求/异常请求：无论采样率如何，总是100%记录

这个策略的精妙之处在于：你永远不会错过问题请求（异常和慢请求全量记录），但正常请求只采样部分，大幅降低存储压力。

三、Pinpoint vs SkyWalking架构对比

深入看一下两者的技术选型差异：

┌─────────────────────────────────────────────────────────────────┐ │ 架构对比：SkyWalking vs Pinpoint │ ├────────────────────┬──────────────────┬──────────────────────── │ │ 组件 │ SkyWalking │ Pinpoint │ ├────────────────────┼──────────────────┼──────────────────────── │ │ 探针异步机制 │ DataCarrier内存队列│ ThriftClient连接池 │ │ OAP/Collector处理 │ OAL流式内存聚合 │ Flink/HBase批量写入 │ │ 存储技术 │ ES/MySQL/TiDB │ HBase（强依赖） │ │ 查询方式 │ GraphQL实时查询 │ MySQL + HBase混合查询 │ │ 部署复杂度 │ 低 │ 高（需要整套大数据栈） │ │ 1万TPS探针损耗 │ < 10% │ 显著高于SkyWalking │ │ 最大规模案例 │ 250服务/3TB/天 │ 大规模（但需大数据支持）│ └────────────────────┴──────────────────┴──────────────────────── │

Pinpoint并不差，它的设计非常优秀，也有很多成功案例。只是两者的技术路线选择不同：

• Pinpoint：“用大数据技术解决大数据问题”
• SkyWalking：“不引入大数据问题，从根本上控制数据量”

四、真实生产案例：250服务/3TB/天

书中提到的这个案例非常有说服力：

背景：某大型零售企业（书中描述的案例规模）

• 服务数量：250个微服务
• 监控数据量：每天产生3TB监控数据
• SkyWalking集群规模：15个OAP节点

15个节点处理250个服务每天3TB数据，单节点处理约200GB/天，这是很高的吞吐水平。

对比一下这意味着什么：如果用Pinpoint，250GB每天的HBase存储增量，意味着需要一个相当规模的HBase集群（通常需要至少6个数据节点），而且HBase的运维复杂度远高于Elasticsearch。

SkyWalking通过流式聚合大幅压缩了存储数据量——那3TB原始数据，经过OAL聚合后，存储到Elasticsearch的实际数据量远小于3TB。

五、100%采样的哲学

大多数APM系统（包括Zipkin、Jaeger的默认配置）在高流量下会开启降采样：只记录1/100或1/1000的请求。

SkyWalking的立场非常鲜明：在单进程1万TPS下支持100%采样。

这背后的工程哲学是：

降采样的问题： 你永远无法预知哪次请求会出问题 如果你只记录了1/100的请求 那么出问题的那1条请求有99%的概率没被记录 故障时你什么都查不到 SkyWalking的解决方案： 通过极低的探针性能损耗，实现生产环境100%采样 + 慢请求/异常请求无论如何100%保留 = 故障时总有数据可查

当然，100%采样对存储是挑战。SkyWalking通过服务器端采样来控制：OAP层可以设置最终持久化的采样率，过滤掉大量正常请求的Trace，只保留有价值的样本。探针端采集100%，存储端聪明地过滤。

六、性能调优的两个关键参数

对于关注性能的同学，这里提前透露两个重要的参数：

探针端：

# 控制采样率（100代表100%，默认值） agent.sample_n_per_3_secs=-1 # -1表示全量采样 # 控制上报的缓冲队列大小 collector.grpc_channel_check_interval=30

OAP端（application.yaml）：

receiver-trace:default:sampleRate:${SW_TRACE_SAMPLE_RATE:10000}# 10000 = 100%采样slowDBAccessThreshold:${SW_SLOW_DB_THRESHOLD:default:200,mongodb:100}

通过sampleRate控制OAP存储的采样率，数值范围0-10000，10000代表100%。

本篇小结

SkyWalking的性能优势来自三个层面的设计：

1. 探针端：DataCarrier内存队列实现异步非阻塞，业务线程不等待网络I/O
2. OAP端：OAL流式聚合在内存中完成，存储的是聚合结果而非原始数据
3. 存储层：服务器端采样 + 慢请求全量保留，平衡存储成本和数据完整性

这些设计使得SkyWalking能在单进程1万TPS下实现100%采样、性能损耗<10%的目标，并在生产环境中处理250服务/3TB/天的监控规模。

下一篇我们深入JavaAgent机制——SkyWalking"无侵入"探针的魔法到底是怎么变出来的？

上一篇【第004篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化
下一篇【第06篇】JavaAgent原理——SkyWalking无侵入探针的魔法秘密（明日更新，敬请期待）