【微服务架构】调用链追踪系统对比

拥有回忆 提交于 2019-12-13 10:47:35

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

概述

当代的互联网服务,通常都是用复杂的、大规模分布式集群来实现的。互联网应用构建在不同的服务集上,这些服务有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,需要一个用于分析性能问题的系统可以监控那些横跨了不同的应用、不同的服务器之间的关联动作,调用链追踪系统应运而生。

目标

分布式调用链追踪系统一般有以下五个目标:

  1. 低消耗(low-overhead)调用链追踪埋点不能占用链路上太长的时间,也不应消耗太多的机器资源。
  2. 低侵入(low-invasiveness)作为非业务组件,应当尽可能少侵入或者不侵入其他业务系统,保持对使用方的透明性,减少开发人员的负担和接入门槛。
  3. 可扩展(scalability)整个调用链追踪通路都应该可扩展,以应对不断接入的服务和公司未来的发展。
  4. 时效性(time-efficient)从追踪数据采集,分析处理,查询,展示的整个通路都要尽量快速。
  5. 决策支持(decision-support)需要为业务定位问题,分析服务,提供丰富清晰的报表。

功能

调用链追踪系统通常包含的功能如下:

  • 对调用请求的整个链路进行追踪,分析每个环节的耗时,协助开发运维人员找到性能瓶颈
  • 找出服务之间的依赖拓扑关系,如每个服务依赖哪些服务,同时又被哪些服务依赖
  • 对服务的性能监控与报警
  • 调用链系统实现了服务与具体机器的关联,可以依据机器的监控指标(CPU,内存,磁盘)排查服务的问题

知名的调用链追踪系统介绍与对比

几乎所有的中大型互联网公司都部署了调用链追踪系统,或者类似的监控系统,对公司的服务进行监控分析,本节将从架构,开发语言,是否开源,业务接入方式,功能,支持追踪的服务,优缺点等6个方面,介绍比较知名的几个调用链追踪工具。

CAT(大众点评)

CAT的核心概念源自eBay闭源系统CAL,是大众点评开源的分布式服务监控程序,已经被大众点评,携程,陆金所,同城旅游等多家公司用于生产环境,资料介绍详见《深度剖析开源分布式监控CAT》及《透过CAT,来看分布式实时监控系统的设计与实现》。 架构: 应用使用CAT的SDK进行手动埋点决定对那些方法和服务进行追踪,追踪数据会通过TCP上传到消费机组,消费机负责将追踪信息组织成调用树,并按小时在内存中统计报表,报表放入MySql,原始数据异步存到HDFS,其中历史数据的查询都是定期归总得到的,比如天级别的统计是在小时级别上聚合得到,周级别的统计是在天级别聚合得到,控制台负责展示。 开发语言:Java 是否开源:开源,代码地址:https://github.com/dianping/cat 业务接入方式:依赖CAT SDK,对要追踪的方法或服务进行手动埋点。 功能:对收集的数据提供各种维度上的统计,如应用级别的qps,延时;iP上的的延时QPS,延时,提供实时查询和历史查询,其中实时查询的实效为1个小时 支持追踪的服务:支持对Java和.NET架构进行追踪,服务包括:HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL,如果不是跨服务的调用,只要埋点就可以对调用的client端进行追踪。 优缺点: 优点:手动埋点,比较灵活,想追踪哪埋哪,提供历史报表的查询,及多种维度的报表统计。 缺点:手动埋点对业务代码的侵入性太强;时效性太差,最低的时效是1个小时,不支持采样

Dapper(Google)

Dapper是Google内部的调用链追踪系统,不开源但在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,其中定义了追踪数据的格式,追踪方式,调用链追踪系统的架构等理论模型。本文对比的调用链追踪系统中除了CAT,其他的都是参照Dapper这篇论文做的实现。 架构: Dapper对Google内部中通用框架都提供了装配工具,服务部署了这些装配工具就会对调用链进行追踪,装配工具将追踪信息打印到机器磁盘上,每台服务器上部署的Dapper daemon会将追踪信息收集到Dapper Collector。Dapper Collector对追踪信息进行处理,存储,并提供查询。 追踪信息中包含的主要信息包括: traceId。一个unique的值,表示1条调用链。 spanId。表示调用中的一个具体环节。 parentSpanId。当前环节的父环节。 duration。当前调用的耗时。 Annotation。包含调用的基本信息(服务所在IP,请求到达或者响应的时间)。 Dapper Collector根据各个服务上报的追踪信息中包含的traceId,spanId和parentSpanId组装成完整的调用链,同时注明每个环节的耗时。 开发语言:未知 是否开源:否 业务接入方式:使用Dapper的装配工具,或者支持调用追踪的公共组件库(RPC组件,HTTP组件) 功能:Dapper是闭源的,发表的文章定义了追踪数据的格式,追踪方式,调用链追踪系统的架构,完成的功能(监控与查询),为其他的调用链追踪系统提供了范式。 支持追踪的服务:Google内部所有的公共组件库,同时提供用户自己接入Dapper的API。 优缺点: 优点:独立于开发语言,通过改造基础组件库,对应用开发近乎零浸入的成本完成对分布式调用的追踪。 缺点:需要不断的支持新的基础库组件,开发者需要加入少量的代码

