由来

在分布式应用开发过程中，一个请求会调用多个应用，会有那种需要知道各个应用之间耗时的想法，这样可以知道一个调用的总时长以及各个组件之间的处理耗时，后面方便定位问题。

理论依据

起源于 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 相关依赖被移除。

https://repo.maven.apache.org/maven2/org/springframework/cloud/spring-cloud-dependencies/2022.0.0/spring-cloud-dependencies-2022.0.0.pom

即如果使用了 spring boot 3.x 版本，那就无法使用 Spring Cloud Sleuth了。需要通过 Micrometer 进行适配。

OpenTelemetry

https://opentelemetry.io/

适配方式官网给了具体方式，分为 maven 和 gradle

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 等等。