分布式服务调用链路追踪——方案选型

 

前言

目前大多数分布式追踪系统的思想模型都来自 Google's Dapper 论文。

全链路追踪工具一览:

  • Drapper(google--未开源):最早的APM;
  • 鹰眼(阿里--未开源):
  • CAT(大众点评--开源):跨服务的跟踪功能与点评内部的RPC框架集成,这部分未开源且项目在2014.1已经停止维护。服务粒度的监控,通过代码埋点的方式来实现监控,比如: 拦截器,注解,过滤器等,对代码的侵入性较大,集成成本较高;
  • Hydra(京东):与dubbo框架集成,对于服务级别的跟踪统计,现有业务可以无缝接入。对于细粒度的兴趣点,需要业务人员手动添加.开源项目已于2013年6月停止维护;
  • PinPoint(naver--开源):字节码探针技术,代码无侵入,体系完善不易修改,支持java,技术栈支持dubbo.其他语言社区支援中;
  • Zipkin(Twitter--开源):方便集成于spring cloud sleuth,社区支持的插件也包括dubbo,rabbit,mysql,httpclient等,同时支持php,go,js等语言客户端,界面功能较为简单,本身无告警功能,可能需要二次开发。代码入侵度小;
  • Uber-jaeger:Jaeger支持java/c++/go/node/php,在界面上较为完善(对比zipkin),但是也无告警功能。代码入侵度小。dubbo目前无插件支持,可二次开发;
  • Skywalking(华为--开源):类似于PinPoint,目前还在apache孵化中,网上吞吐量对比中强于pinpoint,实际未验证。本身支持dubbo;

全链路追踪的核心思想:

  • 为每条请求都单独分配一个唯一的 traceId 用来标识一条请求链路,该 traceId 会贯穿整个请求处理过程的所有服务。
  • 每个服务/线程都拥有自己的 spanId 标识,代表请求的其中一段处理步骤。
  • 一个请求包含一个 traceId 和一个或多个 spanId。

本文重点关注以下三种 APM 组件:

  • Zipkin:由Twitter公司开源的调用链分析工具,目前基于springcloud sleuth得到了广泛的使用,特点是轻量,使用部署简单。
  • Pinpoint:一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪组件,特点是支持多种插件,UI功能强大,接入端无代码侵入。
  • Skywalking:是本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器。

 

1. 方案比较

主要从以下几个维度来对比三种组件:

  • 探针的性能

    主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。

  • 对应用的入侵性

    对应用是否有入侵性。

  • collector的可扩展性

    能够水平扩展以便支持大规模服务器集群。

  • 全面的调用链路数据分析

    提供代码级别的可见性以便轻松定位失败点和瓶颈。

  • 对于开发透明,容易开关

    添加新功能而无需修改代码,容易启用或者禁用。

  • 完整的调用链应用拓扑

    自动检测应用拓扑,帮助你搞清楚应用的架构。

 

1.1 探针的性能

摘自:https://juejin.im/post/5a7a9e0af265da4e914b46f1

比较关注探针的性能,毕竟 APM 定位还是工具,如果启用了链路监控组件后,直接导致吞吐量降低过半,那也是不能接受的。

对 skywalking、zipkin、pinpoint 进行了压测,并与基线(未使用探针)的情况进行了对比。

选用了一个常见的基于 Spring 的应用程序,包含 Spring Boot, Spring MVC,redis客户端,mysql。监控这个应用程序,每个trace,探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。

这边基本和 skywalkingtest 的测试应用差不多。

模拟了三种并发用户:500,750,1000。使用jmeter测试,每个线程发送30个请求,设置思考时间为10ms。使用的采样率为1,即100%,这边与生产可能有差别。

pinpoint默认的采样率为20,即50%,通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来,一共有12种。下面看下汇总表:

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

测试服务的吞吐量从1385降低到774,影响很大。然后再看下CPU和memory的影响,在内部服务器进行的压测,对CPU和memory的影响都差不多在10%之内。

 

1.2 对应用的入侵性

  • zipkin

 没有采用javaagent方式,应用强依赖ZipKin,必须打包到应用中与应用一起运行,每个项目需要添加依赖项、配置,不同探针有不同的bean配置需求;

  • skywalking

采用javaagent方式,普通功能对应用无侵入,以下两项功能需要应用稍作修改:

    • 中添加自定义Tag项:应用代码在SkyWalking Span中添加自定义Tag,可以按需输出方法参数值等关键信息,辅助应用排错和性能分析,PinPointZipKin都不支持(可自行实现);
    • 日志中输出全局跟踪ID,需要添加SkyWalking依赖项;
  • pinpoint

采用javaagent方式,对应用完全无侵入,项目无需添加任何额外依赖项,无需修改代码,这点做得最好;

 

