链路追踪调研

一、问题背景

1、背景

    随着微服务架构的流行，服务按照不一样的维度进行拆分，一次请求每每须要涉及到多个服务，因此服务性能监控和排查就变得更复杂。

1.不同的服务可能由不同的团队开发、甚至可能使用不同的编程语言来实现
2.服务有可能布在了几千台服务器，横跨多个不同的数据中心

    所以，就须要一些能够帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，可以快速定位和解决问题，这就是APM系统，全称是（ApplicationPerformanceMonitor）

2、链路追踪起源

    链路追踪系统最早是在Goggle公开发布的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中提到的。
    Dapper是Google生产环境下的分布式追踪系统，自从Dapper发展成为一流的监控系统之后，给google的开发者和运维团队帮了大忙。

二、链路追踪概述

1、在复杂的微服务架构系统中，几乎每个前端请求都会造成一个复杂的分布式服务调用链路。那么在业务规模不断增大、服务不断增多以及频繁变动的状况下，面对复杂的调用链路就带来一系列问题：

1.如何快速发现问题？
2.如何判断故障影响范围？
3.如何梳理服务依赖以及依赖的合理性？
4.如何分析链路性能问题以及实时容量规划？

    同时咱们会关注在请求处理期间各个调用的各项性能指标，好比：吞吐量（TPS）、响应时间及错误记录等：

1.吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
2.响应时间，包括总体调用的响应时间和各个服务的响应时间等。
3.错误记录，根据服务返回统计单位时间异常次数。

2、全链路性能监控 从总体维度到局部维度展现各项指标，将跨应用的全部调用链性能信息集中展示，可方便度量总体和局部性能，而且方便找到故障产生的源头，生产上可极大缩短故障排除时间。有了全链路监控工具，咱们可以达到：

1.请求链路追踪，故障快速定位：能够经过调用链结合业务日志快速定位错误信息。
2.可视化： 各个阶段耗时，进行性能分析。
3.依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
4.数据分析，优化链路：能够获得用户的行为路径，汇总分析应用在不少业务场景。

3、目标要求

1.探针的性能消耗:
    APM组件服务的影响应该做到足够小。服务调用埋点自己会带来性能损耗，这就须要调用跟踪的低损耗，实际中还会经过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即便一点点损耗也会很容易察觉到，并且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
2.代码的侵入性:
    既也做为业务组件，应当尽量少入侵或者无入侵其余业务系统，对于使用方透明，减小开发人员的负担。
    对于应用的程序员来讲，是不须要知道有跟踪系统这回事的。若是一个跟踪系统想生效，就必须须要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，每每因为跟踪系统在应用中植入代码的bug或疏忽致使应用出问题，这样才是没法知足对跟踪系统“无所不在的部署”这个需求。
3.可扩展性:
    一个优秀的调用跟踪系统必须支持分布式部署，具有良好的可扩展性。可以支持的组件越多固然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也能够自行扩展。
4.数据的分析
    数据的分析要快 ，分析的维度尽量多。跟踪系统能提供足够快的信息反馈，就能够对生产环境下的异常情况作出快速反应。分析的全面，可以避免二次开发。

4、功能模块

1.埋点与生成日志
    埋点即系统在当前节点的上下文信息，能够分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志一般要包含如下内容traceId、spanId、调用的开始时间，协议类型、调用方ip和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步扩展作准备。

不能形成性能负担：一个价值未被验证，却会影响性能的东西，是很难在公司推广的！由于要写log，业务QPS越高，性能影响越重。经过采样和异步log解决。

2.收集和存储日志
    一般来说，会使用离线+实时的方式去存储日志，主要支持分布式日志采集的方案，同时增长MQ做为缓冲。典型的解决方案如Flume结合Kafka等MQ。

1.每一个机器上有一个 deamon 作日志收集，业务进程把本身的Trace发到daemon，daemon把收集Trace往上一级发送；
2.多级的collector，相似pub/sub架构，能够负载均衡；
3.对聚合的数据进行, 实时分析和离线存储；
4.离线分析, 须要将同一条调用链的日志汇总在一块儿；

