前言
本次调研的背景是因为现有APM系统暂时没有适合现有项目的分布式链路追踪的完备功能，故对当下比较流行的链路追踪技术进行调研。本次调研了SpringCloud Sleuth、推特的zipkin、韩国团队naver团队开源的pinpoint。
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页面，还可以看到服务之间的依赖关系。
1、zipkin的通信方式有两种，http与mq两种。上述案例用的是http形式，http形式耗性能，建议整合mq使用
2、zipkin展示的粒度较粗，只能细化到接口级别
3、zipkin能展示每次请求的调用链，可以看到请求链路上不同span所花费的时间，可以展示服务之间调用的拓扑图，
4、spring-cloud-sleuth可以很好的集成zipkin ， 代码无侵入，集成非常简单 ， 社区更加活跃。
5、存储方式支持mysql ， Cassandra （现有资源不支持）， Elasticsearch
6、不支持告警
7、重写默认的采集方式需要对Sleuth源码足够熟悉
PinPoint
1、pinpoint数据分析非常完备的。提供代码级别的可见性以便轻松定位失败点和瓶颈，对于执行的sql语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。
2.对于开发透明，容易开关
对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望功能可以不修改代码就工作并希 望得到代码级别的可见性。
对于这一点，Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是，它要求在需要时修改代码。pinpoint是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。
3.完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构。
相对来说，pinpoint界面显示的更加丰富，具体到调用的DB名，zipkin的拓扑局限于服务于服务之间。
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）、页面展示（自研还是直接用第三方的）。
总结
经过上述分析与比较，我们可以发现，zipkin比较适合于那种对监控粒度没有那么高，且服务数量并不是很多的场景，虽然功能比较单一，但是可以通过Brave进行扩展。Pinpoint