Spring Cloud链路追踪排行榜：SkyWalking vs OpenTelemetry

Spring全家桶之Spring Cloud 2023.0.x链路追踪知识体系

先说一个对Ja va微服务团队至关重要的变化：Spring Cloud 2023.0.x（代号Leyton）在链路追踪领域动了一次“大手术”——彻底放弃了Spring Cloud Sleuth，全面拥抱OpenTelemetry。这意味着什么？如果你还在用Sleuth做追踪，未来几个版本将不再获得官方维护，迁移几乎是必然选择。下面从架构变迁到最佳实践，把整套知识体系拆开揉碎讲清楚。

一、核心背景与架构演进

1.1 Spring Cloud 2023.0.x链路追踪重大变革

Spring Cloud 2023.0.x（Leyton）是里程碑式版本，在链路追踪领域发生了根本性转变：

• 官方弃用Spring Cloud Sleuth：自2023.0.x版本起，Spring Cloud不再维护Sleuth项目，将其所有功能迁移至OpenTelemetry。
• OpenTelemetry成为官方唯一推荐：Spring Cloud官方提供了spring-cloud-starter-opentelemetry系列starter，实现了与OpenTelemetry的深度集成。
• 架构理念升级：从“单一追踪工具”转向“统一可观测性标准”，支持Traces、Metrics、Logs三位一体。

1.2 链路追踪在微服务架构中的核心价值

• 问题定位：快速定位分布式系统中的性能瓶颈和错误根源。
• 依赖分析：自动发现服务间调用关系，生成服务拓扑图。
• 性能优化：量化每个服务和接口的响应时间、吞吐量。
• 业务监控：追踪关键业务流程的执行情况，保障SLA。
• 容量规划：基于历史数据预测系统负载，指导资源扩容。

1.3 SkyWalking与OpenTelemetry的关系定位

最佳实践：将OpenTelemetry作为统一的数据采集层，SkyWalking作为后端存储和分析平台，形成“标准采集 + 专业分析”的完整链路追踪解决方案。

二、OpenTelemetry核心知识体系

2.1 OpenTelemetry核心概念

• Trace：一次分布式请求的完整调用链，由多个Span组成。
• Span：一次独立的操作单元，包含操作名称、开始时间、持续时间、标签、事件等。
• Context：在服务间传递的上下文信息，包含Trace ID、Span ID等。
• Propagator：负责在不同服务和进程间传播Context的组件。
• Instrumentation：用于采集特定库或框架追踪数据的代码。
• Exporter：将采集到的数据导出到后端系统的组件。
• Processor：在数据导出前对其进行处理的组件（如批量处理、过滤）。

2.2 OpenTelemetry架构

OpenTelemetry采用分层架构，从上到下分为：

• 应用层：用户编写的业务代码。
• API层：提供给应用开发者使用的标准接口。
• SDK层：API的具体实现，包含TracerProvider、MeterProvider、LoggerProvider。
• Instrumentation层：针对各种库和框架的自动或手动埋点。
• Exporter层：将数据导出到不同的后端系统。
• Collector层：可选的中间件，用于接收、处理和转发可观测性数据。

2.3 Spring Cloud 2023.0.x OpenTelemetry集成

2.3.1 核心依赖

    org.springframework.cloud
    spring-cloud-starter-opentelemetry



    io.opentelemetry.exporter
    opentelemetry-exporter-otlp



    org.springframework.boot
    spring-boot-actuator-autoconfigure

2.3.2 关键配置

spring:
  application:
    name: order-service
  opentelemetry:
    enabled: true
    traces:
      exporter: otlp
      sampler: parent-based_always_on
    metrics:
      exporter: otlp
    logs:
      exporter: otlp
    exporter:
      otlp:
        endpoint: http://otel-collector:4318
        timeout: 10s

2.3.3 自动埋点支持

Spring Cloud OpenTelemetry starter自动为以下组件提供埋点：

