链路追踪 研究01 选型

一、全链路追踪工具

​1、Zipkin​

  Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。

​2、Pinpoint​

  韩国人开源的基于​​字节码​​注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。

​3、SkyWalking​

  本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。

​4、CAT​

  大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

二、工具对比

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，

在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，

对CPU和memory的影响都差不多在10%之内。

分布式调用跟踪系统的设计

（1）分布式调用跟踪系统的设计目标

低侵入性，应用透明：作为非业务组件，应当尽可能少侵入或者无侵入其他业务系统，对于使用方透明，减少开发人员的负担

低损耗：服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径

大范围部署，扩展性：作为分布式系统的组件之一，一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性

（2）埋点和生成日志

埋点即系统在当前节点的上下文信息，可以分为客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容：

TraceId、RPCId、调用的开始时间，调用类型，协议类型，调用方ip和端口，请求的服务名等信息；

调用耗时，调用结果，异常信息，消息报文等；

预留可扩展字段，为下一步扩展做准备；

（3）抓取和存储日志

日志的采集和存储有许多开源的工具可以选择，一般来说，会使用离线+实时的方式去存储日志，主要是分布式日志采集的方式。典型的解决方案如Flume结合Kafka等MQ。

（4）分析和统计调用链数据

一条调用链的日志散落在调用经过的各个服务器上，首先需要按 TraceId 汇总日志，然后按照RpcId 对调用链进行顺序整理。用链数据不要求百分之百准确，可以允许中间的部分日志丢失。

（5）计算和展示

汇总得到各个应用节点的调用链日志后，可以针对性的对各个业务线进行分析。需要对具体日志进行整理，进一步储存在HBase或者关系型数据库中，可以进行可视化的查询。

链路跟踪Trace模型

一次典型的分布式调用过程，如下图所示:

Trace调用模型，主要有以下概念：

Trace：一次完整的分布式调用跟踪链路。

Span： 追踪服务调基本结构，表示跨服务的一次调用； 多span形成树形结构，组合成一次Trace追踪记录。

Annotation：在span中的标注点，记录整个span时间段内发生的事件。

BinaryAnnotation：可以认为是特殊的Annotation，用户自定义事件。

Annotation类型：保留类型

Cs CLIENT_SEND，客户端发起请求

Cr CLIENT_RECIEVE，客户端收到响应

Sr SERVER_RECIEVE，服务端收到请求

Ss SERVER_SEND，服务端发送结果

用户自定义类型：

Event 记录普通事件

Exception 记录异常事件

Client && Server：对于跨服务的一次调用，请求发起方为client，服务提供方为server

各术语在一次分布式调用中，关系如下图所示：

调用跟踪系统的选型

   大的互联网公司都有自己的分布式跟踪系统，比如Google的Dapper，Twitter的zipkin，淘宝的鹰眼，新浪的Watchman，京东的Hydra等，下面来简单分析。

Google的Drapper

Dapper是Google生产环境下的分布式跟踪系统，Dapper有三个设计目标：

低消耗：跟踪系统对在线服务的影响应该做到足够小。

应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统显然是侵入性太强的。

延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。

处理分为3个阶段：

①各个服务将span数据写到本机日志上；

②dapper守护进程进行拉取，将数据读到dapper收集器里；

③dapper收集器将结果写到bigtable中，一次跟踪被记录为一行。

阿里-鹰眼

关于淘宝的鹰眼系统，主要资料来自于内部分享：

鹰眼埋点和生成日志：

如何抓取和存储日志，记录本地文件，使用额外的后台进程定期（时间间隔小）收集日志。这种方式的优势在于对应用的性能影响小，方便做消息堆积；但是需要在每台业务server上都部署并管理日志收集agent，运维量比较大。

鹰眼的实现小结：

注意Dapper与Eagle eye都不开源。

阿里EDAS+ARMS的立体化监控体系

   通过阿里云提供的EDAS结合ARMS可以打造立体化监控体系，其中EDAS用于应用管控层面，用于控制链路和应用；而ARMS更关注业务运营层面，如电商交易、车联网、零售；实际上，监控需要全方位关注业务、链路、应用、系统，通过ARMS与EDAS相互补全，形成了立体化监控体系。

大众点评——CAT

架构简单。可以实现一个Trace系统的所有功能。架构如下图所示：

跟踪模型

Transaction是最重要的事件消息类型，适合记录跨越系统边界的程序访问行为,比如远程调用，数据库调用，也适合执行时间较长的业务逻辑监控，记录次数与时间开销。Transaction可嵌套。

跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源。

客户端接入方式

对于方法调用、sql、url请求等粒度较小的兴趣点，需要业务人员手写代码实现。

