1、为什么使用链路追踪？
在微服务中，随着服务越来越多，对调用链的分析越来越复杂。
出现问题：
1、微服务之间的调用错综复杂，用户发送的请求经历哪些服务，调用链不清楚，没有一个自动化的工具类来维护调用链。
2、无法快速定位调用链中哪个环节出了问题
3、无法快速定位调用链中哪个环节比较耗时
2、Sleuth简介
Sleuth是SpringCloud的子项目，全称SpringCloud-Sleuth，提供分布式系统中链路追踪解决方案
0、同类产品
SkyWalking是本土基于字节码注入的调用链分析，以及应用监控分析工具。
Cat由大众点评开源，基于java开发的实时应用监控平台，包括实时应用监控、业务监控。集成方案是通过代理码埋点的方式来实现监控
1、术语
1、Span
代表了一组基本的工作单元。为了统计各个处理单元的延迟，当请到达各个服务组件的时候，也通过一个唯一标识(SpanId)来标记它的开始、具体过程和结合。通过SpanId的开始和结束时间戳，就能统计该Span的调用时间，除此之外，还可以获取如事件的名称、请求信息等元数据。简单来说，服务调用链中，每一个服务都是一个Span，每个Span都有自己的spanId属性、parentId属性、traceId属性。
2、Trace
由一组traceId相同的Span串联形成的一个树状结构。为了实现请求跟踪，当请求到达分布式系统的入口端点时，之需要服务跟踪框架为该请求创建一个唯一标识（traceId），同时在分布式系统内部流转的时候，框架始终保持传递该唯一值，直到整个请求的返回。那么就可以使用该唯一标识将所有请求串联起来，形成一条完整的请求链路。简单来说，具有相同traceId的Span，服务调用串联起来的树状结构。
3、Annotation
用它记录一个完成请求的4个事件，每一个事件都是一个Annotation，内部使用的重要注释：
1、CS（Client Send）：客户端发出请求，开始一个请求的生命。
2、SR（Server Received）：服务端接收到请求开始进行处理。
3、SS（Server Send）：服务端处理完毕请求准备发送到客户端。
4、CR（Client Received）：客户端接收到服务端的响应，请求结束。
SR-CS=请求网络延迟 SS-SR=服务器上请求处理时间 CR-SS=响应网络延时 CR-CS=请求的总时间
2、Sleuth+Zipkin
Sleuth本身不提供UI界面，只是负责生成元素的信息，市面上有很多成熟的链路追踪UI界面
Zipkin是Twitter开放源代码分布式的跟踪系统，每个服务向Zipkin报告计时数据，Zipkin会根据调用关系通过Zipkin UI生成依赖关系图
3、 微服务整合Sleuth
1、构建zipkin服务端
如果只需要默认的实现，则不需要自己构建Zipkin Server了，只需要下载jar即可
Zipkin官网：https://zipkin.io/ ，然后下载jar包
写一个启动bat文件：java -jar zipkin-server-2.12.9-exec.jar --server.port=8888 pause
双击bat文件即可启动，zipkin服务端搭建完成，端口号：8888，端口号可自定义
访问：localhost:8888，即可看到zipkin的UI界面
2、加入依赖
<!--Sleuth+Zipkin场景依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
3、配置文件修改
在配置文件中加入zipkiin和sleuth配置
spring: # zipkin配置 zipkin: base-url: http://192.168.2.102:8888 # zipkin服务地址 discovery-client-enabled: false # 禁止zipkin把自己当做nacos-client向nacos-server注册 # sleuth配置 sleuth: sampler: rate: 100 # sleuth抽样率默认是10%，设置为100表示100%请求上报zipkin
4、启动服务并调用接口
当调用完某个接口时，在zipkin的UI界面上点击查询即可看到调用关系
点击SHOW可以看到下面的具体内容