• Spring Web/MVC/WebFlux
• Spring Data JPA/Redis/MongoDB
• Spring Cloud Gateway
• Spring Cloud OpenFeign
• Spring Cloud Stream Kafka/RabbitMQ
• JDBC/MySQL/PostgreSQL

2.4 OpenTelemetry Collector

OpenTelemetry Collector是一个独立的进程，用于集中接收、处理和导出可观测性数据。它采用管道式架构：

• Receivers：接收来自不同来源的数据（如OTLP、Jaeger、Zipkin）。
• Processors：对数据进行处理（如批量处理、过滤、转换、采样）。
• Exporters：将处理后的数据导出到不同的后端系统（如SkyWalking、Prometheus、Elasticsearch）。
• Extensions：提供额外的功能（如健康检查、服务发现）。

三、SkyWalking核心知识体系

3.1 SkyWalking核心概念

• Service：一个独立的应用或服务。
• Service Instance：服务的一个运行实例。
• Endpoint：服务提供的一个接口或方法。
• Trace：一次分布式请求的完整调用链。
• Segment：一个服务实例内的一段调用链。
• Span：一次独立的操作单元。
• Metric：系统或服务的性能指标。
• Log：应用程序输出的日志信息。

3.2 SkyWalking架构

SkyWalking采用分布式架构，主要由以下组件组成：

• Agent：部署在应用程序中，负责采集追踪数据和性能指标。
• OAP Server：接收Agent发送的数据，进行分析和存储。
• Storage：数据存储层，支持Elasticsearch、MySQL、TiDB等。
• UI：提供可视化界面，展示追踪数据、性能指标和服务拓扑。
• Alarm：告警系统，根据预设规则触发告警。

3.3 Spring Cloud 2023.0.x SkyWalking集成

3.3.1 Ja va Agent集成（推荐）

这是SkyWalking最常用的集成方式，无需修改代码，只需在启动时添加agent参数：

ja va -ja vaagent:/path/to/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=skywalking-oap:11800 \
     -jar order-service.jar

3.3.2 OpenTelemetry集成（Spring Cloud 2023.0.x推荐）

由于Spring Cloud 2023.0.x官方推荐使用OpenTelemetry，因此最佳实践是通过OpenTelemetry采集数据，然后导出到SkyWalking：

spring:
  opentelemetry:
    exporter:
      otlp:
        endpoint: http://skywalking-oap:11800/v1/traces

3.4 SkyWalking核心功能

• 分布式链路追踪：展示完整的调用链，支持查看每个Span的详细信息。
• 服务拓扑图：自动生成服务间的调用关系图。
• 性能指标监控：监控服务的响应时间、吞吐量、错误率等指标。
• 日志分析：将日志与追踪数据关联，实现“一站式”问题排查。
• 告警系统：支持基于指标和追踪数据的告警规则。
• 数据库监控：监控SQL语句的执行性能。
• 网关监控：监控Spring Cloud Gateway的请求流量和性能。

四、Spring Cloud 2023.0.x链路追踪最佳实践

4.1 技术选型建议

4.2 采样策略

合理的采样策略可以在保证问题排查能力的同时，降低系统开销：

• AlwaysOnSampler：采集所有请求，适用于测试环境和低流量生产环境。
• AlwaysOffSampler：不采集任何请求，适用于性能测试。
• ParentBasedSampler：根据父Span的采样决策决定是否采样，是最常用的策略。
• TraceIdRatioBasedSampler：根据Trace ID的比例进行采样，适用于高流量生产环境。
• 自定义Sampler：根据业务规则进行采样，如只采集错误请求或慢请求。

4.3 自定义埋点

在自动埋点无法满足需求时，可以进行手动埋点：