日志收集方式

直接向日志收集器发异步请求（有本地内存缓存），一台客户端会连向几个服务端，当一个服务端出问题，数据不会丢失。

当所有服务端都挂掉，消息会存入queue，当queue满了，就丢弃了，没有做数据存储本地等工作。

全量采样，系统繁忙的时候对性能影响较大（可能达到10%的影响）

最后一个稳定版本是2014年1月，之后已经失去维护。

京东-hydra

   与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加。架构如下：

Hydra中跟踪数据模型

Trace: 一次服务调用追踪链路。

Span: 追踪服务调基本结构，多span形成树形结构组合成一次Trace追踪记录。

Annotation: 在span中的标注点，记录整个span时间段内发生的事件。

BinaryAnnotation: 属于Annotation一种类型和普通Annotation区别，这键值对形式标注在span中发生的事件，和一些其他相关的信息。

日志收集方式

与CAT类似。支持自适应采样，规则粗暴简单，对于每秒钟的请求次数进行统计，如果超过100，就按照10%的比率进行采样。

开源项目已于2013年6月停止维护。

Twitter—OpenZipkin

功能、数据跟踪模型与hydra类似。Zipkin本身不开源，开源社区的是另外一套scala实现，依托于finagle这个RPC框架。架构如下：

Zipkin与其他Trace系统的不同之处在于：

Zipkin中针对 HttpClient、jax-rs2、jersey/jersey2等HTTP客户端封装了拦截器。可以在较小的代码侵入条件下实现URl请求的拦截、时间统计和日志记录等操作。

日志收集

Cat是直接将日志发往消费集群；hydra是发给日志收集器，日志收集器推到消息队列；Zipkin的client将统计日志发往消息队列，日志收集器读取后落地存储；Dapper和Eagle eye是记录本地文件，后台进程定期扫描。

Trace系统现状分析

   以上几款链路跟踪系统都各自满足了请求链路追踪的功能，但落实到我们自己的生产环境中时，这些Trace系统存在诸多问题：Google和alibaba的Trace系统不开源，但现阶段来说阿里是做得最好的，如果用的是阿里的服务器，可考虑直接用阿里的追踪系统以节省开发代价；

   京东和点评的虽然开源，但是已经多年没有维护，项目依赖的jdk版本以及第三方框架过于陈旧等等，不适合用在生产环境中；

   Twitter的OpenZipkin使用scala开发，而且其实现基于twitter内部的RPC框架finagle，第三方依赖比较多，接入和运维的成本非常高。

   如果不是用阿里的服务，我们可以借鉴这些开源实现的思想, 自行开发Trace系统。那是自己从0开始开发还是基于开源方案二次开发？ 这里面也要考虑到跨平台，如NET和java环境，尽量减少原系统的侵入性或只需要更改少量的代码即可接入，在这里可以基于zipkin和pinpoint进行二次开发，功能可参考阿里的系统。

Zipkin 和 Pinpoint 选型对比

   Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文，因此理论基础大致相同。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 的后端存储基于 HBase，而 Zipkin 基于 Cassandra。

接入难度

   因为 Brave 的注入需要依赖底层框架提供相关接口，因此并不需要对框架有一个全面的了解，只需要知道能在什么地方注入，能够在注入的时候取得什么数据就可以了。就像上面的例子，我们根本不需要知道 MySQL 的 JDBC Driver 是如何实现的也可以做到拦截 SQL 的能力。但是 Pinpoint 就不然，因为 Pinpoint 几乎可以在任何地方注入任何代码，这需要开发人员对所需注入的库的代码实现有非常深入的了解，通过查看其 MySQL 和 Http Client 插件的实现就可以洞察这一点，当然这也从另外一个层面说明 Pinpoint 的能力确实可以非常强大，而且其默认实现的很多插件已经做到了非常细粒度的拦截。

   针对底层框架没有公开 API 的时候，其实 Brave 也并不完全无计可施，我们可以采取 AOP 的方式，一样能够将相关拦截注入到指定的代码中，而且显然 AOP 的应用要比字节码注入简单很多。

   以上这些直接关系到实现一个监控的成本，在 Pinpoint 的官方技术文档中，给出了一个参考数据。如果对一个系统集成的话，那么用于开发 Pinpoint 插件的成本是 100，将此插件集成入系统的成本是 0；但对于 Brave，插件开发的成本只有 20，而集成成本是 10。从这一点上可以看出官方给出的成本参考数据是 5:1。但是官方又强调了，如果有 10 个系统需要集成的话，那么总成本就是 10 * 10 + 20 = 120，就超出了 Pinpoint 的开发成本 100，而且需要集成的服务越多，这个差距就越大。

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

   最后还要考虑日志收集（直接发送、记录到本地再上传）、日志接收（消息队列，直接进入ElasticSearch）、数据清洗（Logstach、Storm、SparkStreaming）、日志存储（Mysql、Hbase、ElasticSearch）、页面展示（自研还是直接用第三方的）。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Spring Cloud Sleuth + zipkin

