分布式前置数据采集的分析与应用-采样数据的前置处理涉及哪些内容

编辑整理：整理来源：维基百科，浏览量：60，时间：2022-10-23 03:00:01

分布式前置数据采集的分析与应用，现代数据采集系统综述，采样数据的前置处理涉及哪些内容

现在，微服务架构正在变得越来越流行，很多公司都在升级转型为微服务架构。而且，最近面试官在招聘程序员的时候，很可能问到全链路跟踪系统的问题，所以暂时还不懂的小伙伴赶紧学习一下吧。除了应付面试，全链路跟踪系统还是很不错的，非常有用。

在分布式（或微服务）应用系统中，一次前端请求往往会触发一连串、复杂的调用链。例如，用户在访问一个电商网站的时候，前端发出一个请求到电商网站，网站后台收到请求之后，会分别调用商详、活动、频道、广告、促销等服务，然后这些服务又会去进一步调用价格、库存、风控、个性化推荐等服务，再然后，这些服务又有可能进一步调用更底层的服务，形成一个复杂调用链，如下图所示。

除了调用链自身的复杂性以外，网站为应对高并发问题，会把有的服务设置为同步、有的服务设置为异步调用，这进一步增加了调用链的复杂度，导致出现问题后难以定位，系统整体性能难以度量，对系统的整体行为难以把握等。

针对上述问题，Google开发了全链路跟踪系统Google Dapper，并且该项目是开源的。除了Google Dapper之外，市面上还有其他全链路跟踪系统可供选用，例如Zipkin、Pinpoint和Skywalking等，它们大多数都是借鉴自Google Dapper。本文将对比分析Zipkin、Pinpoint和Skywalking这3个系统，如果你对全链路跟踪系统基本概念，例如如何生成调用拓扑图的，或Google Dapper感兴趣，可以参考这篇文章。

Zipkin：Twitter公司开发的开源分布式跟踪系统，可定时收集服务数据，解决微服务架构中的延迟问题，包括数据采集、存储、查询和展示等。

Pinpoint ：这是韩国人开发的大规模分布式跟踪系统。

Skywalking：这是国产分布式跟踪系统，可以对Java应用的运行情况进行追踪、报警和分析等。

本文主要从探针性能、collector扩展性、调用链路数据分析能力、透明性和易用性、调用链拓扑监测能力来对比上述全链路跟踪系统。

1 探针性能

探针(probe)指的是加载到每个应用中的用于收集方法调用数据的agent。探针性能指的是它对服务的吞吐量、CPU性能和内存的影响。通常，微服务的规模越大和动态性越强，数据收集成本就越高，所以我们比较关注探针的性能。

如果启用链路跟踪组件，每个应用就需要加载探针从而执行数据收集任务。如果探针导致吞吐量降低过半，那自然是不能接受的。所以，对Zipkin、Pinpoint、Skywalking进行了压测，并与基线（未使用探针）的情况进行了对比。

选用了一个常见的基于Spring开发的应用程序，包含Spring Boot, Spring MVC，redis客户端，mysql connector等组件。然后，监控这个应用程序。对于每个Trace（解释见此文），探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。

模拟三种并发用户：500线程，750线程，1000线程。使用jmeter测试，每个线程发送30个请求，设置思考时间（请求间的间隔时间）为10ms。使用的采样率为1（即100%）。因为Pinpoint的默认采样率为20（即50%），通过修改agent的配置文件将其改为100%。Zipkin的默认采样率也是1。将以上参数组合起来，一共有12种情况，汇总如下：

从上表可以看出，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中，pinpoint探针对吞吐量的影响较明显。Pinpoint在500并发用户时，吞吐量从1385降低到774，影响很大。然后再看探针对CPU和memory的影响，通过在内部服务器进行压测，发现探针对CPU和memory的影响几乎都在10%以内。

2 collector的扩展性

collector指的是全链路监控系统中用于接收监控数据的组件，它负责从agent接收数据。collector的扩展性使得全链路监控系统能够水平扩展，从而支持更大规模服务器集群。

首先，对于zipkin来说，其zipkin-agent与zipkin-server可以通过http调用或者mq进行通信。因为http的通信方式会对正常访问产生影响（例如阻塞、建立连接然后断开等），所以推荐使用基于mq的异步方式通信（如下图），让zipkin-server通过订阅topic接收zipkin-agent发送过来的数据。MQ异步通信的方式当然是可扩展的，可以部署多个zipkin-server实例进行异步消费，得到监控信息。所以，zipkin方案的collector（即zipkin-server）是支持扩展性的。

然后，对于skywalking来说，其collector支持两种部署方式，单机模式和集群模式。collector与agent之间使用gRPC方式进行通信。所以，skywalking也支持扩展性。

最后，pinpoint也是支持单机部署和集群部署两种的，所以它也支持扩展性。pinpoint agent通过thrift通信框架，把链路信息发送到collector。

总的说来，这3种全链路监控系统都支持扩展性，只是通信方式不同。Zipkin支持http和mq的通信方式，pinpoint支持thrift通信，而skywalking支持gRPC通信方式。区别就在于这些通信方式上有差异，最后都能保证扩展性。

3 调用链路数据分析能力

