微服务下多协议混合调用的链路追踪实践：Dubbo与HTTP的挑战与解决之道

2025/9/22 15:32:29 90 0 0 0

从单体架构向微服务转型，这无疑是技术发展的大趋势，它带来了服务独立性、高内聚低耦合等诸多好处。然而，正如你所遇到的，当服务被拆分、部署独立后，随之而来的却是服务间错综复杂的调用关系。用户反馈一个功能卡顿，我们往往一头雾水，不知道问题出在哪个环节，尤其是在请求横跨Dubbo和HTTP服务时，定位问题更是难上加难。

这正是分布式追踪（Distributed Tracing）大显身手的时候。它就像是给你的每一个请求贴上了一个“快递单号”，无论这个请求经过多少个服务、多少层调用，我们都能通过这个“单号”清晰地追踪到它的完整路径，以及在每个服务节点上的耗时情况，从而快速定位性能瓶颈或错误根源。

什么是分布式追踪？

简单来说，分布式追踪就是记录一个请求从接收到响应的全过程，包括它所经过的所有服务、方法调用、数据库操作等，并将这些信息关联起来。其核心概念包括：

Trace（追踪）：表示一个完整的请求链路，从用户发起请求到最终响应的全过程。一个Trace由一个唯一的Trace ID标识。
Span（跨度）：表示Trace中的一个独立操作或逻辑单元，比如一次RPC调用、一次HTTP请求、一个数据库查询。每个Span都有一个唯一的Span ID，并记录了操作的开始时间、结束时间、耗时、所属服务、方法名、标签（Tags）和日志（Logs）等信息。Span之间通过父子关系（Parent Span ID）形成一个树状结构，共同构成了完整的Trace。
Context Propagation（上下文传播）：这是分布式追踪实现的关键。它确保Trace ID和Span ID能在服务调用链路中正确地传递下去，无论是通过HTTP头、RPC元数据还是消息队列。

为何分布式追踪如此重要？

故障排查：当系统出现异常或性能问题时，能够迅速定位是哪个服务、哪个方法调用导致了问题。
性能优化：通过分析Trace数据，找出链路中最慢的Span，从而聚焦优化资源。
服务依赖可视化：了解服务之间的实际调用关系和依赖拓扑。
理解系统行为：帮助团队成员更好地理解复杂微服务系统的工作原理。

主流追踪标准与工具

目前，业界主要有两种分布式追踪的规范和实现：

OpenTracing/OpenCensus：这是两个不同的开源项目，旨在提供一套与厂商无关的API和数据格式，让开发者可以方便地集成不同的追踪系统。
OpenTelemetry：作为OpenTracing和OpenCensus的继任者，OpenTelemetry（简称OTel）旨在提供一套统一的API、SDK和数据协议，用于收集应用层的可观测性数据（包括追踪、指标和日志），是未来的趋势。

在工具层面，常用的开源实现有：

Zipkin：Twitter开源的分布式追踪系统，支持多种语言和框架，其数据模型和API成为了OpenTracing的前身。
Jaeger：Uber开源的分布式追踪系统，兼容OpenTracing API，提供更丰富的UI界面和查询能力，采用Go语言实现，性能较高。

本文将主要围绕OpenTelemetry的思想和Zipkin/Jaeger的使用进行讲解。

Dubbo与HTTP混合调用的追踪实践

既然我们团队面临Dubbo和HTTP服务混合调用的场景，那么关键在于如何在这两种协议中无缝地传递追踪上下文。

1. 核心思路：统一的上下文传播

无论是Dubbo还是HTTP，其核心都是在每次跨服务调用时，将当前的Trace ID、Span ID以及其他必要的上下文信息（如采样决策）通过请求头或元数据传递给下游服务。下游服务收到这些信息后，会基于它们创建新的子Span，并继续传递下去。

2. Dubbo服务的集成

Dubbo作为一个RPC框架，其扩展性非常好，我们可以利用其**Filter（过滤器）**机制来注入追踪逻辑。

原理：在服务提供方接收请求前和返回响应后，以及服务消费方发送请求前和接收响应后，通过Filter截获请求，从中提取或注入追踪上下文。

实现步骤（以OpenTelemetry为例）：

