使用brave对dubbo做链路跟踪对复杂系统定位问题有重要意义。某项目发现，在rest协议下，brave做链路跟踪会失败。
经试验对比，此问题有普遍性。本篇博客从源码层面探索失败原因，并给出一个初步的解决方案。
也欢迎访问笔者github上此问题示例工程test-dubbo-brave

问题定位

首先明确dubbo和brave集成的方式为通过dubbo的Filter，其中brave的carrier为dubbo的Attachments，可见brave.dubbo.rpc.TracingFilter的Invoke方法，如下代码片段：

if (kind.equals(Kind.CLIENT)) {
    span = tracer.nextSpan();
    injector.inject(span.context(), invocation.getAttachments());
} else {
    TraceContextOrSamplingFlags extracted = extractor.extract(invocation.getAttachments());
    span = extracted.context() != null
            ? tracer.joinSpan(extracted.context())
            : tracer.nextSpan(extracted);
}

可知：

1. 若当前dubbo为消费端，则生成下一个span，放入Attachments
2. 若当前dubbo为服务端，则从Attachments中提取span

另外注意，其中使用的Attachments是Invocation中的。
参考笔者另一篇博客
dubbo-protocol-rest下attachments如何传递，可知protocol-rest下，dubbo使用的Attachments是RpcContext中的。
这样一来就矛盾了：

1. brave使用Invocation中的Attachments，放入或取出Span
2. protocol-rest使用RpcContext中的Attachments，放入或取出HTTP header

这两者一连接，示意图如下：

                                  brave                       protocol-rest
组件                           TracingFilter                 RpcContextFilter
attachments载体             span      Invocation       RpcContext      HTTP headers

server端attachments赋值方向        <-                              <-
client端attachments赋值方向        ->                              ->

造成的问题为：

1. 若当前dubbo为消费端，则将span放入Invocation中的Attachments，将RpcContext中的Attachments放入HTTP header。新span无法传入下一个服务，上下游服务span相同。
2. 若当前dubbo为服务端，从HTTP header取出Attachments放入RpcContext，从Invocation的Attachments提取span。服务端提取不到span，总认为是自己是交易入口，起一个新trace。

修正

这里给出两个方法，分别为是否改源码

修改源码

较简单做法为修改源码，不是使用Invocation中的Attachments作为carrier，而是使用RpcContext中的。略。

不修改源码

另一种做法为再增加一个Filter，完成Invocation中的Attachments和RpcContext中的双向赋值。可见笔者github上此问题示例工程test-dubbo-brave，增加后span和HTTP header之间的赋值示意图如下：

                                  brave                       protocol-rest
组件                           TracingFilter     *新增*      RpcContextFilter
attachments载体             span      Invocation       RpcContext      HTTP headers

server端attachments赋值方向        <-              *<-*            <-
client端attachments赋值方向        ->              *->*            ->

其中两个关键Filter为PropagationFromRpcContextToInvocationFilter及PropagationFromRpcInvocationToContextFilter，类图为：

两个关键Filter类图

context2inv=io.dracula.test.dubbo.brave.PropagationFromRpcContextToInvocationFilter
inv2context=io.dracula.test.dubbo.brave.PropagationFromRpcInvocationToContextFilter

使用时需在xml文件中指定：

<dubbo:provider filter="context2inv,tracing"/>
<dubbo:consumer filter="tracing,inv2context"/>

具体实现方面，在两Filter中尽可能使用brave提供的api，如Extractor和Injector，而不是直接从Attachments中取值再向另一个Attachments赋值。这主要是考虑到了brave的Propagation和Carrier抽象，同时兼顾灵活性。
brave的dubbo Filter，brave.dubbo.rpc.TracingFilter，代码片段如下：

public final class TracingFilter implements Filter {

  TraceContext.Extractor<Map<String, String>> extractor;
  TraceContext.Injector<Map<String, String>> injector;

  //略
}

可见extractor和injector属性为包访问级别，于是需要自己在同包下写一个类，将两属性暴露出来，可见brave.dubbo.rpc.PackageAccessBridge，其子类io.dracula.test.dubbo.brave.PropagationKeysAssignFilter中封装了可复用的逻辑，从一个Attachments用Exractor提取出span，再用Injector将此span放入另一个Attachments，代码片段如下：

//Map<String, String> ori, des分别为两个Attachments
TraceContext extractedTraceContext = extractor.extract(ori).context();
injector.inject(extractedTraceContext, des);