1.3 collector的可扩展性

collector的可扩展性,使得能够水平扩展以便支持大规模服务器集群。

  • zipkin

开发 zipkin-Server(其实就是提供的开箱即用包),zipkin-agent 与 zipkin-Server 通过 http 或者 mq 进行通信,http 通信会对正常的访问造成影响,

所以还是推荐基于mq异步方式通信,zipkin-Server 通过订阅具体的 topic 进行消费。这个当然是可以扩展的,多个 zipkin-Server 实例进行异步消费 mq 中的监控信息。

  • skywalking

skywalking的collector支持两种部署方式:单机和集群模式。collector与agent之间的通信使用了gRPC

当你使用-javaagent参数激活sky-walking的探针, 如果当前上下文中存在traceid,logback将在输出traceId

如果探针没有被激活,将输出TID: N/A.而且SkyWalking是基于字节码增强的,traceId的传递依赖于SkyWalking的服务端,

如果服务端异常等客户端连接不上服务端的情况,就会出现TID: [Ignored Trace]的情况,就会丢失traceId。

  • pinpoint

pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架,发送链路信息到collector。

 

1.4 全面的调用链路数据分析

全面的调用链路数据分析,提供代码级别的可见性以便轻松定位失败点和瓶颈。

  • zipkin

zipkin 的链路监控粒度相对没有那么细,从下图可以看到调用链中具体到接口级别,再进一步的调用信息并未涉及。

  • skywalking

skywalking 支持20+的中间件、框架、类库,比如:主流的dubbo、Okhttp,还有DB和消息中间件。

下图skywalking链路调用分析截取的比较简单,网关调用user服务,由于支持众多的中间件,所以skywalking链路调用分析比zipkin完备些。

  • pinpoint

pinpoint应该是这三种APM组件中,数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈,下图可以看到对于执行的sql语句,都进行了记录。

还可以配置报警规则等,设置每个应用对应的负责人,根据配置的规则报警,支持的中间件和框架也比较完备。

 

1.5 对于开发透明,容易开关

对于开发透明,容易开关,添加新功能而无需修改代码,容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。

对于这一点,Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是,它要求在需要时修改代码。

skywalking和pinpoint都是基于字节码增强的方式,开发人员不需要修改代码,并且可以收集到更多精确的数据因为有字节码中的更多信息。

 

1.6 完整的调用链应用拓扑

自动检测应用拓扑,帮助你搞清楚应用的架构。

下面三幅图,分别展示了APM 组件各自的调用拓扑,都能实现完整的调用链应用拓扑。相对来说,pinpoint 界面显示的更加丰富,具体到调用的DB名,zipkin的拓扑局限于服务于服务之间。

  • zipkin

  • skywalking

  • pingpoint

1.7 Pinpoint与Zipkin细化比较

  • Pinpoint与Zipkin差异性

1、Pinpoint 是一个完整的性能监控解决方案:有从探针、收集器、存储到 Web 界面等全套体系;而 Zipkin 只侧重收集器和存储服务,虽然也有用户界面,但其功能与 Pinpoint 不可同日而语。

      反而 Zipkin 提供有 Query 接口,更强大的用户界面和系统集成能力,可以基于该接口二次开发实现。

