由来
在分布式应用开发过程中，一个请求会调用多个应用，会有那种需要知道各个应用之间耗时的想法，这样可以知道一个调用的总时长以及各个组件之间的处理耗时，后面方便定位问题。
理论依据
起源于 google dapper 论文
https://research.google/pubs/pub36356/
具体文档链接
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf
通过论文标题上面的日期，得知在2010 年4月发表
实现组件
Spring Cloud Sleuth
spring 的开发团队在开发了 spring 的产品后，后面又开发了 spring boot 和 spring cloud。
之前写的一篇文章
https://blog.csdn.net/zlpzlpzyd/article/details/132779246
从 maven 仓库上发布的代码时间得知
spring cloud commons 相关的代码在最早是 2015 年，Spring Cloud Sleuth 最早是2016年发布。
但是最近查看Spring Cloud Sleuth官网文档时发现如下内容
Spring Cloud Sleuth 最后的版本是 3.1.x，从这个版本之后移动到 Micrometer Tracing 项目中。
Micrometer Tracing
https://micrometer.io/docs/tracing
意思就是 Spring Cloud Sleuth 从 Spring Cloud 中分离出来单独创建一个项目 Micrometer Tracing，在 2022年11月发布了 1.0.0 GA 版本。
spring 现在属于 vmware，Micrometer 也属于 vmware，属于同一家公司的产品，它们之间的关系类似于异步非阻塞组件 reactor 与 spring webflux 的关系。总之，都是 vmware 的产品。
链路追踪这块通过 Micrometer 制定了一个规范，也就是 SPI，其他的一些厂商可以自己去实现对应的链路跟踪相关功能。
目前针对 Micrometer 规范的实现有两个组件
OpenZipkin Brave
https://github.com/openzipkin/brave
可以引用 zipkin 的相关功能。
在 spring-cloud-dependencies-2022.0.0 中，sleuth 相关依赖被移除。
即如果使用了 spring boot 3.x 版本，那就无法使用 Spring Cloud Sleuth了。需要通过 Micrometer 进行适配。
OpenTelemetry
适配方式官网给了具体方式，分为 maven 和 gradle
Spring Cloud Sleuth 迁移到 Micrometer Tracing
https://github.com/micrometer-metrics/tracing/wiki/Spring-Cloud-Sleuth-3.1-Migration-Guide
SPI（Service provider interface）
针对 SPI，日常开发中有很多它的身影。一般的 SPI 都是制定了一个规范，即 java 中的 interface，后面对应的厂商针对这个 interface 编写自己对应的实现。跟设计模式中的策略模式对应。只是 SPI 是针对 java 开发的一个规范，更高层次的规范是论文，比如算法，同一个算法，在不同的编程语言中有不同的实现，但是无论如何，最终执行的结果是一致的。其他方面的规范还有 网络协议 http、tcp、udp 等等。
wiki介绍
https://en.wikipedia.org/wiki/Service_provider_interface
spi 以及对应的实现
jdbc， 对应的驱动实现有，mysql，oracle，postgresql、sqlserver 等等。
servlet，对应的servet 容器实现有，tomcat、undertow、jetty 等等。
slf4j，对应的处理有，logback、apache log4j2 等等。
还有 spring cloud commons 中的定义的接口规范，其中有注册中心，对应的实现有 eureka、consul、nacos 等等。