3.分析和统计调用链路数据，以及时效性
    一条调用链的日志散落在调用经过的各个服务器上，首先需要按 TraceId 汇总日志，然后按照RpcId 对调用链进行顺序整理。用链数据不要求百分之百准确，可以允许中间的部分日志丢失。
    调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。抛异常或者超时，在日志里打印TraceID。利用TraceID查询调用链状况，定位问题。
    依赖度量：

1.强依赖：调用失败会直接中断主流程
2.高度依赖：一次链路中调用某个依赖的概率高
3.频繁依赖：一次链路调用同一个依赖的次数多

    离线分析：按TraceID汇总，经过Span的ID和ParentID还原调用关系，分析链路形态。
    实时分析：对单条日志直接分析，不作汇总，重组。获得当前QPS，延迟。
4.展示以及决策支持
    汇总得到各个应用节点的调用链日志后，可以针对性的对各个业务线进行分析。需要对具体日志进行整理，进一步储存在HBase或者关系型数据库中，可以进行可视化的查询。

三、技术方案

1、zipkin（开源）

1.早于Jaeger，是Google Dapper的开源版本，由Twitter公司进一步开发并开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展示。
2.基于Java语言的应用程序，其中包含很多服务，每个服务都实现Zipkin具体的某一个功能，并包括一个用户界面和用于跟踪软件系统框架的界面。每个服务还提供了一系列存储引擎来持久存储数据，例如内存数据库，MySQL，Cassandra和Elasticsearch。
3.还提供了传输机制（如RabbitMQ，Scribe，HTTP和Kafka）以及用于在Cassandra中存储数据的基于节点的服务器。Zipkin支持大多数流行的高级语言，包括C＃，Java和JavaScript。
4.目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。

5. Twitter zipkin -> https://zipkin.io/
   github -> https://github.com/openzipkin/zipkin/

2、skywalking （开源）

1.国产的优秀开源APM组件，是一个对JAVA分布式应用程序集群的业务运行状况进行追踪、告警和分析的系统。也是基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。
2.skywalking的collector支持两种部署方式：单机和集群模式。collector与agent之间的通信使用了gRPC。
3.http://skywalking.apache.org/

3、pinpoint（开源）

1.一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
2.pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架，发送链路信息到collector。
3.https://github.com/pinpoint-apm/pinpoint

4、Jaeger（开源）

1.由Uber创建，并用Go语言编写。它除了Zipkin的功能集外，Jaeger还提供了动态采样，REST API，基于ReactJS的UI界面，以及对Cassandra和Elasticsearch内存数据存储的支持。为了实现这些功能，Jaeger相比Zipkin采取了一种不同的，更分散的方法。
2.Jaeger的体系结构包括一个客户端，该客户端向代理发出跟踪，代理监听入站跨度(spans)并将其路由到收集器。然后，收集器将验证，转换并保留跨度(spans)。
3.Jaeger的分布式体系结构使其具有高度可扩展性。Jaeger还具有独特的数据收集方式：与其他尝试收集轨迹和跨度(spans)的系统不同，Jaeger会对监视的数据进行动态采样。这种方法不仅可以处理突然的流量激增，而且可以提高Jaeger的整体性能。
4.https://www.jaegertracing.io/

5、Elastic APM（开源）

1.来源于之前的opbeat,Opbeat是由一个丹麦初创团队于2013年成立的老公司，专门进行运维软件的开发，而其主打产品即是APM运维软件。被elastic收购之后，opbeat已经于2018年5月份，正式关闭网站和社区，转到了elastic APM上
2.数据存储用 ElasticSearch，用户只需要安装一个 apm-server，然后在应用里面安装对应语言版本的 elastic-apm 包，便可以快速搭建一套开源的 APM 服务。

6、hydra（开源）

1.源于京东，与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加。
2.已于2013年6月停止维护。

7、cat（部分开源）

1.大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。
2.跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源。
3.最后一个稳定版本是2014年1月，之后已经失去维护。

8、Dapper（未开源）

1.Dapper是Google生产环境下的分布式跟踪系统
2.未开源

9、Eagle eye（未开源）

1.阿里淘宝的鹰眼系统
2.未开源

接下来就可以针对开源版本做一个对比

四、方案对比

