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

Posted 2022-09-09 key_3_feng

链路追踪在很多公司已经有大量的实践，开源领域能够开箱即用的产品也不少，主流的包括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监控系统，能够覆盖大部分使用场景，让研发和运维能够实时或准实时地了解应用系统的运行情况。对于二次开发实力强的企业，可以综合对比各方的可扩展性、接入效率、二次开发等方面，选择一个更能满足自己定制需求的全链路监控工具。