微服务.链路追踪概述和方案 (Cat Zipkin Skywaking，Sluth等组件对比选型)

概述

为什么追踪链路

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。

决策分析

产品名称	jaeger	zipkin	CAT	Appdash	MTrace	CallGraph	Watchman	EagleEye	skywalking	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不做什么？

       不对进程间传递的跟踪数据的编码定标准

       不对向后台发送的跟踪数据的编码定标准

       原因：让跟踪后台自己决定最适合他们的编码方式

 来源：https://medium.com/opentracing/towards-turnkey-distributed-tracing-5f4297d1736

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 ...