云原生之全链路分布式跟踪系统 Zipkin和SkyWalking

 贪多嚼不烂 Pinpoint 就不对比了 

参考

APM系统简单对比(zipkin,pinpoint和skywalking) · springcloud · 看云

Zipkin和SkyWalking都是流行的分布式跟踪系统，但它们的设计和实现有明显的不同。

以下是它们之间的一些对比：

数据存储：

Zipkin：默认使用内存存储跟踪数据，也可以配置为使用MySQL、Elasticsearch等。

SkyWalking：支持多种存储方式，包括H2内存、MySQL、Elasticsearch、InfluxDB等，并且提供了高可用性设计。

数据分析和查询：

Zipkin：提供了一个简单的界面来查看跟踪信息，但是缺乏复杂查询功能。

SkyWalking：提供了强大的界面和强大的查询功能，可以进行复杂的查询并提供各种指标报表。

扩展性和可用性：

Zipkin：设计为一个轻量级解决方案，没有提供复杂的集群和高可用性设计。

SkyWalking：支持集群部署，并且可以通过集群来保证服务的高可用性。

监控的粒度：

Zipkin：主要关注于服务到服务的调用链和端到端的追踪。

SkyWalking：不仅关注服务间的调用，还可以追踪到每个服务内的中间件、数据库访问等细粒度的行为。

兼容性：

Zipkin：需要与Spring Cloud Sleuth等库配合使用。

SkyWalking：支持Java、.NET、Node.js等多种语言，并且可以与各种框架和库集成。

社区支持和更新频率：

Zipkin：由Twitter维护，更新和支持可能不如SkyWalking频繁。

SkyWalking：由Apache软件基金会维护，更新和支持更为频繁。

选择哪一个取决于你的具体需求。如果你需要一个轻量级的跟踪系统，对扩展和高可用性要求不高，那么Zipkin可能是个不错的选择。如果你需要一个能够提供强大分析和高可用性的系统，并且对监控粒度要求较高，那么SkyWalking可能更适合。

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。

二、Zipkin

优点：与spring-cloud项目整合非常方便，而且支持以spring-boot的方式部署zipkin-collector
缺点：功能比较少，而且有代码入侵(jar包和配置项)

三、Pinpoint

优点：功能比较全，UI比较好，而且调用链的跟踪粒度非常细，并且依靠HBase强大的存储能力适合日志量非常庞大的场景
缺点：由于采集信息太过详细所以对性能的损耗最大，并且HBase的维护代价有点大，需要有能力hold住一套HBase集群

四、Skywalking

优点：功能比较全，UI比较好，性能损耗较少，主流中间件和数据库的监控基本都支持
缺点：es强在检索能力但存储能力偏弱

三、Skywalking工作原理

在应用程序中添加 SkyWalking Agent，就可以将接口、服务、数据库、MQ等进行追踪，将追踪结果通过 HTTP 或 gRPC 发送到 OAPServer，经过分析和聚合，将结果存储到 Elasticsearch 或 H2，SkyWalking 同时提供了一个 SkyWalking UI 的可视化界面，UI 以 GraphQL + HTTP 方式获取存储数据进行展示。

配置中心比较Apollo与Nacos_appollo 和 nacos-CSDN博客