引入依赖：在Dubbo项目中引入OpenTelemetry的相关SDK，例如opentelemetry-api、opentelemetry-sdk、opentelemetry-exporter-zipkin或opentelemetry-exporter-jaeger以及Dubbo的OpenTelemetry集成包（如果官方或社区有提供）。
创建Dubbo Filter：
- 消费方Filter：在发送RPC请求前，从当前ThreadLocal或MDC中获取当前的Trace ID和Span ID，生成一个子Span，并将Trace ID、当前Span ID作为父Span ID以及子Span ID等信息通过Dubbo的Attachment（附加参数）传递给服务提供方。
- 提供方Filter：在接收RPC请求后，从Dubbo的Attachment中提取Trace ID和父Span ID。基于这些信息创建新的Span（作为接收方Span的子Span），并在处理请求完成后结束这个Span。
配置Filter：将自定义的Dubbo Filter配置到Dubbo服务中，确保它能被自动加载和执行。

// 示例伪代码：Dubbo消费方Filter
public class TracingConsumerFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        // 从当前OpenTelemetry Context获取父Span
        Span parentSpan = Span.current();
        // 创建新的子Span，作为RPC调用的Span
        Span span = Tracer.globalTracer()
                         .spanBuilder(invoker.getUrl().getPath() + "." + invocation.getMethodName())
                         .setParent(Context.current().with(parentSpan))
                         .setSpanKind(SpanKind.CLIENT)
                         .startSpan();
        try (Scope scope = span.makeCurrent()) {
            // 将Trace ID和Span ID等信息注入到Dubbo Attachment，传递给下游
            Map<String, String> contextMap = new HashMap<>();
            // 使用TextMapSetter将OpenTelemetry上下文写入到map
            OpenTelemetry.getGlobalPropagators().getTextMapPropagator()
                .inject(Context.current(), contextMap, MapTextMapSetter.INSTANCE);
            
            invocation.addAttachments(contextMap); // 注入到Dubbo附加参数

            return invoker.invoke(invocation);
        } finally {
            span.end();
        }
    }
}

// 示例伪代码：Dubbo提供方Filter
public class TracingProviderFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        // 从Dubbo Attachment中提取Trace ID和Span ID等信息
        Map<String, String> contextMap = new HashMap<>(invocation.getAttachments());
        Context extractedContext = OpenTelemetry.getGlobalPropagators().getTextMapPropagator()
            .extract(Context.current(), contextMap, MapTextMapGetter.INSTANCE);

        // 基于提取的上下文创建新的Span
        Span span = Tracer.globalTracer()
                         .spanBuilder(invoker.getUrl().getPath() + "." + invocation.getMethodName())
                         .setParent(extractedContext) // 设置父Span上下文
                         .setSpanKind(SpanKind.SERVER)
                         .startSpan();

        try (Scope scope = span.makeCurrent()) {
            return invoker.invoke(invocation);
        } finally {
            span.end();
        }
    }
}

注意：OpenTelemetry社区通常会提供针对主流框架（如Dubbo、Spring）的Instrumentation Agent或Libraries，可以直接使用，无需手动编写Filter。例如，如果你使用Java Agent，它可以在运行时自动为Dubbo框架进行字节码增强，实现无侵入的追踪。

3. HTTP服务的集成

对于HTTP服务，追踪上下文的传递通常通过HTTP Header进行。

原理：在发送HTTP请求前，将追踪上下文注入到HTTP请求头中；在接收HTTP请求后，从请求头中提取追踪上下文。

实现步骤（以Spring Boot + OpenTelemetry为例）：

引入依赖：同Dubbo，引入OpenTelemetry相关SDK。
Web服务器端（如Spring MVC）：
- 通常情况下，OpenTelemetry提供了针对Servlet API的Instrumentation Agent或Starter，可以直接通过字节码增强自动处理HTTP请求的追踪。它会从请求头中提取Trace ID，创建新的Span，并在处理请求过程中自动传递上下文。
- 如果你需要手动处理，可以编写一个Servlet Filter或Spring Interceptor：
  - 在请求进入时，从HTTP Header中（例如traceparent、X-B3-TraceId等）提取上下文。
  - 创建或激活Span，并将上下文绑定到当前线程。
  - 在请求完成后，结束Span。
HTTP客户端（如RestTemplate、FeignClient）：
- OpenTelemetry同样提供了针对主流HTTP客户端库的Instrumentation。
- 如果你需要手动处理，可以编写一个Interceptor：
  - 在发送HTTP请求前，从当前线程获取Trace ID和Span ID。
  - 将这些信息注入到HTTP请求头中。
  - 例如，遵循W3C Trace Context标准，注入traceparent和tracestate头。