Zipkin(Twitter)

Zipkin是Twitter基于Google Dapper开发的开源调用链追踪系统,几乎完全按照Dapper中定义的追踪数据格式,追踪方式和架构进行了实现。 架构: Zipkin整个架构上与Dapper非常类似,装配了追踪工具的服务将追踪信息上报给Transport,Collector对追踪信息进行处理,存储,然后前端调用存储中的信息进行展示,其中Transport支持(HTTP, Kafka,Scribe),Storage支持(Mysql, ElasticSearch,Cassandra)。 开发语言:Java 是否开源:是,代码地址:https://github.com/openzipkin/zipkin 业务接入方式:使用Zipkin的装配工具 功能:提供了调用链的查询,依赖分析功能,并提供了比较丰富的装配工具 支持追踪的服务:Zipkin的追踪是独立于开发语言的,只要满足Zipkin的追踪数据格式就可以,已经支持的框架包括:grpc,Jersey,Spring Web,Spring boot,Spring Cloud,Mysql,okHttp, Sevlet, JAXRS2等 优缺点: 优点:独立于开发语言,对应用侵入非常小,提供服务之间的依赖关系展示。 缺点:需要不断的支持新的框架,开发者需要加入少量的代码,应用追踪数据的上报对Zipkin的后台的稳定性有比较强的依赖,缺乏宏观监控

jaeger(Uber)

jaeger 是Uber基于Google Dapper,并借鉴Zipkin使用GO语言开发的开源调用链追踪系统,架构,功能与Zipkin类似,也能与Zipkin的追踪数据兼容。 架构: jaeger的整体架构与Zipkin类似,在Zipkin的基础上实现了自适应的采样,通过Thrift RPC上传追踪数据。利用Spark定期的处理追踪数据,分析服务之间的依赖关系,这个功能Zipkin也具备。 开发语言:GO 是否开源:是,代码地址:https://github.com/uber/jaeger 业务接入方式:使用jaeger提供的装配工具 功能:提供了调用链的查询,依赖分析功能 支持追踪的服务:jaeger的追踪是独立于开发语言的,提供了GO,Java,Node.js和python的装配工具SDK,可以直接追踪的框架包括dropwizard,ApacheHTTPClient,JAXRS2 优缺点: 优点:独立于开发语言,提供了服务之间的依赖关系展示,提供了自适应的采样功能,具有服务级别平均延时的宏观监控 缺点:能够直接追踪的框架还比较少,很多都是要调用SDK直接埋点,应用追踪数据的上报对jaeger的后台的稳定性有比较强的依赖

HTrace(Apache Incubator)

HTrace是Cloudrea基于Google Dapper开发的调用链追踪系统,提供了C,C++,Java的追踪SDK,可以直接对HDFS(2.7版本及以上)和HBase(1.0版本及以上)进行追踪,目前是Apache的孵化器项目。 架构: 系统转配好Htrace的Client后,追踪信息可以由3种上传方式(HTTP,日志收集,Flume)中的一种上传给SpanReceiver,SpanReceiver对追踪信息进行组装存储,并提供查询功能,htrace-web负责展示。htrace将追踪信息存储在Leveldb。 开发语言:Java 是否开源:是,代码地址:https://github.com/apache/incubator-htrace 业务接入方式:使用HTrace的SDK手动埋点 功能:提供了调用链的查询功能,可以对HDFS和HBase的内部调用关系进行追踪,提供了与Zipkin对接的工具包 支持追踪的服务:是独立语言的,开发了C,C++,Java的追踪装配SDK,业务需要对追踪的服务进行手动埋点,原生支持对HDFS和HBase的追踪 优缺点: 优点:独立于开发语言,提供了调用链的查询功能,原生支持对HDFS和HBase的追踪 缺点:缺少宏观监控,缺少对公共的HTTP,RPC框架的支持,需要手工在要追踪的位置进行埋点

鹰眼(阿里)

