一、链路追踪
1、作用
如果能跟踪每个请求，中间请求经过哪些微服务，请求耗时，网络延迟，业务逻辑耗时等。我们就能更好地分析系统瓶颈、解决系统问题。比我们自己思考解决方案简单多了（调用加时间戳、捕获异常、打印日志分析）
2、市面上产品（大部分基于大部分基于google的Dapper论文）
zipkin,twitter开源的。是严格按照谷歌的Dapper论文来的。
pinpoint 韩国的 Naver公司的。
Cat 美团点评的
EagleEye 淘宝的
3、需要考虑的问题
//探针的性能消耗。不能过于影响服务本身
//容易使用。可以快速上手，别浪费太多精力
//数据分析。实时和维度。
二、Sleuth简介
Sleuth是Spring cloud的分布式跟踪解决方案。
整个数据结构是一棵树，从root span开始。
1、span(跨度)。基本工作单元。一次链路调用，创建一个span，
- span用一个64位id唯一标识。包括：id，描述，时间戳事件，spanId,span父id。
- span被启动和停止时，记录了时间信息，初始化span叫：root span，它的span id和trace id相等。
2、trace(跟踪)。一组共享“root span”的span组成的树状结构称为trace，trace也有一个64位ID，trace中所有span共享一个trace id。类似于一颗span树。
3、annotation(标签)，annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。
- CS(Client Send客户端发起请求)。客户端发起请求描述了span开始。
- SR(Server Received服务端接到请求)。服务端获得请求并准备处理它。SR-CS=网络延迟。
- SS(Server Send服务器端处理完成，并将结果发送给客户端)。表示服务器完成请求处理，响应客户端时。SS-SR=服务器处理请求的时间。
- CR(Client Received客户端接受服务端信息)。span结束的标识。客户端接收到服务器的响应。CR-CS=客户端发出请求到服务器响应的总时间。
三、Sleuth使用
1、引入依赖
<!-- 引入sleuth依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
2、启动应用后，看日志结果
[api-driver,1a409c98e7a3cdbf,1a409c98e7a3cdbf,true]
[服务名称，traceId（一条请求调用链中 唯一ID），spanID（基本的工作单元，获取数据等），是否让zipkin收集和展示此信息]
//看下游
[service-sms,1a409c98e7a3cdbf,b3d93470b5cf8434,true]
traceId，是一样的。服务名必须得写。
3、这么拍错需要看日志，有点原始，所以有了基于Sleuth的其他工具。
四、zipkin简介
zipkin是twitter开源的分布式跟踪系统。
收集系统的时序数据，从而追踪微服务架构中系统延时等问题。有一个友好的界面。
由4个部分组成
- Collector 采集器
- Storage 存储器
- Restful API 接口
- Web UI UI界面
五、zipkin原理
sleuth收集跟踪信息通过http请求发送给zipkin server，zipkin将跟踪信息存储，以及提供RESTful API接口，zipkin ui通过调用api进行数据展示。
默认内存存储，可以用mysql，ES等存储。
六、zipkin配置使用
1、依赖
<!-- zipkin -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
2、在每个需要监听的服务中配置
spring:
# 上报zipkin地址
zipkin:
base-url: http://localhost:9411/
# 采样比例
sleuth:
sampler:
rate: 1
3、启动zipkin服务
jar包下载：curl -sSL https://zipkin.io/quickstart.sh | bash -s
启动： java -jar zipkin.jar
docker：docker run -d -p 9411:9411 openzipkin/zipkin