上一篇【第004篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化下一篇【第06篇】JavaAgent原理——SkyWalking无侵入探针的魔法秘密明日更新敬请期待摘要在APM领域Pinpoint曾经是GitHub Star数最多的开源项目直到2019年被SkyWalking超越。两者功能看起来相似但性能差距却非常显著。不是Pinpoint差而是两者的设计出发点完全不同Pinpoint为能用而设计SkyWalking为高并发生产环境稳定运行而设计。本篇从设计目标、技术选型到具体实现带你看清楚SkyWalking性能优势的本质。一、先把性能定义清楚谈性能必须先定义衡量维度否则对话会变成我们系统很快“快多少”“感觉快”对于APM探针来说性能维度有两个探针端性能损耗给业务系统加上APM后业务系统本身的性能下降了多少OAP端吞吐能力APM后端能处理多少TPS的监控数据SkyWalking的设计目标非常明确┌─────────────────────────────────────────────────────────────┐ │ SkyWalking 性能设计目标明文写在官方文档里 │ │ │ │ 探针端 │ │ 单进程 1万TPS 下支持 100% 采样 │ │ 业务系统性能损耗 10% │ │ │ │ OAP端 │ │ 常规处理能力百亿级别 │ │ 支持 15 个OAP节点处理 250个服务、每天3TB 监控数据 │ │ │ │ 这不是PPT指标是生产案例验证的数字 │ └─────────────────────────────────────────────────────────────┘1万TPS100%采样——这意味着什么意味着你的应用每秒处理1万个请求SkyWalking全量记录每一个请求的追踪链路对业务系统的性能影响不超过10%。这个指标在APM领域是非常高的标准。二、SkyWalking的性能优势来源优势1DataCarrier——异步非阻塞的内存队列探针在业务线程中收集数据后最关键的一步是怎么把数据发给OAP Server而不阻塞业务线程方案A差直接在业务线程里发送gRPC请求——业务线程会等待网络I/O完成严重影响业务响应时间。方案BSkyWalking实际用的使用DataCarrier内存队列业务线程只把数据写入内存队列纳秒级然后立刻返回。另有专门的发送线程池异步消费队列批量打包发送给OAP。┌─────────────────────────────────────────────────────────────┐ │ DataCarrier异步队列的工作流程 │ │ │ │ 业务线程 │ │ │ │ │ ├─ 处理HTTP请求主业务逻辑 │ │ │ │ │ ├─ SkyWalking拦截创建Span ←──── 极低开销纳秒级 │ │ │ │ │ ├─ Span写入DataCarrier内存队列 ←── 极低开销纳秒级 │ │ │ │ │ └─ 返回HTTP响应业务线程不等待数据发送 │ │ │ │ ↕ │ │ DataCarrier 内存队列 │ │ ↕ │ │ │ │ 发送线程独立线程池 │ │ ├─ 批量拉取队列中的Span数据 │ │ ├─ 序列化为Protocol Buffers格式 │ │ └─ 通过gRPC异步发送给OAP Server │ └─────────────────────────────────────────────────────────────┘这是SkyWalking探针低性能损耗的核心原因数据采集与数据传输完全异步解耦。优势2OAL轻量级流计算引擎接到探针上报的Trace数据后OAP需要聚合计算出各种指标平均响应时间、错误率等。Pinpoint的方案依赖HBase的强大存储和Scatter Chart等可视化但所有数据都存储后再查询实时性差而且HBase本身运维复杂。SkyWalking的方案自研OALObservability 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通过采样模型解决了这个问题指标数据Metrics100%采集并聚合因为存的是聚合结果量很小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/天这是很高的吞吐水平。对比一下这意味着什么如果用Pinpoint250GB每天的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_interval30OAP端application.yamlreceiver-trace:default:sampleRate:${SW_TRACE_SAMPLE_RATE:10000}# 10000 100%采样slowDBAccessThreshold:${SW_SLOW_DB_THRESHOLD:default:200,mongodb:100}通过sampleRate控制OAP存储的采样率数值范围0-1000010000代表100%。本篇小结SkyWalking的性能优势来自三个层面的设计探针端DataCarrier内存队列实现异步非阻塞业务线程不等待网络I/OOAP端OAL流式聚合在内存中完成存储的是聚合结果而非原始数据存储层服务器端采样 慢请求全量保留平衡存储成本和数据完整性这些设计使得SkyWalking能在单进程1万TPS下实现100%采样、性能损耗10%的目标并在生产环境中处理250服务/3TB/天的监控规模。下一篇我们深入JavaAgent机制——SkyWalking无侵入探针的魔法到底是怎么变出来的上一篇【第004篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化下一篇【第06篇】JavaAgent原理——SkyWalking无侵入探针的魔法秘密明日更新敬请期待