在上一篇文章中说到在springMVC、dubbo项目中成功集成了zipkin，并且使用也是正常，到zipkin控制台界面也可以看到所有的请求都链接起来了，这个是令人开心的。
但是在这个过程中遇到了很多问题，下面总结一下：

问题1
如何修改springMVC请求中的请求名称？
方法：brave默认用的是请求名称是请求方式，即get，post，put等；由源代码可以知道

public class DefaultSpanNameProvider implements SpanNameProvider {
    public DefaultSpanNameProvider() {
    }

    public String spanName(HttpRequest request) {
        return request.getHttpMethod();
    }
}//从这个类中可以看到默认把请求方式作为这次请求的name


//自定义的requestAdapter类
package com.louie.trace;

import static com.github.kristofa.brave.IdConversion.convertToLong;

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

import com.github.kristofa.brave.KeyValueAnnotation;
import com.github.kristofa.brave.ServerRequestAdapter;
import com.github.kristofa.brave.SpanId;
import com.github.kristofa.brave.TraceData;
import com.github.kristofa.brave.http.BraveHttpHeaders;
import com.github.kristofa.brave.http.HttpServerRequest;
import com.github.kristofa.brave.http.SpanNameProvider;

public class CusHttpServerRequestAdapter  implements ServerRequestAdapter {
    private final HttpServerRequest request;
    private final SpanNameProvider spanNameProvider;
    private final String service;
    private final String data;

    public CusHttpServerRequestAdapter(HttpServerRequest request,String service,String data, SpanNameProvider spanNameProvider) {
        this.request = request;
        this.spanNameProvider = spanNameProvider;
        this.service = service;
        this.data = data;
    }

    public TraceData getTraceData() {
        String sampled = request.getHttpHeaderValue(BraveHttpHeaders.Sampled.getName());
        String parentSpanId = request.getHttpHeaderValue(BraveHttpHeaders.ParentSpanId.getName());
        String traceId = request.getHttpHeaderValue(BraveHttpHeaders.TraceId.getName());
        String spanId = request.getHttpHeaderValue(BraveHttpHeaders.SpanId.getName());

        // Official sampled value is 1, though some old instrumentation send true
        Boolean parsedSampled = sampled != null
            ? sampled.equals("1") || sampled.equalsIgnoreCase("true")
            : null;

        if (traceId != null && spanId != null) {
            return TraceData.create(getSpanId(traceId, spanId, parentSpanId, parsedSampled));
        } else if (parsedSampled == null) {
            return TraceData.EMPTY;
        } else if (parsedSampled.booleanValue()) {
            // Invalid: The caller requests the trace to be sampled, but didn't pass IDs
            return TraceData.EMPTY;
        } else {
            return TraceData.NOT_SAMPLED;
        }
    }

    public String getSpanName() {
        return spanNameProvider.spanName(request);//这里就是将默认的请求方式放进去，当然你可以手动修改成你需要的名字，例如请求的uri
    }

    public Collection<KeyValueAnnotation> requestAnnotations() {
        KeyValueAnnotation sera = KeyValueAnnotation.create(
                "service", service);
        KeyValueAnnotation dataa = KeyValueAnnotation.create(
                "data", data);
        List<KeyValueAnnotation> kas = new ArrayList<KeyValueAnnotation>();
        kas.add(sera);
        kas.add(dataa);
        return kas;
        //return Collections..singleton(sera);
    }

    static SpanId getSpanId(String traceId, String spanId, String parentSpanId, Boolean sampled) {
        return SpanId.builder()
            .traceIdHigh(traceId.length() == 32 ? convertToLong(traceId, 0) : 0)
            .traceId(convertToLong(traceId))
            .spanId(convertToLong(spanId))
            .sampled(sampled)
            .parentId(parentSpanId == null ? null : convertToLong(parentSpanId)).build();
   }
}

问题2
集成成功后，代码等没有报错，但是请求并没有串联起来，如下图

image.png
方法：这个是我遇到的问题，可能其他人不会遇到，毕竟环境不一样，先说说我的解决思路吧，刚开始一脸懵逼状态，明明是按照demo搞的，为什么人家的正常，自己的不正常；

首先：我去将别人的demo下载下来，还好demo不需要搞数据库等等东西，然后我配置了下zk等，跑起来了；测试了下，如愿以偿，跟我想要的一样，那么问题来了，为什么我的没有串起来，他的请求反倒可以呢；

第二步：对比两个项目中这部分配置有什么不一样的，经过一遍又一遍的对比，我发现了demo中直接通过spi配置了filter，dubbo的xml配置文件中并没有重新再去配置filter，但是我的项目中我是有在xml中配置了filter，然后就是这里的区别导致了请求没有串联起来，那么我去掉这个配置试试看，结果发现一切正常，由此可知问题是出在这里；

第三步：既然知道了问题出在这里，那么就得去找到为什么这样配置会错误，然后去了解一下dubbo的spi机制已经过滤器的顺序，粗略了解了一下，加上@Activate注解的类，dubbo会将该类作为默认的过滤器来加载，不用再继续到xml文件中配置，假如在xml文件中配置的话，这个过滤器的加载顺序将按照配置的加载顺序来执行，具体修改执行顺序的话，请自行百度。这里dubbo的spi机制非常灵活。

第四步：那么为什么作为默认加载的话没有问题，然后将过滤器放入xml文件中的话就出现了这种问题，但是我在提供者这边也配置了xml，但是提供者这边却没有任何问题，这个就很奇怪了，打断点调试查看源代码，可以发现最终取的span是从ThreadLocal中拿出来，加与不加xml配置的区别在于从ThreadLocal做这个类型对象中能否取到值，结果是加了的取出来的值为null，不加的时候取出来是上一次请求的span，由此可知原因出在这里，再仔细查询发现用的ThreadLocal对象并不是同一个，同时又确认问题不是出在dubbo框架，大胆猜测，可能是filter的顺序导致的问题；

第五步：重新配置filter的顺序，将自定义的traceFilterc定义到第一个后，启动调试，发现正常，然后将traceFilterc定义到最后一个后发现出现之前的问题，好了找到原因了。一个个测试，可以发现是自己其他定义的filter影响的，因为在我们项目中有用到一个熔断器的fiter，当将traceFilterc配置在该熔断器后，就出现问题，在之前就没有任何问题。

第六步：同事跟我说明了这个熔断器的原理，里面有一个线程池，来进行请求，导致client进来的请求跟rpc调用的请求不是同一个，然后导致ThreadLocal对象也不是同一个，由此不能串联起来。那么知道原因了在测试一把，打印一下各自的线程名称，发现永远都不会一样。自此该问题结束。

问题3
如何过滤请求记录中的相关参数，因为我们项目中涉及到一些很大的字段，如果将其全部发到zipkin的话感觉不太好，并且这些打字段对查找问题意义不大，所有引出这个问题。

方法：供大家自己实现，我目前也想不到什么好办法，哈哈哈哈，如果有好方法的话希望大家能交流一下，谢谢

如果帮到您了，请点个喜欢，谢谢！;