前言
本次调研的背景是因为现有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次服务调用。
![](https://i-blog.csdnimg.cn/blog_migrate/fc7deea14e9f532e8b6034dce505e1d1.png)
点击其中任意一个trace,可以看到请求链路上不同span所花费的时间。
![](https://i-blog.csdnimg.cn/blog_migrate/95547275a87eae866fa4bbd863546599.png)
进入Dependencies页面,还可以看到服务之间的依赖关系。
![](https://i-blog.csdnimg.cn/blog_migrate/93a24f57f3957df7f024ea764cb78299.png)
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