sleuth的相关配置
# Sleuth的相关配置
## 为什么要用Sleuth链路追踪?
> **我们的项目即使不复杂, 但是不免会有一个复杂的操作, 如果该操作调用链路很长, 而且最终执行出来的效果很差(出现了异常 或 响应时间很长), 此时, 我们就需要去找到导致这些结果的原因**
> **为了找出原因, 我们引入了链路追踪, 通过链路排查问题, 如果没有链路追踪, 手动的去排查调用过程中的问题, 那将是一件非常困难的事**
> <font color='red'>**总结: Sleuth可以帮我们快速的定位错误发生的链路和执行时间很短的链路, 快速帮我们定位问题**</font>
## 基本术语
### Span(跨度)
> <font color="blue">**跨度事是基本的工作单元, 比如发送一个远程请求或者接受一个远程请求都需要一个跨度, 因此, 一个微服务至少会出现两个及以上的跨度(有些跨度仅仅作为执行逻辑代码的单元, 并不参与发送或接受请求)**</font>
> 跨度是用一个64位的ID唯一标识的, 跨度还存储其他信息, 如: 摘要, 时间戳时间, 跨度ID 以及 进度ID
> <font color="green">**发送请求和接受请求的跨度一般都是同一个跨度, 如果某个跨度不参与请求, 则这个跨度会被抛弃**</font>
> **跨度之间会记录父子关系, 通过这层父子关系, 我们就可以推算出整个调用逻辑**
### Trace(追踪)
> 从一个入口资源开始, 经历一系列的调用逻辑, 最终返回, 这被称为一个追踪, **一个追踪可能含有多个跨度**
> 追踪是用一个64位的ID唯一标识的
### Annotation(标注)
> 整个追踪中, 跨度可能担任不同的角色, 为了区分跨度的职责, 因此引入了标注
#### CS - Client Sent
> 客户端发送, 一般是指发送请求的跨度
#### SR - Server Received
> 服务端接受, 一般指接受请求的跨度
> **如果我们知道了SR和CS, 就可以用SR - CS, 就可以算出两个跨度传输信息的时间, 即网络传输的时间**
#### SS - Server Sent
> 服务端发送, 一般是指执行完业务后的跨度, 该跨度需要发送请求
> **如果我们知道SR和SS, 就可以用SS - SR, 就可以算出这个业务究竟执行了多长时间**
#### CR - Client Received
> 客户端接受, 一般是整个业务执行完了, 接受响应的跨度
> **如果我们知道CR 和 SS, 我们就可以用CR -SS, 就可以算出响应过程, 网络传输的时间**
## 案例分析
### 微服务调用逻辑
### Sleuth链路追踪的结果
> 跨度A: 属于X调用链路, 角色当前为SR(服务器接受前端请求)
> 跨度B: 属于X调用链路, 角色当前为CS(service1 通过该跨度调用 service2)
> 跨度B: 属于X调用链路, 角色当前为SR(该跨度接受请求, 一般发送和接受的跨度是一样的)
> 跨度C: 属于X调用链路, 该跨度主要是用于执行业务逻辑, 并不与请求打交道, 因此没有任何的角色, 也不参与链路追踪
> 跨度D: 属于X调用链路, 角色当前为CR(service2 异步调用 service3)
> 跨度E: 属于X调用链路, 该开度主要适用于执行业务逻辑, 同理没有角色, 不参与链路追踪
> 其他同理, 跨度的发送和接受是同一个跨度, 共同组成了一个调用链
### 跨度的父子关系
## 整合Sleuth&Zipkin
1. 创建容器
```shell
docker run -d -p 9411:9411 --restart=always openzipkin/zipkin
```
2. pom
```xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>
```
> **注意, 虽然我们的zipkin的dashboard是最新的, 但是, 我们的依赖不能是最新的, 一旦最新, 会发生类找不到的异常`Caused by: java.lang.ClassNotFoundException:org.springframework.boot.actuate.health.CompositeHealthContributor`, 这是因为我之前用的是`2.2.1.RELEASE`版本, 换成如上版本才能成功运行**
3. yaml
```yaml
zipkin:
base-url: http://192.168.10.131:9411/ # zipkin服务器地址
discovery-client-enabled: false # 关闭服务发现, 屏蔽zipkin的url, 避免当作服务名
sender:
type: web # http形式传输数据
sleuth:
sampler:
probability: 0.5
```
# sleuth的使用技巧
## 如何通过链路追踪查找错误?
> **如上所示, 当我们链路追踪的时候, 如果出现了红色的进度条, 说明这个链路的调用有问题, 然后我们取到该调用逻辑的最后一个过程, 如上所示, 发现是订单微服务没有正常启动而导致的异常, 此刻, 我们就可以通过异常来解决问题**
## 依赖分析
> 这里的依赖图, 整体展现出了微服务之间的相互调用关系, 可以从大致看出它们的调用逻辑, 并不是链路追踪调优的重点