業(yè)務(wù)場(chǎng)景

通常微服務(wù)對(duì)于用戶認(rèn)證信息解析有兩種方案

• 在 gateway 就解析用戶的 token 然后路由的時(shí)候把 userId 等相關(guān)信息添加到 header 中傳遞下去。
• 在 gateway 直接把 token 傳遞下去，每個(gè)子微服務(wù)自己在過(guò)濾器解析 token

現(xiàn)在有一個(gè)從 A 服務(wù)調(diào)用 B 服務(wù)接口的內(nèi)部調(diào)用業(yè)務(wù)場(chǎng)景，無(wú)論是哪種方案我們都需要把 header 從 A 服務(wù)傳遞到 B 服務(wù)。

RequestInterceptor

OpenFeign 給我們提供了一個(gè)請(qǐng)求攔截器 RequestInterceptor ，我們可以實(shí)現(xiàn)這個(gè)接口重寫(xiě) apply 方法將當(dāng)前請(qǐng)求的 header 添加到請(qǐng)求中去，傳遞給下游服務(wù)，RequestContextHolder 可以獲得當(dāng)前線程綁定的 Request 對(duì)象

/** Feign 調(diào)用的時(shí)候傳token到下游 */
public class FeignRequestInterceptor implements RequestInterceptor {
  @Override
  public void apply(RequestTemplate template) {
    // 從header獲取X-token
    RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
    ServletRequestAttributes attr = (ServletRequestAttributes) requestAttributes;
    HttpServletRequest request = attr.getRequest();
    String token = request.getHeader("x-auth-token");//網(wǎng)關(guān)傳過(guò)來(lái)的 token
    if (StringUtils.hasText(token)) {
      template.header("X-AUTH-TOKEN", token);
    }
  }
}

然后在 @FeignClient 中使用

@FeignClient(
    ...
    configuration = {FeignClientDecoderConfiguration.class, FeignRequestInterceptor.class})
public interface AuthCenterClient {

多線程環(huán)境下傳遞 header（一）

上面是單線程的情況，假如我們?cè)诋?dāng)前線程中又開(kāi)啟了子線程去進(jìn)行 Feign 調(diào)用，那么是無(wú)法從 RequestContextHolder 獲取到 header 的，原因很簡(jiǎn)單，看下 RequestContextHolder 源碼就知道了，它里面是一個(gè) ThreadLocal ，線程都變了，那肯定獲取不到主線程請(qǐng)求里面的 requestAttribute 了。

原因已經(jīng)清楚了，現(xiàn)在想辦法去解決它。觀察 RequestContextHolder.getRequestAttributes() 方法源碼

public static RequestAttributes getRequestAttributes() {
   RequestAttributes attributes = requestAttributesHolder.get();
   if (attributes == null) {
      attributes = inheritableRequestAttributesHolder.get();
   }
   return attributes;
}

注意到如果當(dāng)前線程拿不到 RequestAttributes ，他會(huì)從 inheritableRequestAttributesHolder 里面拿，再仔細(xì)觀察發(fā)現(xiàn)源碼設(shè)置 RequestAttributes 到 ThreadLocal 的時(shí)候有這樣一個(gè)重載方法

/**
 * 給當(dāng)前線程綁定屬性
 * @param inheritable 是否要將屬性暴露給子線程
 */
public static void setRequestAttributes(@Nullable RequestAttributes attributes, boolean inheritable) {
   //......
}

這特喵的完美符合我們的需求，現(xiàn)在我們的問(wèn)題就是子線程沒(méi)有拿到主線程的 RequestContextHolder 里面的屬性。在業(yè)務(wù)代碼中：

RequestContextHolder.setRequestAttributes(RequestContextHolder.getRequestAttributes(), true);
log.info("主線程任務(wù)....");
new Thread(() -> {
    log.info("子線程任務(wù)開(kāi)始...");
    UserResponse response = client.getById(3L);
}).start();

開(kāi)發(fā)環(huán)境測(cè)試之后發(fā)現(xiàn)子線程已經(jīng)能夠從 RequestContextHolder 拿到主線程的請(qǐng)求對(duì)象了。

分析 inheritableRequestAttributesHolder 原理