@RestController
public class OrderController {
    private final Tracer tracer;
    public OrderController(Tracer tracer) {
        this.tracer = tracer;
    }
    @GetMapping("/orders/{id}")
    public Order getOrder(@PathVariable Long id) {
        Span span = tracer.spanBuilder("getOrder")
                .setAttribute("order.id", id)
                .startSpan();
        try (Scope scope = span.makeCurrent()) {
            // 业务逻辑
            return orderService.getOrder(id);
        } catch (Exception e) {
            span.recordException(e);
            span.setStatus(StatusCode.ERROR, e.getMessage());
            throw e;
        } finally {
            span.end();
        }
    }
}

4.4 性能优化

• 合理设置采样率：高流量环境下建议使用10%以下的采样率。
• 批量导出数据：使用BatchSpanProcessor减少网络请求次数。
• 限制Span数量：避免在一个Trace中创建过多的Span。
• 优化Agent配置：根据应用特点调整Agent的参数。
• 使用异步导出：避免数据导出阻塞业务线程。

五、常见问题与解决方案

5.1 链路不完整

• 问题原因：Context传播失败、某些组件未被埋点、跨语言调用不兼容。
• 解决方案：
  • 确保所有服务都使用相同的Context传播协议（如W3C TraceContext）。
  • 检查是否缺少必要的Instrumentation依赖。
  • 对于跨语言调用，确保双方都支持相同的传播协议。

5.2 性能开销过高

• 问题原因：采样率过高、Span数量过多、数据导出频繁。
• 解决方案：
  • 降低采样率，使用基于Trace ID的比例采样。
  • 减少不必要的自定义埋点。
  • 增加批量导出的大小和间隔。
  • 使用OpenTelemetry Collector进行集中处理。

5.3 数据丢失

• 问题原因：网络不稳定、OAP Server负载过高、存储系统性能不足。
• 解决方案：
  • 增加重试机制和超时时间。
  • 扩容OAP Server集群。
  • 优化存储系统的性能。
  • 使用本地缓存暂存数据。

5.4 从Sleuth迁移到OpenTelemetry

• 步骤1：移除Sleuth相关依赖。
• 步骤2：添加OpenTelemetry相关依赖。
• 步骤3：修改配置文件，将Sleuth配置转换为OpenTelemetry配置。
• 步骤4：替换自定义埋点代码，使用OpenTelemetry API。
• 步骤5：测试链路追踪功能是否正常工作。

六、未来发展趋势

• OpenTelemetry成为行业标准：越来越多的厂商和项目将支持OpenTelemetry。
• 可观测性一体化：Traces、Metrics、Logs将更加紧密地集成。
• AI驱动的可观测性：利用AI技术自动分析可观测性数据，预测和预防问题。
• eBPF技术的应用：使用eBPF技术实现更高效、更低侵入性的数据采集。
• 服务网格集成：与Istio等服务网格深度集成，实现全栈可观测性。

Spring Cloud 2023.0.x 链路追踪面试高频问答卡片

（按考点优先级排序，答案精炼为背诵版，突出得分点）

一、核心背景与架构演进（★★★★★ 最新版本必问）

Q1：Spring Cloud 2023.0.x（Leyton）在链路追踪领域发生了哪些根本性变革？

标准答案：

• 官方弃用Spring Cloud Sleuth：自2023.0.x起停止维护，所有功能迁移至OpenTelemetry。
• OpenTelemetry成为唯一官方推荐：提供spring-cloud-starter-opentelemetry系列starter深度集成。
• 架构理念升级：从“单一追踪工具”转向“统一可观测性标准”，支持Traces、Metrics、Logs三位一体。

Q2：链路追踪在微服务架构中的核心价值是什么？

标准答案：

• 问题定位：快速定位分布式系统的性能瓶颈和错误根源。
• 依赖分析：自动发现服务间调用关系，生成服务拓扑图。
• 性能优化：量化每个服务/接口的响应时间、吞吐量。
• 业务监控：追踪关键业务流程，保障SLA。
• 容量规划：基于历史数据预测系统负载，指导资源扩容。

