聊聊 SpringBoot3 的 Micrometer Tracing _SpringBoot

这是个很尴尬的话题，为什么这么说呢？当我们在讨论卷和造轮子两个事情的时候，SpringBoot 的开发人员也正在做着同样的事情...

回顾之前在微服务-分布式链路这篇文章中我介绍了 DApper、Opentracing，并以蚂蚁分布式链路组件 SOFATracer 为例，较为详细的说明了分布式链路组件中的一些技术细节和实现方式，有兴趣的同学可以自行查看。
Micrometer Tracing
最近关注 SpringBoot3 的发布，在 Production-ready Features 中，首次将 tracing 作为一个单独的功能项写进官方文档中；在此之前 SpringBoot 仅提供了 Http Tracing 的能力，并且默认情况下，是在内存中存储近 100 次请求的记录；在 2.7.x 的官方文档中，Http Tracing 只是建议在开发环境使用，对于生产环境，官方文档也明确的指出，建议使用 Zipkin 或 Spring Cloud Sleuth 这类比较成熟的可观测性解决方案。
从 Dapper 到 OpenTracing，解决了厂商无关和统一链路 API 的问题，从 OpenTracing 到 OpenTelemetry，解决统一可观测性 API 的问题，并且 OpenTelemetry 从 2019-5.7 被 CNCF Accepted 之后，也在不断地孵化和完善。如果说 SpringBoot 面向 OpenTelemetry 提供 Tracing，可能更便于接受，但是 SpringBoot 却使用了 Micrometer tracing，并且通过 Facade 进行了桥接 Brave 和 otel 。
首先一点是，SpringBoot 将 Tracing 在 v3 系列提供出来比较容易理解，在可观测性上，tracing 一直都是 SpringBoot 缺失的，在 SpringCloud 中，它通过 Spring Cloud Slueth 整合了 Brave 补缺了这一环。
比较疑惑的是，SpringBoot 提供的 tracing 为什么会选择使用一个新的 facade Micrometer tracing 来实现，这一点我尝试从 issue 中去找答案，但也没有找到比较有说服力的，比如 Add auto-configuration for Micrometer 2.0 Observation API 和 Add support for Micrometer tracing 。不过有意思的是，在 spring.io/projects/sp… 这里给出了一些信息，意思就是 Spring Cloud Slueth 将迁移到 Micrometer tracing 。
【聊聊 SpringBoot3 的 Micrometer Tracing】那么关于为什么 SpringBoot 使用 Micrometer 而不是 OpenTelemetry，可能有以下几点原因（一家之言，欢迎指导）：

1、在之前的一些版本中，Micrometer 关注更多是 metrics，而 OpenTelemetry 则更多关注 tracing，但是随着版本的迭代完善，Micrometer 和 OpenTelemetry 在 metrics 和 tracing API 上基本都具备了。重要的是，在此之前，SpringBoot 已经对 Micrometer Metrics 进行了支持，所谓近水楼台先得月。
2、OpenTelemetry 的目标是厂商无关，语言无关，penTelemetry 更适合在异构技术栈中发挥作用；而 Micrometer 一直以来都是基于 JAVA 语言，这与 Spring 体系从根上是一致的。
3、Micrometer API 进行大量更改。最重要的变化是引入了一个新的 API：Observation API，这样便于使用者能够使用统一的 API 来观测业务代码，包括 metrics，tracing 以及 logging 。

下面就 SpringBoot3 Tracing 展开聊聊。
SpringBoot3 Tracing 剖析
SpringBoot3 在 Spring Boot Actuator 中为 Micrometer Tracing 的依赖性管理和自动配置。Micrometer Tracing 充当了类似日志领域内 slf4j 门面的角色。
Micrometer Tracing API
Micrometer Tracing 中的相关概念也是借用 Dapper 的，比如 Span，Trace 等，这里不做过多介绍。总体来说，Micrometer Tracing 包括以下几个部分：