服务跟踪，就是跟踪你的整个流程，查看一些每个微服务的耗时。
为什么要实现微服务的跟踪：
谈到微服务的服务跟踪，就不得不提一些分布式计算的八大误区：
1.网络可靠
2.延迟为零
3.宽带无限
4.网络绝对安全
5.网络拓扑不会改变
6.必须有一名管理员
7.传输成本为零
8.网络同质化
从这些问题可以看出，网络是很大的一个问题，网络并不可靠，而且网络资源是有限的。
sleuth的一些术语：
span(跨度)：基本的工作单元。span用一个64位的id唯一标示。除ID外，span还包含其他数据，例如描述，时间戳事件，键值对的注解(标签),spanID,span父ID等。span被启动和停止时，记录了时间信息。初始化span被称为"root span",该span的id和trace的ID相等。
trace(跟踪)：一组共享"root span"的span组成的树状结构称为trace。trace也是用一位64位的ID唯一标识，trace中的所有span都共享trace的ID。
annotation(标注)：annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。
--CS(Client Sent 客户端发送):客户端发起一个请求，该annotation描述span的开始
--SR(Server Received服务器端接收):服务器端得到请求并准备处理它。如果用SR减去CS时间戳，就可以得到网络延迟。
--SS(Server Sent服务器端发送)：该annotation表明完成请求处理(当响应发回客户端时)。如果用SS减去SR时间戳，就能得到服务器端处理请求所需的时间。
--CR(Client Received客户端接收)：span结束的标识。客户端成功接收到服务器端的响应。如果用CR减去CS的时间戳就可以得到从客户端发送请求到服务端响应的所需的时间。
为了实现请求跟踪， 当请求发送到分布式系统的入口端点时， 只需要服务跟踪框架为该请求创建一个唯一的跟踪标识， 同时在分布式系统内部流转的时候，框架始终保待传递 该唯一标识， 直到返回给请求方为止， 这个唯一标识就是Trace ID。 通过TraceID的记录， 我们就能将所有请求过程的日志关联起来。
为了统计各处理单元的时间延迟， 当请求到达各个服务组件时， 或是处理逻辑到达某个状态时， 也通过一个唯一标识来标记它的开始、 具体过程以及结束， 该标识就是前文中提到的SpanID。 对于每个Span来说， 它必须有开始和结束 两个节点， 通过记录开始 Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外， 它还可以包含一些其他元数据， 比如事件名称、 请求信息等。第二篇会重点介绍的。
基于sleuth，我们可以轻松实现了日志级别的跟踪信息接入。在 Spring Boot 应用中， 通过在工程中引入sleuth 依赖之后， 它会自动为当前应用构建起各通信通道的跟踪机制， 比如：
• 通过诸如 RabbitMQ、 Kafka(或者其他任何 Spring Cloud Stream 绑定器实现的消息中间件)传递的请求。
• 通过 Zuul 代理传递的请求。
• 通过 RestTemplate 发起的请求。
抽样收集：
通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪， 而记录的跟踪信息最终会被分析系统收集起来， 并用来实现对分布式系统的监控和分析功能，比如，预警延迟过长的请求链路、查询请求链路的调用明细等。此时，我们在对接分析系统时就会碰到一个问题：分析系统在收集跟踪信息的时候，需要收集多少跟踪信息才合适呢？
理论上来说，我们收集的跟踪信息越多就可以越好地反映出系统的实际运行情况，并给出更精准的预警和分析。但是在高并发的分布式系统运行时，大量的请求调用会产生海量的跟踪日志信息， 如果收集过多的跟踪信息将会对整个分布式系统的性能造成一定的影响， 同时保存大量的日志信息也需要不少的存储开销。 所以， 在 Sleuth 中采用了抽象收集的方式来为跟踪信息打上收集标记， 也就是我们之前在日志信息中看到的第4个布尔类型的值， 它代表了该信息是否要被后续的跟踪信息收集器获取和存储。
Sleuth 中的抽样收集策略是通过 Sampler 接口实现的， 它的定义如下：
package org.springframework.cloud.sleuth; public interface Sampler { boolean isSampled(Span var1); }
通过实现 isSarnpled 方法，Spring Cloud Sleuth 会在产生跟踪信息的时候调用它来为跟踪信息生成是否要被收集的标志。 需要注意的是， 即使 isSampled 返回了 false, 它仅代表该跟踪信息不被输出到后续对接的远程分析系统（比如 Zipkin), 对于请求的跟踪活动依然会进行， 所以我们在日志中还是能看到收集标识为 false 的记录。
默认情况下，Sleuth 会使用 PercentageBasedSarnpler 实现的抽样策略，以请求百分比的方式配置和收集跟踪信息。 我们可以通过在 application.properties 中配置下面的参数对其百分比值进行设置， 它的默认值为0 .1, 代表收集10%的请求跟踪信息。可以修改为1。
spring.sleuth.sampler.percentage=1
当然我们也可以实现Sampler接口 自定义抽样的策略。
package com.yjp.sleuth.controller; import org.springframework.cloud.sleuth.Sampler; import org.springframework.cloud.sleuth.Span; /** * 实现一个仅包含指定Tag的抽样策略 */ public class TagSampler implements Sampler { private String tag; public TagSampler(String tag) { this.tag = tag; } @Override public boolean isSampled(Span span) { return span.tags().get(tag) != null; } }
Sleuth这个组件更多的是一边实践一边说原理的。
这一章就说到这里了。
努力吧，皮卡丘。