主流开源 APM：Zipkin/Pinpoint/SkyWalking 全面对比

链路追踪在很多公司已经有大量的实践，开源领域能够开箱即用的产品也不少，主流的包括 Zipkin、Pinpoint、SkyWalking、CAT 等，这里重点对比以下三种优秀的开源 APM 组件。

• Zipkin：由 Twitter 公司开放源代码的调用链分析系统，基于 spring-cloud-sleuth 得到广泛使用，非常轻量。

• Pinpoint：由韩国 Naver 研发团队开源，专注于链路分析和应用性能监控系统，采用 Java 语言编写，埋点无侵入，稳定且易用。

• SkyWalking：国产的优秀 APM 组件，专注于链路和性能监控，埋点无侵入，已加入 Apache 孵化器，本身也支持 OpenTracing 规范，是开源 APM 领域的后起之秀。

这里重点从探针的性能、Collector 的可扩展性、调用链路分析、完整的应用拓扑、对于科技人员使用友好程度（部署安装、埋点接入、使用管理）几个方面来进行对比。

1、探针性能

探针的性能是比较关键的指标，毕竟作为公共组件，如果启用链路监控后导致吞吐量大幅下降，这不仅不能被接受，甚至可能造成生产事件。因此在选择 APM 组件的过程中，必须要经过充分的性能对比测试。不过，要设计公平的性能测试环境来对比这三款方案也并不容易，探针性能与被接入的应用系统自身性能、高吞吐高负载场景、系统间调用关系的复杂度、探针采样频率，甚至 Web 应用服务器的自身性能都有密切关系，都可能对测试指标造成影响。

从性能测试数据来看，在三种链路监控组件中，SkyWalking 的探针对应用系统吞吐量的影响最小，Zipkin 居中，Pinpoint 的影响最为明显，高峰时甚至可能使性能下降超过 10%；同时，启用探针之后，对被接入主机的 CPU 和内存方面也均会产生一定的性能开销，Zipkin 的性能开销最为明显，Pinpoint 和 SkyWalking 则相对较低。综合对比的话，SkyWalking 的表现无疑最优。

2、Collector 扩展性

Collector 是链路工具收集探针或应用埋点时发送的各类数据的关键服务模块，Collector 能否水平扩展决定了该链路追踪工具能否支撑大规模服务器集群。

• Zipkin：Agent 与服务端之间通过 HTTP 或消息队列进行通信。推荐基于消息队列异步方式通信，有利于提高吞吐量。

• SkyWalking：Collector 支持单机和集群两种模式。Collector 与 Agent 之间使用 gRPC 协议进行通信。

• Pinpoint：Pinpoint 的 Collector 同样支持单机或集群部署。Pinpoint Agent 通过 thrift 通信框架，发送链路信息到 Collector。

3、调用链路数据分析

对调用链路采集到的数据分析越全面，粒度越细越好，如果能够实现代码行级别的数据采集和分析，那么定位故障和性能瓶颈时也更加具体。

• Zipkin 的链路监控粒度比较粗（相比较而言），调用链展示只到接口级别。

• SkyWalking 支持主流的各类中间件、开发框架、数据库及消息中间件，不过调用链路分析只能说比 Zipkin 稍稍完备，粒度仍然不够细。SkyWalking 社区非常活跃，版本迭代极为迅速，相信随着其版本的快速更迭，功能也会越来越强。

• Pinpoint 是这几款 APM 组件中调用分析较为完备的一款。Pinpoint 提供了代码级别的追踪粒度，不仅对每个方法进行记录，甚至对执行的 SQL 的耗时都做了记录。当然，这有利也有弊，追踪的粒度越细，性能开销也有可能越大，尽管可以通过设置采样率来减少性能方面的影响，但采样率低的话，请求又可能追踪不到，这中间如何平衡，就需要用户自己仔细考量了。不过，若单纯从链路追踪粒度和数据分析方面来看，目前 Pinpoint 完胜另外两款。

4、完整的应用拓扑

自动分析应用拓扑，能够帮助梳理应用系统之间的调用关系。Zipkin、Pinpoint 和 SkyWalking 这 3 款 APM 组件都能实现完整的链路拓扑展示，相对来说，Zipkin 展示的拓扑结构主要展示服务与服务之间的调用关系，Pinpoint 和 SkyWalking 的调用拓扑则展示得更加丰富，除了服务与服务之间的调用关系外，过程中涉及的中间件（如 DB/Redis）也都有体现。