2、Zipkin 官方提供有基于 Finagle 框架(Scala 语言)的接口,而其他框架的接口由社区贡献,目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架;

      但是 Pinpoint 目前只有官方提供的 Java Agent 探针,其他的都在请求社区支援中(请参见 #1759 和 #1760)。

3、Pinpoint 提供有 Java Agent 探针,通过字节码注入的方式实现调用拦截和数据收集,可以做到真正的代码无侵入,只需要在启动服务器的时候添加一些参数,就可以完成探针的部署;

      而 Zipkin 的 Java 接口实现 Brave,只提供了基本的操作 API,如果需要与框架或者项目集成的话,就需要手动添加配置文件或增加代码。

4、Pinpoint 的后端存储基于 HBase,而 Zipkin 基于 Cassandra。

  • Pinpoint 与 Zipkin 相似性

Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文,因此理论基础大致相同。两者都是将服务调用拆分成若干有级联关系的 Span,通过 SpanId 和 ParentSpanId 来进行调用关系的级联;

最后再将整个调用链流经的所有的 Span 汇聚成一个 Trace,报告给服务端的 collector 进行收集和存储。

即便在这一点上,Pinpoint 所采用的概念也不完全与那篇论文一致。比如他采用 TransactionId 来取代 TraceId,而真正的 TraceId 是一个结构,里面包含了 TransactionId, SpanId 和 ParentSpanId。

而且 Pinpoint 在 Span 下面又增加了一个 SpanEvent 结构,用来记录一个 Span 内部的调用细节(比如具体的方法调用等等),因此 Pinpoint 默认会比 Zipkin 记录更多的跟踪数据。

但是理论上并没有限定 Span 的粒度大小,所以一个服务调用可以是一个 Span,那么每个服务中的方法调用也可以是个 Span,

这样的话,其实 Brave 也可以跟踪到方法调用级别,只是具体实现并没有这样做而已。

  • 字节码注入 vs API 调用

Pinpoint 实现了基于字节码注入的 Java Agent 探针,而 Zipkin 的 Brave 框架仅仅提供了应用层面的 API,但是细想问题远不那么简单。

字节码注入是一种简单粗暴的解决方案,理论上来说无论任何方法调用,都可以通过注入代码的方式实现拦截,也就是说没有实现不了的,只有不会实现的。

但 Brave 则不同,其提供的应用层面的 API 还需要框架底层驱动的支持,才能实现拦截。

比如,MySQL 的 JDBC 驱动,就提供有注入 interceptor 的方法,因此只需要实现 StatementInterceptor 接口,并在 Connection String 中进行配置,就可以很简单的实现相关拦截;

而与此相对的,低版本的 MongoDB 的驱动或者是 Spring Data MongoDB 的实现就没有如此接口,想要实现拦截查询语句的功能,就比较困难。

因此在这一点上,Brave 是硬伤,无论使用字节码注入多么困难,但至少也是可以实现的,

但是 Brave 却有无从下手的可能,而且是否可以注入,能够多大程度上注入,更多的取决于框架的 API 而不是自身的能力。

  • 难度及成本

经过简单阅读 Pinpoint 和 Brave 插件的代码,可以发现两者的实现难度有天壤之别。在都没有任何开发文档支撑的前提下,Brave 比 Pinpoint 更容易上手。

Brave 的代码量很少,核心功能都集中在 brave-core 这个模块下,一个中等水平的开发人员,可以在一天之内读懂其内容,并且能对 API 的结构有非常清晰的认识。

Pinpoint 的代码封装也是非常好的,尤其是针对字节码注入的上层 API 的封装非常出色,但是这依然要求阅读人员对字节码注入多少有一些了解,

虽然其用于注入代码的核心 API 并不多,但要想了解透彻,恐怕还得深入 Agent 的相关代码,

比如很难一目了然的理解 addInterceptor 和 addScopedInterceptor 的区别,而这两个方法就是位于 Agent 的有关类型中。

因为 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 完全处于劣势,从社区所开发出来的集成接口就可见一斑。

Pinpoint 的数据接口缺乏文档,而且也不太标准(参考论坛讨论帖),需要阅读很多代码才可能实现一个自己的探针(比如 Node 的或者 PHP 的)。

而且团队为了性能考虑使用了 Thrift 作为数据传输协议标准,比起 HTTP 和 JSON 而言难度增加了不少。

  • 社区支持

这一点也不必多说,Zipkin 由 Twitter 开发,可以算得上是明星团队,而 Naver 的团队只是一个默默无闻的小团队(从 #1759 的讨论中可以看出)。

虽然说这个项目在短期内不太可能消失或停止更新,但毕竟不如前者用起来更加放心。

而且没有更多社区开发出来的插件,让 Pinpoint 只依靠团队自身的力量完成诸多框架的集成实属困难,而且他们目前的工作重点依然是在提升性能和稳定性上。

  • 其他

Pinpoint 在实现之初就考虑到了性能问题,www.naver.com 网站的后端某些服务每天要处理超过 200 亿次的请求,因此他们会选择 Thrift 的二进制变长编码格式、

而且使用 UDP 作为传输链路,同时在传递常量的时候也尽量使用数据参考字典,传递一个数字而不是直接传递字符串等等。

这些优化也增加了系统的复杂度:包括使用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等。

相比之下,Zipkin 使用熟悉的 Restful 接口加 JSON,几乎没有任何学习成本和集成难度,只要知道数据传输结构,就可以轻易的为一个新的框架开发出相应的接口。

另外 Pinpoint 缺乏针对请求的采样能力,显然在大流量的生产环境下,不太可能将所有的请求全部记录,这就要求对请求进行采样,以决定什么样的请求是我需要记录的。

Pinpoint 和 Brave 都支持采样百分比,也就是百分之多少的请求会被记录下来。但是,除此之外 Brave 还提供了 Sampler 接口,可以自定义采样策略,尤其是当进行 A/B 测试的时候,这样的功能就非常有意义了。

  • 总结

从短期目标来看,Pinpoint 确实具有压倒性的优势:无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。

但是长远来看,学习 Pinpoint 的开发接口,以及未来为不同的框架实现接口的成本都还是个未知数。

相反,掌握 Brave 就相对容易,而且 Zipkin 的社区更加强大,更有可能在未来开发出更多的接口。在最坏的情况下,

我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码,而并不需要引入太多的新技术和新概念。

而且在未来业务发生变化的时候,Pinpoint 官方提供的报表是否能满足要求也不好说,增加新的报表也会带来不可以预测的工作难度和工作量。

 

1.8 Pinpoint与Skywalking细化比较

首先,上个别人的研究成果,我也是踩着巨人的肩膀继续前进的。

随着pinpoint版本的迭代更新,这图上的结论有些已经过时了,比如pinpoint方面:

  1. 协议,最新2.2.2版本也是默认使用gRPC的;
  2. TraceId查询,最新2.2.2版本也是支持的;
  3. 发布包,最新2.2.2版本同样也是采用jar包部署的;
  4. 异步跟踪执行,最新2.2.2版本也已经支持了;

接着说我们今天具体要对比的内容:

  • UI比较

pinpoint的UI看上去更加的美观、友好、方便,pinpoint确实胜skywalking好几分,来两张图,各位看官自己比较。

  • 跟踪粒度

看完了外观,我们再来对比下它们各自的内功,毕竟这类工具是要干活的,光当花瓶没有用,关键时候得派的上用场才行。

同样,我们先上两张图,来看看pinpoint和skywalking的跟踪粒度如何。

可以看出pinpoint可以监控到每个链路过程的耗时情况,包括SQL执行耗时、第三方服务响应耗时等,甚至连SQL的变量参数都跟踪出来了。

而skywalking只监控到了接口耗时,并没有监控更多一点的链路耗时信息,有群友告知说skywalking能监控到方法级,但是需要侵入代码,在每个要跟踪的方法上面加注解,

所以我直接放弃了,因为这样的代价实在太大了点。而且即使监控到方法级,也只能知道哪个方法慢了,方法下面可能还有数据库调用、第三方方法调用等,还是没法定位出真正的问题。

所以skywalking这款APM监控工具,个人理解,更多地是用来监控接口响应耗时并提出告警,至于具体的性能问题嘛,只能通过其他手段再进一步定位了。

所以,在监控粒度上面,skywalking差pinpoint不是一点半点,这是差了好几个量级啊。

  • JVM监控

接下来我们再来对比下这类APM工具的另外一个非常好用的功能,监控JVM。

这边就简单罗列下它们都能监控到那些JVM指标

从上面对比结果来看,pinpoint在JVM监控方面要更强大得多,比如对Thread、Open File Descriptor、Data Source的支持,尤其是Data Source,实在是太方便了,数据库连接池的使用情况一目了然。

而skywaling的唯一得分点,是支持GC指标的查看。

  • 性能损耗

既然pinpoint跟踪粒度比skywalking详细了好几个量级,那么对应地,它的性能损耗是否要大得多呢?翻看有些网友(比如下面参考链接)的测试结果,

pinpoint的性能损耗可以达到50%左右,这也太恐怖了,但是根据官方宣传,它的性能损耗是在3%以内的,那么到底谁是靠谱的呢?

本人平时都是开着APM在做压测的,并没有感觉会有很大的性能损耗,总体损耗应该在8%以内,并且性能测试结果指标还都蛮OK的,所以,对于性能损耗这块,我对pinpoint还是挺有信心的。

贴个官方性能损耗说明:

  • 总结

主要从UI、跟踪粒度、JVM监控这三个方面对pinpoint和skywalking做了个人使用体验上的对比,从对比结果来看,pinpoint无论在操作简便性还是性能问题定位上,还是要优胜于skywalking的。

毕竟作为一款APM工具,能够更好更快更全面地发现性能问题,才是它们最大的价值所在。

也可能是我对skywalking了解的还太肤浅,还没发现skywalking真正的强大和美好。各位如果持有不同看法和意见的,欢迎留言探讨。

 

2. 方案总结

基本

方案

扩展性

实现方式

代码侵入性

性能损失

传输协议

客户端支持

存储

skywalking

java探针
字节码注入

部分侵入(生成TraceId)

gRPC Java, .NET, PHP等 es,mysql,H2,TIDB

sleuth+zipkin

拦截请求

侵入(强依赖zipkin)

Http,MQ java,c#,go,php等 es,mysql,cassandra,内存

pingpoint

java探针
字节码注入

无侵入

Thrift,gRPC java、php hbase+mysql

分析

方案

颗粒度

调用链应用拓扑

UI丰富程度

告警支持jvm监控trace查询

全局调用统计

skywalking

方法级 服务+中间件 支持 支持 支持 支持

sleuth+zipkin

接口级

服务 不支持 不支持 支持 不支持

pingpoint

代码级

服务+中间件 支持 支持 支持 支持

 

 

 

引用:

posted on 2021-05-22 18:33  曹伟雄  阅读(990)  评论(0编辑  收藏  举报

导航