Q3：OpenTelemetry和SkyWalking的核心区别与关系是什么？

标准答案：

最佳实践：OpenTelemetry作为统一采集层，SkyWalking作为后端分析平台，形成“标准采集 + 专业分析”方案。

二、OpenTelemetry核心知识体系（★★★★★ 核心考点）

Q4：OpenTelemetry的核心概念有哪些？

标准答案：

• Trace：一次分布式请求的完整调用链，由多个Span组成。
• Span：独立操作单元，包含名称、时间、标签、事件等。
• Context：服务间传递的上下文（Trace ID、Span ID）。
• Propagator：负责Context跨服务/进程传播的组件。
• Instrumentation：针对库/框架的自动/手动埋点代码。
• Exporter：将数据导出到后端系统的组件。
• Processor：数据导出前的预处理组件（批量、过滤）。

Q5：OpenTelemetry的分层架构是怎样的？

标准答案：从上到下分为6层：

• 应用层：用户业务代码。
• API层：开发者使用的标准接口。
• SDK层：API的具体实现（Tracer/Meter/LoggerProvider）。
• Instrumentation层：自动/手动埋点。
• Exporter层：导出到后端系统。
• Collector层：可选的集中式数据接收、处理、转发中间件。

Q6：Spring Cloud 2023.0.x集成OpenTelemetry需要哪些核心依赖和关键配置？

标准答案：

• 核心依赖：
  • spring-cloud-starter-opentelemetry（核心starter）
  • opentelemetry-exporter-otlp（OTLP协议导出）
  • spring-boot-actuator-autoconfigure（自动配置支持）
• 关键配置：

spring:
  opentelemetry:
    enabled: true
    traces:
      exporter: otlp
      sampler: parent-based_always_on
    exporter:
      otlp:
        endpoint: http://otel-collector:4318

Q7：OpenTelemetry Collector的作用和管道式架构是什么？

标准答案：

• 作用：独立进程，集中接收、处理、转发可观测性数据，解耦应用与后端。
• 管道式架构：
  • Receivers：接收多源数据（OTLP、Jaeger、Zipkin）。
  • Processors：数据处理（批量、过滤、转换、采样）。
  • Exporters：导出到多后端（SkyWalking、Prometheus、ES）。
  • Extensions：额外功能（健康检查、服务发现）。

三、SkyWalking核心知识体系（★★★★ 高频考点）

Q8：SkyWalking的核心概念有哪些？

标准答案：

• Service：独立应用/服务。
• Service Instance：服务的一个运行实例。
• Endpoint：服务提供的接口/方法。
• Trace：分布式请求完整调用链。
• Segment：一个服务实例内的调用链片段。
• Metric：系统/服务性能指标。
• Log：应用日志信息。

Q9：SkyWalking的分布式架构由哪些组件组成？

标准答案：

• Agent：部署在应用中，无侵入采集追踪数据和指标。
• OAP Server：接收数据，进行分析和存储。
• Storage：数据存储层（支持Elasticsearch、MySQL、TiDB）。
• UI：可视化界面（展示追踪、指标、服务拓扑）。
• Alarm：告警系统，根据预设规则触发告警。

Q10：Spring Cloud 2023.0.x集成SkyWalking的两种方式及区别？

标准答案：

• 传统Ja va Agent集成：
  • 方式：启动时添加-ja vaagent参数。
  • 优点：无代码侵入，功能完善。
  • 缺点：不符合Spring Cloud 2023.0.x官方标准。
• OpenTelemetry集成（官方推荐）：
  • 方式：通过OTLP协议将OpenTelemetry采集的数据导出到SkyWalking。
  • 配置：spring.opentelemetry.exporter.otlp.endpoint=http://skywalking-oap:11800/v1/traces。
  • 优点：符合官方标准，未来兼容性好。

Q11：SkyWalking的核心功能有哪些？