5、使用友好

不管是 Zipkin、SkyWalking，还是 Pinpoint，都由 4 个模块组成。其中 SkyWalking 和 Pinpoint 都由 Collector、Storage、Agent 和 Web 4 个模块组成。Zipkin 没有提供 Agent，而是多了一个 Query 模块，负责查询 Storage 中存储的数据。

从接入方式来看，SkyWalking 和 Pinpoint 均基于 ASM 字节码增强技术实现调用拦截和数据收集，可以做到真正的代码无侵入，对代码的侵入性非常低，对开发人员可以实现完全透明，只需要在启动服务器时添加一些参数，就可以完成探针的部署；Zipkin 的链路追踪是基于 spring-cloud-sleuth，只提供了基本的操作 API，如果需要与框架或者项目集成的话，就需要手动添加配置文件或增加代码。

对于探针的扩展性，Zipkin 目前能够支持包括 Java、Scala、Node、Go、Python、Ruby 和 C#等主流开发语言和框架。Pinpoint 只支持 Java 和 PHP，而 SkyWalking 目前已支持多种语言，包括 Java、C#、PHP、Node.js、Go 等，如果企业的系统服务涉及多个开发语言，那么 Zipkin 和 SkyWalking 都会是不错的选择。

在数据存储方面，Zipkin 基于 Cassandra，也能够支持 ElasticSearch 和 MySQL，Pinpoint 的后端存储基于 HBase（引申出一个问题，选择 Pinpoint 要有能力运维一套 HBase 集群），SkyWalking 支持的存储很多，包括 ElasticSearch、MySQL、TiDB 等。

在追踪数据查询方面，Pinpoint 无形中也受到 HBase 自身所能支持查询的限制（HBase 只能支持 3 种方式查询：RowKey 精确查找，SCAN 范围查找，全表扫描），至今仍不能支持指定 TraceID 的查询，只支持在视窗界面通过鼠标圈定时间范围后，查看这个范围内的 Trace 信息。而 Zipkin 和 SkyWalking 可以支持多个维度任意组合查询，如时间范围、服务名、Trace 状态、请求路径、TraceID 等。

Zipkin 和 SkyWalking 都是标配 jar 包，部署和启动都非常简单，有 Java 环境即可，而 Pinpoint 的 Collector 和 Web 模块都是 war 包，运行依赖 Web 容器。

在 UI 可视化功能方面，Pinpoint 具备完整的链路追踪与应用性能监控解决方案，Web 界面功能较为强大；而 Zipkin 虽说也提供了 UI 界面，但其功能不及 Pinpoint。如果是直接比较原生 UI 界面功能的话，当前 Pinpoint 要比 SkyWalking 和 Zipkin 稍微好些，尤其是服务调用之间的拓扑图展示。不过如果企业内部开发资源较为丰富的话，Zipkin 和 SkyWalking 都能够进行定制性的二次开发，从而扩展其 UI 功能。

在监控和告警方面，Zipkin 的链路追踪只到接口级，目前也不支持告警。而 Pinpoint 和 SkyWalking 都是代码级，且均支持自定义告警规则。不过，Pinpoint 配置告警时的用户、用户组信息以及告警规则都保存在 MySQL 数据库中，如果配置告警规则的话，既要维护 HBase 又要维护 MySQL，维护成本会升高。SkyWalking 在 config/alarm-settings.xml 中配置告警规则，无须其他组件支持，同时告警规则也支持自定义。

总的来说，在易用性和代码侵入方面，Pinpoint 和 SkyWalking 要优于 Zipkin；同时 Pinpoint 相比后起之秀 SkyWalking，在稳定性和易用性方面，目前来看仍具优势；在性能方面，Pinpoint 明显处于下方，不过整体损耗尚可接受。SkyWalking 和 Pinpoint 都是优秀的调用链追踪+APM 监控系统，能够覆盖大部分使用场景，让研发和运维能够实时或准实时地了解应用系统的运行情况。对于二次开发实力强的企业，可以综合对比各方的可扩展性、接入效率、二次开发等方面，选择一个更能满足自己定制需求的全链路监控工具。