// 示例伪代码：Spring Web请求处理，通常由OpenTelemetry Agent自动完成
// 但如果需要手动，可以如下：
@RestController
public class MyController {
    @GetMapping("/api/data")
    public String getData(@RequestHeader(value = "traceparent", required = false) String traceparent) {
        Context context = Context.current();
        // 如果traceparent存在，则从HTTP Header中提取上下文
        if (traceparent != null) {
             context = OpenTelemetry.getGlobalPropagators().getTextMapPropagator()
                .extract(Context.current(), Map.of("traceparent", traceparent), MapTextMapGetter.INSTANCE);
        }

        Span span = Tracer.globalTracer().spanBuilder("MyController.getData")
                             .setParent(context)
                             .setSpanKind(SpanKind.SERVER)
                             .startSpan();
        try (Scope scope = span.makeCurrent()) {
            // 业务逻辑...
            return "Data from service";
        } finally {
            span.end();
        }
    }
}

// 示例伪代码：RestTemplate拦截器
public class TracingClientHttpRequestInterceptor implements ClientHttpRequestInterceptor {
    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {
        // 获取当前OpenTelemetry上下文，并注入到HTTP Header
        OpenTelemetry.getGlobalPropagators().getTextMapPropagator()
            .inject(Context.current(), request.getHeaders(), HttpHeadersTextMapSetter.INSTANCE);
        
        return execution.execute(request, body);
    }
}

4. 统一追踪上下文的传播机制

为了确保Dubbo和HTTP服务能够共享同一个追踪上下文，关键在于在业务逻辑代码中，无论请求是从HTTP入口进来，还是从Dubbo入口进来，或者由一个服务调用另一个服务（无论是HTTP还是Dubbo），当前的Span上下文都必须是可用的。OpenTelemetry的Context和Scope机制天然地解决了这个问题。Context是线程本地存储的，当通过Scope将Span激活时，后续在该线程中的操作都会自动关联到这个Span。

核心：保持上下文在线程间的传递。
当一个HTTP请求进来，会创建一个Span并激活它。如果这个HTTP服务又调用了Dubbo服务，Dubbo消费方的Filter会从当前激活的Span中获取信息并传递给下游。同样，Dubbo服务收到请求后，会从附加参数中提取上下文，创建新的Span并激活，如果它又调用了其他HTTP服务，则HTTP客户端拦截器会从当前激活的Span中获取信息并注入到HTTP头中。

实践建议与注意事项

选择合适的追踪系统：对于新项目或希望长期维护的项目，优先考虑基于OpenTelemetry标准的方案，未来兼容性更好。如果已经在使用Zipkin或Jaeger，继续使用也无妨，它们都支持OpenTelemetry协议。
部署Agent/SDK：对于Java应用，使用OpenTelemetry Java Agent是最推荐的方式，它以字节码增强的形式无侵入地实现追踪，大大降低了开发成本。如果Agent无法满足需求，再考虑手动集成SDK。
日志关联：将Trace ID和Span ID注入到你的日志中（如Logback、Log4j2），这样在查看日志时，可以通过Trace ID过滤出某个请求的所有相关日志，与追踪链路视图形成互补。
采样策略：在生产环境中，不可能对所有请求都进行追踪，因为这会带来显著的性能开销和存储压力。通常需要配置采样策略，例如：
- 固定采样率：按一定比例（如1%或0.1%）进行采样。
- 基于错误采样：只追踪发生错误的请求。
- 基于请求头采样：允许特定请求（如测试请求）强制采样。
链路数据存储与查询：追踪系统通常需要后端存储（如Elasticsearch、Cassandra）来保存大量的Span数据，并提供UI界面进行查询和分析。确保存储容量和性能满足需求。
持续监控：将分布式追踪与度量（Metrics）和日志（Logging）结合起来，构建完整的可观测性体系，形成监控-告警-追踪-排查的闭环。

总结

微服务转型带来的复杂性确实让许多团队感到困扰，但分布式追踪正是解决这种复杂性、提高系统可观测性的利器。通过在Dubbo和HTTP服务中统一上下文传播机制，无论是借助OpenTelemetry Agent的无侵入方式，还是通过编写自定义Filter/Interceptor，我们都能清晰地“看到”请求在整个系统中的流转，准确找出性能瓶颈，从而让团队在微服务化的道路上走得更稳、更快。现在，是时候给你的服务请求都贴上一个专属的“快递单号”了！

码匠老张微服务分布式追踪 Dubbo