鹰眼是阿里基于Google Dapper开发的调用链追踪系统,用于淘宝所有服务之间的调用追踪。 架构: 带有鹰眼埋点的中间件将追踪数据打印到日志,由日志收集agent将日志中的追踪信息上传到Storm,Storm将追踪数据全量存入HDFS,并将实时统计结果存入HBase。MapReduce任务根据追踪数据做更详细的统计,如服务之间的依赖关系,某个服务的来源分析、入口分析、路径分析,实时访问量,以及具体的调用链路的详情等功能。鹰眼服务器提供对实时统计和离线统计的查询,并由丰富的UI进行展示。 开发语言:未知 是否开源:否 业务接入方式:使用带鹰眼埋点的中间件 功能:提供了调用链查询,实时统计及丰富的离线宏观统计报表 支持追踪的服务:覆盖了淘宝主要使用的网络通讯中间件 优缺点: 优点:独立于开发语言,支持丰富的内部使用中间件,提供丰富的宏观统计报表,并能够与机器的CPU,内存,磁盘和进程的JVM信息等做关联,协助排障,数据基于日志打印收集追踪数据,做到了和线上服务的隔离 缺点:需要不断的支持新的框架,业务需要修改少量代码

CallGraph(京东)

京东之前有一个只追踪Dubbo的调用追踪系统Hydra,现在开发了可以追踪所有中间件新的调用链追踪系统CallGraph。CallGraph几乎完全参照阿里的鹰眼系统实现。 架构: 加入了CallGraph追踪工具包的服务将追踪信息打印到日志文件,由日志收集Agent将追踪信息上传给Storm,Storm将实时统计信息存到Hbase或者ES中,原始数据存入HDFS,由Spark定期处理。CallGraph-UI负责展示。提供服务间的调用拓扑,某个服务的来源分析、入口分析、路径分析,以及具体的调用链路的详情等功能。 开发语言:未知 是否开源:否 业务接入方式:使用带CallGraph埋点的中间件 功能:提供了调用链查询,实时统计及丰富的离线宏观统计报表 支持追踪的服务:覆盖了淘宝主要使用的网络通讯中间件 优缺点: 优点:独立于开发语言,提供丰富的宏观统计报表,数据基于日志打印收集追踪数据,做到了和线上服务的隔离 缺点:需要不断的支持新的框架,业务需要修改少量代码

Microscope(唯品会)

Microscope是唯品会基于Google Dapper参照Zipkin实现的,具有调用链追踪,实时监控,报警,并能关联机器的CPU,内存,磁盘,JVM。目前整个项目还是一个初始项目,没看到项目完整的架构图和实际的上线情况,但从设计描述与基于Google Dapper的其他设计差别不大。

Watchman(新浪微博)

Watchman是新浪基于Google Dapper开发的用于追踪微博各服务的调用链追踪系统。 架构: Watchman-runtime使用字节码增强技术对服务进行埋点,并将追踪信息打印到日志文件,由服务所在机器的watchman-prism(基于Scribe开发)将日志收集到中间层的watchman-prism,中间层的watchman-prism将追踪信息写入消息队列。Storm负责实时的统计,并将统计结果写入HBase,前端对统计结果进行展示。 开发语言:Java 是否开源:否 业务接入方式:字节码增强技术侵入服务,服务启动的时候加载埋点Jar包即可 功能:提供了实时统计报表,调用链查询 支持追踪的服务:微博用到的所有基于JVM的服务组件 优缺点: 优点:字节码增强技术侵入服务,业务无需修改代码,具有实时统计展示功能,调用链追踪功能,数据基于日志打印收集追踪数据,做到了和线上服务的隔离。 缺点:只能支持Java语言开发的服务,使用字节码增强技术门槛比较高,加入新的服务框架困难。

Pinpoint(Naver)