这方面的能力指的是它是否提供代码级别的可见性以便轻松定位故障和瓶颈。例如，当我们在系统中发现一个bug，而且这个bug涉及到多个团队，我们怎么根据全链路监控系统提供的追踪信息快速得定位问题（如果没有全链路系统，团队之间可能互相甩锅，排查问题很麻烦）。

Zipkin的数据分析界面如下图所示。可以看到，zipkin的链路监控粒度相对没有那么细，调用链只到达接口级别，再进一步的调用信息并未涉及。

skywalking 的数据分析界面截图如下，另外，它还支持20+的中间件、框架、类库等，包括dubbo、Okhttp、DB和消息中间件等。图中的调用链路比较简单，即网关调用user服务，由于skywalking支持众多的中间件，所以skywalking链路调用分析比zipkin更多完备。

pinpoint是这三种全链路监控系统中数据分析功能最完备的。它提供代码级别的可见性，可以很轻松定位故障问题和性能瓶颈等。从下图可以看到对于每条所执行的sql语句，它都做了记录。pinpoint还可以配置报警规则等，设置每个应用的负责人，根据规则报警，支持的中间件和框架也比较完备。

4 透明性和易用性

除了上面提到的探针性能、collector扩展性和数据分析能力之外，这里的透明性和易用性主要是指监控系统使用起来是否方便，没有前面3方面性能那么重要。这里的透明性和易用性指的是添加新功能是否无需修改代码，容易启用或禁用。

对开发人员透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望可以不修改代码就让全链路监控系统生效，并得到代码级别的可见性。对于这一点，Zipkin 使用修改过的类库和自己的容器(Finagle)来提供分布式事务跟踪功能。但是，zipkin要求在需要时修改代码，透明性不够好。skywalking和pinpoint都是基于字节码增强方式运行的，开发人员不需要修改代码，并且可以收集到更精确的调用数据。

5 调用链拓扑监测能力

这方面的能力指是否可以自动检测应用的调用拓扑关系，帮助我们弄清应用架构。

Pinpoint生成的调用链拓扑图如下

Skywalking生成的调用链拓扑图如下

Zipkin生成的调用量拓扑图如下

上面三幅图，分别展示了3个系统各自的调用拓扑结构，说明它们都能自动检测出完整的调用链拓扑。相对来说，pinpoint界面显示更加丰富，可以具体到调用的数据库名，而zipkin的拓扑只限于在服务于服务之间的调用。

6. 进一步比较Pinpoint和Zipkin

Pinpoint 是一个比较完整的性能监控解决方案，它具有从探针、收集器、存储到 Web 界面等全套体系；而 Zipkin 只侧重收集器和存储服务，虽然也有用户界面，但功能与 Pinpoint 相比不可同日而语。但是，Zipkin 提供了 Query 接口，可以基于该接口开发出更强大的界面和系统集成能力。

Zipkin 官方提供基于 Finagle 框架（Scala 语言）的接口，而其他框架的接口由社区贡献，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架；Pinpoint 目前只有官方提供的 Java Agent 探针，其他的都在请求社区开发支持。

Pinpoint 提供有Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，无需修改代码，只需要在启动的时候添加参数就可以部署探针；Zipkin 的 Java 接口实现的Brave框架只提供基本操作 API，如果需要与项目集成，需要添加配置文件或增加代码。

Pinpoint 与 Zipkin 的理论基础相同，都是将服务调用拆分成若干个有级联关系的 Span，通过 SpanId 和 ParentSpanId 来进行调用关系的级联；最后再将整个调用链所经过的所有的Span 汇聚成一个 Trace，报告给服务端。不过，Pinpoint的概念与Google Dapper论文不完全一致。例如它用 TransactionId 取代 TraceId，而真正的 TraceId 是一个结构，里面包含TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 下面增加了一个 SpanEvent 结构，用来记录一个 Span 的内部调用细节（具体的方法调用等），因此 Pinpoint 比 Zipkin 能记录更多跟踪数据。

根据前面的比较，可以认为Pinpoint 目前具有压倒性优势。因为它无需对项目代码进行任何修改就可以部署探针、追踪数据，并且粒度细化到方法调用级别、用户界面功能强大以及几乎全面支持 Java 框架，但是缺点是对性能的影响较大。但是长远来看，学习 Pinpoint 的开发接口，以及未来为不同的框架实现接口的成本都还是个未知数。相反，掌握 Brave 就相对容易，而且 Zipkin 的社区更加强大，有可能在未来开发出更多接口。在最坏情况下，我们也可以自己通过 AOP 的方式添加适合我们自己的监控代码，不需要引入太多新技术和新概念。而且在业务发生变化的时候，Pinpoint 官方提供的报表是否能满足要求也不好说，增加新的报表也会带来不可以预测的工作难度和工作量。

以上我们比较分析了Zipkin、Pinpoint和Skywalking这3种分布式跟踪系统，希望对您的工作和跳槽面试都有所帮助。另外，如果对互联网技术、Android、Java、C/C++、Linux、个性化推荐、Community Detection、Machine Learning、Deep Learning、Data Mining、Gnuplot、甚至LaTeX等技术均感兴趣的话，欢迎关注本公众号，本公众号不限于Java编程。

行业热门话题：

【前置数据采集子系统】【采样数据的前置处理涉及哪些内容】【现代数据采集系统综述】