Spring Cloud Slueth和zipkin之间的关系是什么？

本质上 Spring Cloud Slueth 与 Pinpoint 没有可比性，真正对比的是Zipkin，Spring Cloud Slueth 聚焦在链路追踪和分析，将信息发送到Zipkin，利用 Zipkin的存储来存储信息，当然，Zipkin也可以使用ELK来记录日志和展示，再通过收集服务器性能的脚本把数据存储到ELK，则可以展示服务器状况信息了。Zipkin的总体展示，也是基于链路分析为主。

当采用这种方式进行监控的时候，需要对要监控的项目增加sleuth与zipkin依赖，还需要创建一个zipkin-ui工程用于展示采集的数据，创建之后还要在每个需要监控的项目中指定zipkin的服务地址配置。

访问前端应用3次，页面显示3次服务调用。

点击其中任意一个trace，可以看到请求链路上不同span所花费的时间。

进入Dependencies页面，还可以看到服务之间的依赖关系。

Zipkin 和 Pinpoint 选型对比

Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文，因此理论基础大致相同。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 的后端存储基于 HBase，而 Zipkin 基于 Cassandra。

1、zipkin的通信方式有两种，http与mq两种。上述案例用的是http形式，http形式耗性能，建议整合mq使用

2、zipkin展示的粒度较粗，只能细化到接口级别

3、zipkin能展示每次请求的调用链，可以看到请求链路上不同span所花费的时间，可以展示服务之间调用的拓扑图，

4、spring-cloud-sleuth可以很好的集成zipkin ， 代码无侵入，集成非常简单 ， 社区更加活跃。

5、存储方式支持mysql ， Cassandra （现有资源不支持）， Elasticsearch

6、不支持告警

7、重写默认的采集方式需要对Sleuth源码足够熟悉

接入难度

因为 Brave 的注入需要依赖底层框架提供相关接口，因此并不需要对框架有一个全面的了解，只需要知道能在什么地方注入，能够在注入的时候取得什么数据就可以了。就像上面的例子，我们根本不需要知道 MySQL 的 JDBC Driver 是如何实现的也可以做到拦截 SQL 的能力。但是 Pinpoint 就不然，因为 Pinpoint 几乎可以在任何地方注入任何代码，这需要开发人员对所需注入的库的代码实现有非常深入的了解，通过查看其 MySQL 和 Http Client 插件的实现就可以洞察这一点，当然这也从另外一个层面说明 Pinpoint 的能力确实可以非常强大，而且其默认实现的很多插件已经做到了非常细粒度的拦截。

针对底层框架没有公开 API 的时候，其实 Brave 也并不完全无计可施，我们可以采取 AOP 的方式，一样能够将相关拦截注入到指定的代码中，而且显然 AOP 的应用要比字节码注入简单很多。

以上这些直接关系到实现一个监控的成本，在 Pinpoint 的官方技术文档中，给出了一个参考数据。如果对一个系统集成的话，那么用于开发 Pinpoint 插件的成本是 100，将此插件集成入系统的成本是 0；但对于 Brave，插件开发的成本只有 20，而集成成本是 10。从这一点上可以看出官方给出的成本参考数据是 5:1。但是官方又强调了，如果有 10 个系统需要集成的话，那么总成本就是 10 * 10 + 20 = 120，就超出了 Pinpoint 的开发成本 100，而且需要集成的服务越多，这个差距就越大。

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

最后还要考虑日志收集（直接发送、记录到本地再上传）、日志接收（消息队列，直接进入ElasticSearch）、数据清洗（Logstach、Storm、SparkStreaming）、日志存储（Mysql、Hbase、ElasticSearch）、页面展示（自研还是直接用第三方的）。

总结

经过前面对skywalking和Pinpoint全方位对比后我们发现，对于两款非常优秀的APM软件，有一种既生瑜何生亮的感觉。Pinpoint的优势在于：追踪数据粒度非常细、功能强大的用户界面，以及使用HBase作为存储带来的海量存储能力。而skywalking的优势在于：非常活跃的中文社区，支持多种语言的探针，对国产开源软件非常全面的支持，以及使用es作为底层存储带来的强大的检索能力，并且skywalking的扩展性以及定制化要更优于Pinpoint：

三、性能对比