Pinpoint是韩国搜索公司Naver基于Google Dapper开源的一款分布式调用链追踪系统。 架构: Pinpoint使用字节码增强技术对服务进行埋点,追踪信息通过Thrift上传到Pinpoint Collector,Pingpoint负责计算统计指标,并将实时结果和原始追踪信息都存入HBase,前端从HBase读数据进行展示。 开发语言:Java 是否开源:开源,代码地址:https://github.com/naver/pinpoint 业务接入方式:字节码增强技术侵入服务,服务启动的时候加载埋点Jar包即可 功能:提供了实时统计报表图,调用链查询 支持追踪的服务:Spring, Spring Boot,OKHttpClient,ApacheHttpClient,Thrift,Dubbo,Mysql等常见服务 优缺点: 优点:字节码增强技术侵入服务,业务无需修改代码,具有实时统计展示功能,JVM的实时监控,调用链追踪服务。 缺点:只能支持Java语言开发的服务,使用字节码增强技术门槛比较高,加入或更新对服务框架的追踪困难,统计指标非常少,只有延时散点图和响应时间汇总图。 4. 调用追踪系统的模块汇总 从各个调用链追踪系统架构上看,主要分以下几个模块。 埋点 埋点是调用链追踪系统与业务服务交互的部分,这块的设计要做到低消耗与低侵入,目前有以下三种方式。 业务手动埋点,在要追踪的地方调用SDK进行埋点。 支持公共组件库,通过改造公共组件库,或者提供公共组件库的插件来避免与业务的代码发生交互,可以对业务代码做到零侵入,或者然业务加入少量代码。 字节码增强,这种方式与第2一样,但是是通过字节码增强技术,在JVM加载公共组件库的时候动态修改代码,加入侵入逻辑,可以做到对业务代码零侵入。 第2种方式因为对业务代码的侵入比较少,可以追踪所有开发语言的框架,开发容易,应用最广泛;第三种方式无需业务修改代码,但开发困难,且只能追踪Java应用,也有一定应用;第一种方式对业务代码侵入性太强,实际应用的公司比较少。 追踪数据上传 追踪数据的上传目前是两种方式: TCP/UDP上传。 将追踪信息打印到日志,走日志采集。 第2种方式应用比较普遍,好处:1 是最大限度的将业务服务和调用链追踪系统做到了隔离,避免调用链追踪系统的后台的任何改变对线上服务有影响;2 埋点组件的开发简单,直接打印到日志就可以了,不依赖其他组件。 计算 根据上传上来的追踪数据,可以计算许多指标,用于业务了解服务的各种状态,比较全面的可计算统计指标包括: 实时的QPS,调用延时,延时分布,服务状态监控 服务依赖关系拓扑图 服务访问入口分析(DC, 服务,机器级别的延时,QPS,状态分析),出口分析(DC, 服务,机器级别的延时,QPS,状态分析),路径延时分布分析 统计指标还需要按不同的时间粒度再聚合(分钟,小时,天,周,月)。 存储 需要存储的信息包括两类: 原始追踪数据。数据量比较大,一般存储在分布式存储中,如HDFS,HBase,Elastic Search, Cassandra,需要开发实时的索引查询服务。 统计信息。量比较小,需要具有快速的按时间的检索能力,一般存在Mysql,HBase,或时序数据库。 关联 追踪数据中会包含IP信息,因此可以将服务与机器级别的指标关联,例如机器的CPU,内存,网络,磁盘等,还可以和JVM的信息做关联,甚至可以和具体应用的日志做关联,以便快速的分析和定位故障。 展示 调用链分析系统可以包含许多的可查询指标,清晰的组织各种维度的实时与历史统计数据和调用链树非常关键。 5. Rover Rover是服务云基于Google Dapper,参考Zipkin开发的分布式调用链系统,用于公司线上各服务的调用链追踪。目前已经可以支持对Thrift,Spring Web,Spring boot,Spring Cloud,Struts,Jersey,Grpc,各种HTTP Client的追踪。具有如下特点: 通过开发各种服务的插件完成追踪,对业务代码侵入下,在业务代码逻辑之外加几行代码就行。 具备实时监控报警功能,可以实时监控服务的QPS,延时,并可以再其上加报警。 服务依赖拓扑图分析 入口与出口的调用次数统计 基于日志收集做调用分析,避免与线上系统的直接交互 项目与权限管理

总结

调用链追踪系统或者类似的监控系统几乎是大中型互联网公司的标配,本文从架构,对业务的侵入方式,完成的功能等各方面对比了知名的调用链追踪系统。

参考资料

深度剖析开源分布式监控CAT:http://tech.meituan.com/CAT_in_Depth_Java_Application_Monitoring.html 透过CAT,来看分布式实时监控系统的设计与实现:http://www.infoq.com/cn/articles/distributed-real-time-monitoring-and-control-system Google Dapper: https://research.google.com/pubs/pub36356.html Zipkin介绍主站:http://zipkin.io/ Uber Jaeger:https://uber.github.io/jaeger/ Apache HTrace:http://htrace.incubator.apache.org/ 阿里鹰眼:https://wenku.baidu.com/view/5bd8e7c550e2524de5187ee0.html 京东Hrdra:http://www.aiuxian.com/article/p-1705239.html 京东CallGraph:http://zhuanlan.51cto.com/art/201701/528304.htm?utm_source=tuicool&utm_medium=referral 唯品会的Microscope:http://blog.csdn.net/alex19881006/article/details/24381109 新浪Watchman:http://www.infoq.com/cn/articles/weibo-watchman Naver Pinpoint:https://github.com/naver/pinpoint

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!