目录
[📈 核心趋势：OpenTelemetry 统一江湖](#📈 核心趋势：OpenTelemetry 统一江湖)
[🧩 主流技术方案对比](#🧩 主流技术方案对比)
[💡 如何为你的项目选择？](#💡 如何为你的项目选择？)
Java分布式链路追踪技术，本质上是为流经复杂微服务的每个请求创建一张"数字化地图"，让你能清晰地看到请求的完整路径、每一站点的耗时以及可能出现的异常。这项技术正经历着一场重大的技术换代。
当前最核心的趋势是：技术标准已从过去的"百花齐放"走向"统一"，OpenTelemetry 已成为新一代的事实标准，而曾经的入门首选 Spring Cloud Sleuth 则正式退役。
📈 核心趋势：OpenTelemetry 统一江湖
过去，Java链路追踪技术栈较为分散，有基于规范如OpenTracing的，也有各框架自带的解决方案。现在，由OpenTracing和OpenCensus合并而来的 OpenTelemetry（简称OTel），作为CNCF孵化项目，已一统天下。它的核心优势在于：
-
厂商中立：一次埋点，数据可同时导出到Jaeger、Zipkin、Prometheus等不同后端，避免被单一厂商锁定。
-
数据统一：不仅管链路（Traces），还能统一处理日志（Logs）和指标（Metrics），实现真正的可观测性。
与之对应的是，Spring Cloud生态原有的 Spring Cloud Sleuth 已停止维护，官方推荐使用其桥接模块迁移至OpenTelemetry。对于所有新项目，都应直接基于OpenTelemetry构建。
🧩 主流技术方案对比
在OpenTelemetry的大框架下，你可以根据项目的侵入性要求和控制粒度，选择不同的落地方式。以下是对当前主流方案的梳理：
| 方案类别 | 技术选型 | 核心特点 | 适用场景 |
|---|---|---|---|
| 新一代事实标准 | OpenTelemetry (OTel) | 统一标准，厂商中立，支持Trace、Metrics、Logs三大信号。通过Java Agent或SDK集成。 | 所有新项目首选，追求长期技术演进和架构弹性的团队。 |
| 经典轻量级方案 | Zipkin + Brave | 老牌组合，轻量级，部署简单。Brave是Zipkin的Java客户端库。 | 技术栈较传统，仅需基本链路可视化，对OpenTelemetry迁移成本敏感的场景。 |
| 已退役的Spring方案 | Spring Cloud Sleuth | 与Spring Boot生态集成极佳，但已停止维护，功能已并入Micrometer Tracing（基于OTel）。 | 仅适用于维护老项目，新项目严禁使用。 |
| 国产APM代表 | Apache SkyWalking | 功能强大，提供完整的应用性能监控（APM）能力（拓扑图、告警、JVM监控等），对Java业务代码零侵入。 | 需要一站式、开箱即用的APM平台，且希望深入分析服务性能（如方法级耗时）的团队。 |
| 韩国开源APM | Pinpoint | 同样基于字节码注入，零代码侵入，UI功能强大且详尽，数据统计维度丰富。 | 与SkyWalking类似，适合需要极详尽调用信息的场景，但在国内社区活跃度略逊于SkyWalking。 |
| 商业化APM | Datadog, New Relic | 全托管SaaS服务，接入简单，功能强大，自带AI异常检测和全球基础设施监控。 | 中大型企业，预算充足，追求极致效率和开箱即用体验，愿意接受厂商绑定的团队。 |
💡 如何为你的项目选择？
-
如果你是初创团队或新项目，希望紧跟技术趋势 ：强烈推荐 OpenTelemetry 。你可以选择无侵入的 Java Agent 方式快速接入，5分钟即可看到效果。搭配 Jaeger 或 Grafana Tempo 作为后端存储与展示，构成一套完整的云原生可观测性体系。
-
如果你在维护老项目，且使用了Spring Cloud Sleuth ：无需立即重构。但应规划未来，可以逐步引入
micrometer-tracing-bridge-otel等桥接依赖，平滑过渡到OpenTelemetry生态。 -
如果你需要一个功能全面、开箱即用的监控平台，且不想折腾代码 ：Apache SkyWalking 是非常成熟的本土化选择。它提供的不仅仅是链路追踪，还有服务拓扑图、JVM性能分析、告警等一系列功能，部署探针即可。