觀察源碼我們可以看到這個(gè)屬性的類型是 NamedInheritableThreadLocal 它繼承了 InheritableThreadLocal 。還記得去年我第一次遇到開(kāi)啟多線程跨服務(wù)請(qǐng)求的時(shí)候始終不能理解為什么這玩意能把當(dāng)前線程綁定的對(duì)象暴露給子線程。前幾天 debug 了一下 InheritableThreadLocal.set() 方法恍然大悟。

其實(shí)這個(gè)東西對(duì) Thread、ThreadLocal 有了解就會(huì)知道，在 Thread 的構(gòu)造方法里面有這樣一段代碼

//...
Thread parent = currentThread(); //創(chuàng)建子線程的時(shí)候先拿父線程
//...
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
 this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals;
//...

其實(shí)我們創(chuàng)建子線程的時(shí)候會(huì)先拿父線程，判斷父線程里面的 inheritableThreadLocals 是不是有值，由于上面 RequestContextHolder.setRequestAttributes(xxx,true) 設(shè)置了 true ，所以父線程的 inheritableThreadLocals 是有 requestAttributes 的。這樣創(chuàng)建子線程后，子線程的 inheritableThreadLocals 也有值了。所以后面我們?cè)谧泳€程中獲取 requestAttributes 是能獲取到的。

這樣真的解決問(wèn)題了嗎？從非 web 層面來(lái)看，的確是解決了這個(gè)問(wèn)題，但是在我們的 web 場(chǎng)景中并非如此。經(jīng)過(guò)反復(fù)的測(cè)試，我們會(huì)發(fā)現(xiàn)子線程并不是每次都能獲取到 header ，進(jìn)而我們發(fā)現(xiàn)了這與父子線程的結(jié)束順序有關(guān)，如果父線程早與子線程結(jié)束，那么子線程就獲取不到 header ，反之子線程能獲取到 header。

分析 inheritableRequestAttributesHolder 失效原因

其實(shí)標(biāo)題并不嚴(yán)謹(jǐn)，因?yàn)樽泳€程獲取不到請(qǐng)求的 header 并不是因?yàn)?inheritableRequestAttributesHolder 失效。這個(gè)原因當(dāng)初我也很奇怪，于是我從網(wǎng)上看到一篇文章，它是這么寫(xiě)的。

在源碼中ThreadLocal對(duì)象保存的是RequestAttributes attributes；這個(gè)是保存的對(duì)象的引用。一旦父線程銷毀了，那RequestAttributes也會(huì)被銷毀，那RequestAttributes的引用地址的值就為null**；**雖然子線程也有RequestAttributes的引用，但是引用的值為null了。

真的是這樣嗎？？我怎么看怎么感覺(jué)不對(duì)......于是我自己驗(yàn)證了下

@GetMapping("/test")
public void test(HttpServletRequest request) {
    RequestAttributes attr = RequestContextHolder.getRequestAttributes();
    log.info("父線程:RequestAttributes:{}", attr);
    RequestContextHolder.setRequestAttributes(attr, true);
    log.info("父線程:SpringMVC:request:{}",request);
    log.info("父線程:x-auth-token:{}",request.getHeader("x-auth-token"));
    ServletRequestAttributes attr1 = (ServletRequestAttributes) attr;
    HttpServletRequest request1 = attr1.getRequest();
    log.info("父線程:request:{}",request1);
    new Thread(
            () -> {
                try {
                    TimeUnit.SECONDS.sleep(3);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                RequestAttributes childAttr = RequestContextHolder.getRequestAttributes();
                log.info("子線程:RequestAttributes:{}",childAttr);
                ServletRequestAttributes childServletRequestAttr = (ServletRequestAttributes) childAttr;
                HttpServletRequest childRequest = childServletRequestAttr.getRequest();
                log.info("子線程:childRequest:{}",childRequest);
                String childToken = childRequest.getHeader("x-auth-token");
                log.info("子線程:x-auth-token:{}",childToken);
            }).start();
}

觀察日志

父線程:RequestAttributes:org.apache.catalina.connector.RequestFacade@ea25271
父線程:SpringMVC:request:org.apache.catalina.connector.RequestFacade@ea25271
父線程:x-auth-token:null
父線程:request:org.apache.catalina.connector.RequestFacade@ea25271

子線程:RequestAttributes:org.apache.catalina.connector.RequestFacade@ea25271
子線程:childRequest:org.apache.catalina.connector.RequestFacade@ea25271
子線程:x-auth-token:{}:null

很明顯子線程拿到了 RequestAttitutes 對(duì)象，而且和父線程是同一個(gè)，這就推翻了上面的說(shuō)法，并不是引用變?yōu)?null 了導(dǎo)致的。那么到底是什么原因?qū)е赂妇€程結(jié)束后，子線程就拿不到 request 對(duì)象里面的 header 屬性了呢？

