基于蓝绿发布的Bg-Gray头部改造中Feign中获取不到头部问题

概要：在做蓝绿发布头部改造的时候，大家的策略基本都是修改@FeignClient配置类configuration里的SignatureInterceptor，在SignatureInterceptor里通过RequestContextHolder .getRequestAttributes()获取前端传过来的user_id，从而确定Bg-Gray的值，为什么不行呢
部门产品对接mop基本都是通过Feign进行mop接口调用

在做蓝绿发布头部改造的时候，大家的策略基本都是修改@FeignClient配置类configuration里的SignatureInterceptor，在SignatureInterceptor里通过RequestContextHolder .getRequestAttributes()获取前端传过来的user_id，从而确定Bg-Gray的值

但是，经过测试可以知道通过RequestContextHolder .getRequestAttributes()并不能获取到前端传输的user_id，获取到的requestAttributes为null值

具体什么原因呢？通过查阅相关资料可得知

在执行spring的过滤器chain之前会把当前的ServletRequestAttributes保存在当前线程的ThreadLocal里，所以后面要想获取ServletRequestAttributes必须在同一个线程里通过RequestContextHolder.getRequestAttributes()才能获取到

大家知道，在使用Feign进行接口调用的时候，会使用到Hystrix进行资源隔离，隔离方式包含线程池隔离和信号量Seamphore隔离，而默认是使用线程池隔离的，所以在使用Feign进行接口调用时，会在新的线程里进行Feign接口调用操作，故而无法通过RequestContextHolder.getRequestAttributes()获取前一个线程里设置的attribute，所以原来的实现方式不可行，从上面的解释中可以得知，只要是在同一个线程里就可以获取到线程里设置的attribute，恰好信号量Seamphore隔离就是在同一个线程里，于是就有了第一个解决方案。

通过信号量Seamphore隔离实现user_id的header传递
只需要在配置文件里增加信号量Seamphore隔离的配置，就可以获取到线程里配置的attribute

hystrix.command.default.execution.isolation.strategy=SEMAPHORE

具体为什么呢？

原来增加了信号量Seamphore隔离的配置后，会直接在当前线程里执行mop接口调用的后续流程

所以在信号量隔离的模式下，接收请求和执行下游依赖在同一个线程内完成，不存在线程上下文切换所带来的性能开销，但是也存在问题，在调用线程上执行下游依赖程序，并发请求受信号量限制Hystrix官方不推荐这种做法。
Thread or Semaphore
The default, and the recommended setting, is to run HystrixCommands using thread isolation (THREAD) and HystrixObservableCommands using semaphore isolation (SEMAPHORE).
Commands executed in threads have an extra layer of protection against latencies beyond what network timeouts can offer.
Generally the only time you should use semaphore isolation for HystrixCommands is when the call is so high volume (hundreds per second, per instance) that the overhead of separate threads is too high; this typically only applies to non-network calls.

那么为什么使用线程池隔离就无法在下游Feign接口调用执行中，获取到线程里配置的attribute呢，大家看下上图的蓝色部分可知。

原来使用线程池隔离，下游Feign接口调用会被调度到Hystrix线程池中新的线程里，所以通过在新的线程中通过RequestContextHolder.getRequestAttributes()获取上一个ThreadLocal里的值肯定无法得到attribute，那么怎么才能在下游的线程里获取到上游线程中配置的attribute呢？于是就有了第二个方案

Hystrix跨线程传递数据
首先我们在上游服务里保存前端传输过来的request信息，在这里，我使用拦截器进行request的处理

通过HystrixRequestContext.initializeContext()在当前线程中创建HystrixRequestContext，并把他保存在当前线程的ThreadLocal 里。

通过REQUEST.set(request)把request信息保存到上述当前线程创建的HystrixRequestContext的state里。

前面我们知道，使用线程池隔离下游的服务会在新的线程里执行

其中 1为在进入下游的线程之前获取上游刚才保存的HystrixRequestContext，命名为parentThreadState

     2为下游线程中的HystrixRequestContext，命名为existingState，为后面恢复现场做准备  3为设置下游线程的HystrixRequestContext为parentThreadState ，这样就实现了Hystrix跨线程传递数据  4为处理结束恢复现场

通过这种方式便实现了Hystrix跨线程传递数据，使得即使通过Hystrix的线程隔离也一样可以获得前端传过来的user_id

那如果我既想使用方法1里的RequestContextHolder .getRequestAttributes()获取user_id，又想使用方法2的线程池隔离，有没有什么方法呢？

这就是下一个方法

重定义WrappedCallable实现Hystrix跨线程传递数据
在上图中，如果我在1的地方获取上游线程的RequestAttributes，并把他传到wrapCallable里，是的下游可以获取到上游的RequestAttributes不是一样可以在下游获取上游前端传过来header里的user_id吗？

还真有这个实现，我们编写一个类，让其继承HystrixConcurrencyStrategy ，并重写wrapCallable 方法即可

我们把上游获取到的RequestAttributes通过1传入新定义的wrapCallable中

在2处即在下游线程里，通过RequestContextHolder.setRequestAttributes把上游传过来的RequestAttributes保存在下游的ThreadLocal，注意：在此处inheritable=true，实际上是保存到了子inheritableRequestAttributesHolder里

在3处继续执行后续下游的mop接口调用服务，如果需要通过RequestContextHolder .getRequestAttributes()获取attribute，那么肯定可以获取到，并且是上游传过来的。这里源码里RequestContextHolder获取attribute是这样的

1 先从requestAttributesHolder获取

2 获取不到的时候再从inheritableRequestAttributesHolder中获取，即从上面保存的地方获取到attribute

结束:

以前使用Feign的使用，没有过多关注Hystrix隔离机制，于是认为在Feign里可以通过RequestContextHolder .getRequestAttributes()直接获取前端传过来的request信息，但是测试中确啥也获取不到，通过查看相关文档以及源码，才慢慢定位出原因。让我想起在做zuul网关的时候，也遇到过类似的问题，前端传过来的header通过zuul传到下游服务的时候，header信息已经不是原来的header了，所以在下游无法获取前端传来的信息，具体什么原因，有时间可以给大家在讲下。