方案	zipkin	skywalking	pinpoint	Jaeger	Elastic APM
开发语言	java	java	java	go	go
Github Star	15.4k+	19.4k+	12.2k+	15.7k+	1000+
Github contributors	150	399	111	239	68
背后公司或组织	Apache、Twitter	Apache	NAVER	CNCF、Uber	Elastic
代码侵入性	高	低	低	中	很低
UI	中	高	高	中	中
OpenTracing兼容	是	是	否	是	不完善
客户端支持语言	java,php,go,python,.net,ruby	java,php,go,c++,node.js,python,.net,lua	java,php,python	java,go,python,node.js,c++,c#	java,php,go,node.js,python,.net,ruby
存储类型	Memory,Cassandra,Elasticsearch,mysql	Memory,Elasticsearch,mysql,TiDB,infulxdb	HBase	Memory,Cassandra,Elasticsearch,Kafka	Elasticsearch
二次开发难度	中	中	高	低	高
监控报警	无，需结合其它工具实现	支持	支持	无，需结合其它工具实现	支持
traceId查询	支持	支持	不支持
性能损失	中	低	高	中
颗粒度	接口级	方法级（更详细），方法中所有远程调用都展示：如数据库、redis	方法级（更详细）
实现方式	拦截请求，发送（HTTP，mq）数据至zipkin服务	java探针，字节码增强	java探针，字节码增强
接入方式	基于linkerd或者sleuth方式，引入配置即可	javaagent字节码	javaagent字节码
agent到collector的协议	http,MQ	gRPC	thrift
全局调用统计	不支持	支持	支持
JVM监控	不支持	支持	不支持

    基于上面方案对比，再结合目前项目组情况，基本可以排除Jaeger和Elastic APM

五、选型

1、对比项

1.探针的性能
    主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提升。
2.collector的可扩展性
    可以水平扩展以便支持大规模服务器集群。
3.全面的调用链路数据分析
    提供代码级别的可见性以便轻松定位失败点和瓶颈。
4.对于开发透明，容易开关
    添加新功能而无需修改代码，容易启用或者禁用。
5.完整的调用链应用拓扑
    自动检测应用拓扑，帮助你搞清楚应用的架构。
6.社区支持

2、对比
2.1、探针的性能

    比较关注探针的性能，毕竟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%之内。

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

1.zipkin:
    开发zipkin-Server（其实就是提供的开箱即用包），zipkin-agent与zipkin-Server通过http或者mq进行通信，http通信会对正常的访问造成影响，所以还是推荐基于mq异步方式通信，zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的，多个zipkin-Server实例进行异步消费mq中的监控信息。
2.skywalking:
    skywalking的collector支持两种部署方式：单机和集群模式。collector与agent之间的通信使用了gRPC。
3.pinpoint:
    pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架，发送链路信息到collector。

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

1.zipkin

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

skywalking 还支持20+的中间件、框架、类库，比如：主流的dubbo、Okhttp，还有DB和消息中间件。上图skywalking链路调用分析截取的比较简单，网关调用user服务，由于支持众多的中间件，所以skywalking链路调用分析比zipkin完备些。
3.pinpoint

pinpoint应该是这三种APM组件中，数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图可以看到对于执行的sql语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。

2.4、对于开发透明，容易开关

    对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。
    对于这一点，Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是，它要求在需要时修改代码。skywalking和pinpoint都是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。

2.5、完整的调用链应用拓扑
    自动检测应用拓扑，帮助你搞清楚应用的架构。

1.zipkin链路拓扑:

2.skywalking链路拓扑:

3.pinpoint链路拓扑:

三个组件都能实现完整的调用链应用拓扑。相对来说:

• pinpoint界面显示的更加丰富，具体到调用的DB名

• zipkin的拓扑局限于服务于服务之间

2.6、社区支持
    Zipkin 由 Twitter 开发，可以算得上是明星团队，而 pinpoint的Naver 的团队只是一个默默无闻的小团队，skywalking是国内的明星项目，目前属于apache孵化项目，社区活跃。

3、总结

方案	zipkin	pinpoint	skywalking
探针性能	中	低	高
collector扩展性	高	中	高
调用链路数据分析	低	高	中
对开发透明性	中	高	高
调用链应用拓扑	中	高	中
社区支持	高	中	高

相对来说，skywalking更占优，因此团队采用skywalking作为APM工具。