我們可以猜測(cè)一下，既然父線程和子線程拿到的 request 對(duì)象是同一個(gè)，并且在子線程代碼中 request 對(duì)象還不是 null，但是屬性沒(méi)了，那應(yīng)該是請(qǐng)求結(jié)束之后某個(gè)地方對(duì) request 對(duì)象進(jìn)行了屬性移除。我們跟隨 RequestFacade 類去尋找真理，尋找尋找再尋找......終于我發(fā)現(xiàn)了真相在 org.apache.coyote.Request 類

在 Tomcat 內(nèi)部，請(qǐng)求結(jié)束后會(huì)對(duì) request 對(duì)象重置，把 header 等屬性移除，是因?yàn)檫@樣如果父線程提前結(jié)束，我們?cè)谧泳€程中才無(wú)法獲取 request 對(duì)象的 header 。

或許你可以再思考一下 Tomcat 為什么要這么做？

多線程環(huán)境下傳遞 header（二）

既然 RequestContextHolder.setRequestAttributes(attr, true); 也不能完全實(shí)現(xiàn)子線程能夠獲取父線程的 header ，那么我們?nèi)绾谓鉀Q呢？

控制主線程在子線程結(jié)束后再結(jié)束

這是最簡(jiǎn)單的方法，我把父線程掛起來(lái)，等子線程任務(wù)都執(zhí)行完了，再結(jié)束父線程，這樣就不會(huì)出現(xiàn)子線程獲取不到 header 的情況了。最簡(jiǎn)單的，我們可以用 ExecutorCompletionService 實(shí)現(xiàn)。

重新保存 request 的 header

上面我們已經(jīng)知道了獲取不到 header 是因?yàn)?request 對(duì)象的 header 屬性被移除了，那么我們只需要自己定義一個(gè)數(shù)據(jù)結(jié)構(gòu) ThreadLocal 重新在內(nèi)存中保存一份 header 屬性即可。我們可以定義一個(gè)請(qǐng)求攔截器，在攔截器中獲取 headers 放到自定義的結(jié)構(gòu)中。

定義結(jié)構(gòu)

public class RequestHeaderHolder {
    private static final ThreadLocal<Map<String,String>> REQUEST_HEADER_HOLDER = new InheritableThreadLocal<>(){
        @Override
        protected Map<String, String> initialValue() {
            return new HashMap<>();
        }
    };
    //...省略部分方法
}

攔截器

public class RequestHeaderInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        Enumeration<String> headerNames = request.getHeaderNames();

        while (headerNames.hasMoreElements()){
            String s = headerNames.nextElement();
            RequestHeaderHolder.set(s,request.getHeader(s));
        }
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        RequestHeaderHolder.remove(); //注意一定要remove
    }
}

然后將這個(gè)攔截器添加到 InterceptorRegistry 即可。這樣我們?cè)谧泳€程中就可以通過(guò) RequestHeaderHolder 獲取請(qǐng)求到 header 。

結(jié)語(yǔ)

本篇文章簡(jiǎn)單介紹 OpenFeign 調(diào)用傳遞 header ，以及多線程環(huán)境下可能會(huì)出現(xiàn)的問(wèn)題。其中涉及到 ThreadLocal 的相關(guān)知識(shí)，如果有同學(xué)對(duì) ThreadLocal、InheritableThreadLocal 不清楚的可以留言，后面出一篇 ThreadLocal 的文章。

到此這篇關(guān)于SpringCloud OpenFeign 服務(wù)調(diào)用傳遞 token的場(chǎng)景分析的文章就介紹到這了,更多相關(guān)SpringCloud OpenFeign傳遞 token內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論