概述
为什么追踪链路
1. 单体应用 过渡 到微服务
2. 微服务 必须导致 调用熵增加
3. 单体应用中两个问题显现出来：根据日志查询问题；调用链路和调用的性能。
4. 日志问题在以后的日志方案中研究，典型的方案就是ELK。
5. 下面解决调用链路和性能分析问题
6. 区别：日志较粗的记录链路，一般用来审计和查业务问题，一般都会编码实现； 链路记录的信息更细致，偏向于调用服务链路的展示，对代码入侵越少越好，主要用来性能分析和问题核查。
解决方案
1. 标识请求：可一个给每一个HTTP请求添加一个TractID(跟踪ID)
2. 锚点设置：每个调用目标方法都进行代理，在调用前后进行日志的记录
3. 数据传输：这些数据尽可能减小对应用的影响
4. 数据存储：
5. 数据展示和分析
设计目标
- 低侵入性
- 灵活的应用策略；(可以 [最好随时] 决定所收集数据的范围和粒度)
- 时效性；从agent采样，到collect、storage和display尽可能快
- 决策支持；
- 可视化是王道；(丰富的数据报表)
- 低消耗；在web请求链路中，对请求的响应影响尽可能小
- 延展性；随着业务量暴增，分布式跟踪系统的高可用、和高性能表现依然好
开源框架
结论：
1. jaeger对于go开发者来说，可能比较合适一些，但是入手比较困难。它的rpc框架采用thrift协议，现在主流grpc并不支持。后端丰富存储，社区正在积极适配
2. appdash对于go开发者想搭建一个小型的trace比较合适，不适合大规模使用
3. zipkin项目，github很活跃，star数量很多，属于java系。很多大厂使用
4. CAT项目也属于java系, github不活跃，已不太更新了。不过很多大厂使用，平安、大众点评、携程...
5. skywalking项目, 也属于java系。目前已成为Apache下的项目了，github活跃，作者也非常活跃，当当、华为正在使用。
6. appdash项目，go语言开发，因为可视化过于简单、且完全内存存储，不太适合大规模项目使用。
7. 19年6月12日，阿里云发布了链路追踪服务 Tracing Analysis，提供分布式系统的全链路追踪能力，帮助客户快速发现和定位分布式系统下的各类性能瓶颈，成本仅自建链路追踪系统的1/5甚至更少。
所以自建选择的话，可以从skywalking、cat、jaeger和zipkin中选择；
如果托管且应用在阿里云可以使用Tracing Analysis。决策分析
产品名称 | CallGraph | EagleEye | Tracing Analysis | |||||||
厂商 | uber | twitter | sourcegraph | 美团 | 京东 | sina微博 | 淘宝 | 华为 吴晟 | 阿里托管服务 | |
开源 | 开源 | 开源 | 开源 | 开源 | 不开源 | 不开源 | 不开源 | 不开源 | 开源 | |
OpenTracing标准 | 完全支持 | 部分支持 | - | 完全支持 | - | - | - | - | 完全支持 | 完全支持 |
侵入性 | 部分侵入 | 侵入性强 | 侵入性强 | 侵入性较弱 | - | 侵入性很低 | ||||
应用策略 | 策略灵活 | 策略灵活 | 策略灵活 | 采样率支持(粒度：不能根据流量采样，只能依赖于请求数量)；没有trace开关 | - | 策略灵活 | ||||
时效性 | 时效性高， UDP协议传输数据(在Uber任意给定的一个Jaeger安装可以很容易地每天处理几十亿spans) | 时效性好 | 时效性较好，rpc框架采用tcp传输数据 | 时效性高 | - | 时效性较好 | ||||
决策支持 | 决策支持较好，并且底层支持metrics指标 | 决策一般(功能单一，监控维度和监控信息不够丰富。没有告警功能) | 决策好 | 决策支持低 | 由于调用链路的更细化， 但是作者在性能和追踪细粒度之间保持了比较好的平衡。决策好 | |||||
可视化 | 报表不丰富，UI比较简单 | 丰富的数据报表 | 报表丰富，满足各种需求 | 可视化太弱，无报表分析 | 丰富的数据报表 | |||||
低消耗 | 消耗低 | 系统开销小 | 消耗较低 ， 国内很多大厂都在使用 | 消耗方面。不支持大规模部署, 因为appdash主要依赖于memory，虽然可以持久化到磁盘，以及内存存储支持hash存储、带有效期的map存储、以及不加限制的内存存储，前者存储量过小、后者单机内存存储无法满足 | 消耗较低 | 一般在1%左右 | ||||
延展性 | jaeger比较复杂，使用框架较多，比如：rpc框架采用thrift协议，不支持pb协议之类。后端存储比较复杂。但经过uber大规模使用，延展性好 | 延展性好 | - | 延展性差 | 延展性非常好，水平理论上无限扩 |
标准提取
背景：
Google 2004年开始内部使用Dapper，2010年Dapper文章发表，2012年Zipkin发布。分布式系统跟踪不是一个新的话题，它已经存在快14年了！
问题：
如果分布式跟踪是对日志和监控指标的重要补充，为什么到2016年大家都还没有广泛使用它？因为要让自己的应用支持分布式跟踪太难了！不仅需要在进程内进行跟踪数据的传递，还要在进程之间传递。更难的是，还需要其他组件对分布式跟踪的支持，其中包括：
- 开源的服务（比如NGINX, Cassandra, Redis）
- 在服务内引入的开源库（比如 grpc, ORMs)
- 已有的业务逻辑
解决办法：
制定一个统一的标准，然后让大家都遵守这个标准来实现分布式跟踪信息的描述和传递。这样只要使用的是按照标准实现的服务，就能够进行完整的分布式跟踪。
这个标准就是OpenTracing。
OpenTracing是什么？
后台无关的一套接口，被跟踪的服务只需要调用这套接口，就可以被任何实现这套接口的跟踪后台（比如Zipkin, Jaeger等等）支持，而作为一个跟踪后台，只要实现了个这套接口，就可以跟踪到任何调用这套接口的服务标准化了对跟踪最小单位Span的管理：定义了开始Span，结束Span和记录Span耗时的API。Span的定义可以参照开源分布式跟踪系统Zipkin介绍（架构篇）
标准化了进程间跟踪数据传递的方式：定义了一套API方便跟踪数据的传递
标准化了进程内当前Span的管理：定义了存储和获取当前Span的API
OpenTracing不做什么？
不对进程间传递的跟踪数据的编码定标准
不对向后台发送的跟踪数据的编码定标准
原因：让跟踪后台自己决定最适合他们的编码方式
OpenTracing架构
应用代码和开源控件写代码调用一套抽象出来的OpenTracing API（浅绿色的那一块）。而实现OpenTracing API的代码库（深绿色的那一块）则负责缓存和编码跟踪数据，以及进程间跟踪数据的上下文信息，以及如何和它自己的后台系统进行通信
通过这样的一种方式，应用代码就可以随意的更换OpenTracing的实现而不用改一行自己的代码。比如如果自己用Zipkin用得不爽了，就可以换到Jaeger后台。如果一开始直接调用Zipkin的API而不是OpenTracing的API，那么要换到Jaeger后台就得把所有调用Zipkin API的地方都换成调用Jaeger API，而OpenTracing免除了这方面的工作
APM应用性能监控
Application PerformanceMonitor
阿里有ARMS服务，应用实时监控服务ARMS（Application Real-Time Monitoring Service）是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP等领域的性能管理，能帮助您实现全栈式性能监控和端到端全链路追踪诊断，让应用运维从未如此轻松高效。
现有方案简述
思路
1. 在一个请求过来是，给绑定一个标记。
2. 在请求经过的每个节点(包括：同步方法调用，微服务调用，中间件调用等)，都把这个标记给带着
3. 添加另一个标示标示调用位置(比如：AàB,那么A和B的标记区别)来记录处理的时间
4. 锚点设置好后，就需要在请求过来后收集信息，并记录。 通过将信息发送给特定服务或者组件
5. 这个服务或者组件(MQ)需要处理这些数据，包括：解析，持久化(或者放在内存)
6. 或者 可以通过日志处理技术，输出到文件，然后收集所有服务的日志文件然后处理
7. 有数据了就需要展示
链路跟踪组成
1. 收集数据
2. 传输数据
3. 展示数据
收集数据技术
1. 代码层面的代理
- 过滤器，拦截器，AOP 都属于这一类
- 特点：代码会侵入，容易控制
2. 修改字节码
- 通过JavaAgent字节码进行修改，形成代理
- 代码层面不影响，但涉及到性能或者自定义都比较难
数据传输手段
1. logstash 在每个微服务部署个代理，直接收集日志，传输过程不需要微服务处理
2. 在微服务集成组件，产生数据数据后通过HTTP发送给指定服务，或者发送给MQ
3. 部分组件使用二级制GRPC接口
现有组件
现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。国内，淘宝的“鹰眼”、京东的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是这样的系统。
典型组件：
Sleuth：
1. 是SpringCloud全家桶成员，对Feign、Stream(MQ) 都有很好的支持
2. 属于代码层面代理；
3. 很好的梳理了服务调用和调用时间信息，一个服务内调用了几个方法，每个方法消耗的时间是没法统计的。
4. 对调用接口的损耗可以有初步的定位。以及调用成功和失败统计，依赖关系的梳理。
SkyWalking：
1. 国人吴晟(sheng)开源，已提交Apache，由社区维护
2. 是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking；
3. 通过JavaAgent(探针)进行字节码植入，也就是说启动的时候需要带-javaagent参数end ...