标准答案：

• 分布式链路追踪：完整调用链展示与Span详情。
• 服务拓扑图：自动生成服务间调用关系。
• 性能指标监控：响应时间、吞吐量、错误率。
• 日志分析：日志与追踪数据关联，一站式排查。
• 告警系统：基于指标和追踪数据的告警规则。
• 数据库监控：SQL执行性能分析。
• 网关监控：Spring Cloud Gateway流量与性能监控。

四、最佳实践（★★★★ 实操必问）

Q12：不同场景下链路追踪的技术选型建议是什么？

标准答案：

Q13：OpenTelemetry常用的采样策略有哪些？各自适用什么场景？

标准答案：

• AlwaysOnSampler：采集所有请求 → 测试环境、低流量生产。
• AlwaysOffSampler：不采集任何请求 → 性能测试。
• ParentBasedSampler：继承父Span采样决策 → 最常用，保证链路完整性。
• TraceIdRatioBasedSampler：按Trace ID比例采样 → 高流量生产环境。
• 自定义Sampler：按业务规则采样 → 只采集错误请求或慢请求。

Q14：OpenTelemetry自定义埋点的标准步骤是什么？

标准答案：

• 注入Tracer对象。
• 使用tracer.spanBuilder()创建Span并设置属性。
• 使用try-with-resources包裹span.makeCurrent()管理上下文。
• 异常时调用span.recordException()和span.setStatus(StatusCode.ERROR)。
• 在finally块中调用span.end()确保Span结束。

Q15：链路追踪系统的性能优化措施有哪些？

标准答案：

• 合理设置采样率：高流量环境建议10%以下。
• 批量导出数据：使用BatchSpanProcessor减少网络请求。
• 限制单个Trace的Span数量，避免过度埋点。
• 优化Agent配置，关闭不必要的Instrumentation。
• 使用异步导出，避免阻塞业务线程。
• 引入OpenTelemetry Collector进行集中处理。

五、常见问题与解决方案（★★★ 经验题）

Q16：分布式链路追踪中链路不完整的常见原因及解决方案？

标准答案：

• 原因：Context传播失败、组件未被埋点、跨语言调用不兼容。
• 解决方案：
  • 统一使用W3C TraceContext传播协议。
  • 检查并补充缺失的Instrumentation依赖。
  • 确保跨语言服务支持相同的传播协议。

Q17：链路追踪系统性能开销过高的原因及解决方法？

标准答案：

• 原因：采样率过高、Span数量过多、数据导出频繁。
• 解决方案：
  • 降低采样率，使用TraceIdRatioBasedSampler。
  • 减少不必要的自定义埋点。
  • 增加批量导出的大小和间隔。
  • 使用OpenTelemetry Collector集中处理数据。

Q18：从Spring Cloud Sleuth迁移到OpenTelemetry的步骤是什么？

标准答案：

• 移除所有Sleuth相关依赖。
• 添加OpenTelemetry核心依赖和OTLP导出依赖。
• 将Sleuth配置转换为OpenTelemetry配置。
• 替换自定义埋点代码，使用OpenTelemetry API。
• 测试链路追踪功能是否正常工作。

六、未来发展趋势（★★ 拓展题）

Q19：分布式链路追踪和可观测性领域的未来发展趋势是什么？

标准答案：

• OpenTelemetry成为行业统一标准。
• Traces、Metrics、Logs三位一体深度融合。
• AI驱动的可观测性：自动分析、预测和预防问题。
• eBPF技术应用：实现更高效、更低侵入性的数据采集。
• 与Istio等服务网格深度集成，实现全栈可观测性。

背诵技巧

• 优先背诵标★★★★★的最新版本考点和核心概念。
• 表格类内容对比记忆，抓住核心区别点。
• 实操类问题按步骤记忆，形成流程化思维。
• 问题解决类问题先记原因，再对应记解决方案。

来源：互联网