Springcloud Feign转发请求头(防止token失效)--Hystrix如何实现上下文数据传递

暮色里de白雪檐

已于 2024-03-06 22:02:36 修改

阅读量8.2k

点赞数 1

分类专栏： ThreadLocal springcloud 文章标签：多线程 springcloud hystrix 上下文传递网关 gateway zuul

于 2021-03-17 14:49:42 首次发布

本文链接：https://blog.csdn.net/lucky_love816/article/details/114929420

版权

springcloud 同时被 2 个专栏收录

15 篇文章 0 订阅

订阅专栏

ThreadLocal

4 篇文章 0 订阅

订阅专栏

Feign自动转发HTTP请求头，(防止session失效)

微服务开发中经常有这样的需求，公司自定义了通用的请求头，需要在微服务的调用链中转发，比如在请求头中加入了token，或者某个自定义的信息uniqueId，总之就是自定义的一个键值对的东东，A服务调用B服务，B服务调用C服务，这样通用的东西如何让他在一个调用链中不断地传递下去呢？以A服务为例：

方案1

最傻的办法，在程序中获取，调用B的时候再转发，怎么获取在Controller中国通过注解获取，或者通过request对象获取，这个不难，在请求B服务的时候，通过注解将值放进去即可；简代码如下：

获取：
@RequestMapping(value = "/api/test", method = RequestMethod.GET)
public String testFun(@RequestParam String name, @RequestHeader("uniqueId") String uniqueId) {
    if(uniqueId == null ){
         return "Must defined the uniqueId , it can not be null";
    }
    log.info(uniqueId, "begin testFun... ");
 return uniqueId;
}

然后A使用Feign调用B服务的时候，传过去：

@FeignClient(value = "DEMO-SERVICE")
public interface CallClient {

   /**
 * 访问DEMO-SERVICE服务的/api/test接口，通过注解将logId传递给下游服务
  */
 @RequestMapping(value = "/api/test", method = RequestMethod.GET)
    String callApiTest(@RequestParam(value = "name") String name, @RequestHeader(value = "uniqueId") String uniqueId);

}

方案弊端：毫无疑问，这方案不好，因为对代码有侵入，需要开发人员没次手动的获取和添加，因此舍弃

在介绍方案2之前需要了解隔离技术线程池（ThreadPool）和信号量（semaphore）是干什么的

首先要明白Semaphore和线程池各自是干什么？

信号量Semaphore是一个并发工具类，用来控制可同时并发的线程数，其内部维护了一组虚拟许可，通过构造器指定许可的数量，每次线程执行操作时先通过acquire方法获得许可，执行完毕再通过release方法释放许可。如果无可用许可，那么acquire方法将一直阻塞，直到其它线程释放许可。

线程池用来控制实际工作的线程数量，通过线程复用的方式来减小内存开销。线程池可同时工作的线程数量是一定的，超过该数量的线程需进入线程队列等待，直到有可用的工作线程来执行任务。

使用Seamphore，你创建了多少线程，实际就会有多少线程进行执行，只是可同时执行的线程数量会受到限制。但使用线程池，你创建的线程只是作为任务提交给线程池执行，实际工作的线程由线程池创建，并且实际工作的线程数量由线程池自己管理。

简单来说，线程池实际工作的线程是work线程，不是你自己创建的，是由线程池创建的，并由线程池自动控制实际并发的work线程数量。而Seamphore相当于一个信号灯，作用是对线程做限流，Seamphore可以对你自己创建的的线程做限流（也可以对线程池的work线程做限流），Seamphore的限流必须通过手动acquire和release来实现。

区别就是两点：

1、实际工作的线程是谁创建的？
使用线程池，实际工作线程由线程池创建；使用Seamphore，实际工作的线程由你自己创建。

2、限流是否自动实现？
线程池自动，Seamphore手动。

Hystrix中的实现

信号量模式

在该模式下，接收请求和执行下游依赖在同一个线程内完成，不存在线程上下文切换所带来的性能开销，所以大部分场景应该选择信号量模式，但是在下面这种情况下，信号量模式并非是一个好的选择。

比如一个接口中依赖了3个下游：serviceA、serviceB、serviceC，且这3个服务返回的数据互相不依赖，这种情况下如果针对A、B、C的熔断降级使用信号量模式，那么接口耗时就等于请求A、B、C服务耗时的总和，无疑这不是好的方案。

另外，为了限制对下游依赖的并发调用量，可以配置Hystrix的execution.isolation.semaphore.maxConcurrentRequests，当并发请求数达到阈值时，请求线程可以快速失败，执行降级

实现也很简单，一个简单的计数器，当请求进入熔断器时，执行tryAcquire(),计数器加1，结果大于阈值的话，就返回false，发生信号量拒绝事件，执行降级逻辑。当请求离开熔断器时，执行release()，计数器减1。

线程池模式

在该模式下，用户请求会被提交到各自的线程池中执行，把执行每个下游服务的线程分离，从而达到资源隔离的作用。当线程池来不及处理并且请求队列塞满时，新进来的请求将快速失败，可以避免依赖问题扩散。

在信号量模式提到的问题，对所依赖的多个下游服务，通过线程池的异步执行，可以有效的提高接口性能。

优势

减少所依赖服务发生故障时的影响面，比如ServiceA服务发生异常，导致请求大量超时，对应的线程池被打满，这时并不影响ServiceB、ServiceC的调用
如果接口性能有变动，可以方便的动态调整线程池的参数或者是超时时间，前提是Hystrix参数实现了动态调整。

缺点

请求在线程池中执行，肯定会带来任务调度、排队和上下文切换带来的开销。
因为涉及到跨线程，那么就存在ThreadLocal数据的传递问题，比如在主线程初始化的ThreadLocal变量，在线程池线程中无法获取

zuul/gateway中的实现

zuul/gateway默认是使用信号量隔离，并且信号量的大小是100，请求的并发线程超过100就会报错
注意点：因为默认都是信号隔离级别，所以网管里面的token等信息可以往下游服务传递

可以调大该信号量的最大值来提高性能，配置如下：

zuul:
  semaphore:
    max-semaphores: 5000

也可以改为使用线程隔离，调大hystrix线程池线程大小，该线程池默认10个线程，配置如下：

zuul:
  ribbonIsolationStrategy: THREAD

hystrix:
  threadpool:
    default:
      coreSize: 100
      maximumSize: 400
      allowMaximumSizeToDivergeFromCoreSize: true
      maxQueueSize: -1

maximumSize：最大线程数量
allowMaximumSizeToDivergeFromCoreSize：是否让maximumSize生效，false的话则只有coreSize会生效
maxQueueSize：线程池的队列大小，-1代表使用SynchronousQueue队列

方案2

服务通过请求拦截器，在请求从A发送到B之后，在拦截器内将自己需要的东东加到请求头：

 import com.intellif.log.LoggerUtilI;
import feign.RequestInterceptor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;

import javax.servlet.http.HttpServletRequest;
import java.util.Enumeration;

/**
 * 自定义的请求头处理类，处理服务发送时的请求头；
 * 将服务接收到的请求头中的uniqueId和token字段取出来，并设置到新的请求头里面去转发给下游服务
 * 比如A服务收到一个请求，请求头里面包含uniqueId和token字段，A处理时会使用Feign客户端调用B服务
 * 那么uniqueId和token这两个字段就会添加到请求头中一并发给B服务；
 *
 * @author mozping
 * @version 1.0
 * @date 2018/6/27 14:13
 * @see FeignHeadConfiguration
 * @since JDK1.8
 */
@Configuration
public class FeignHeadConfiguration {
    private final LoggerUtilI logger = LoggerUtilI.getLogger(this.getClass().getName());

    @Bean
    public RequestInterceptor requestInterceptor() {
        return requestTemplate -> {
            ServletRequestAttributes attrs = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
            if (attrs != null) {
                HttpServletRequest request = attrs.getRequest();
                Enumeration<String> headerNames = request.getHeaderNames();
                if (headerNames != null) {
                    while (headerNames.hasMoreElements()) {
                        String name = headerNames.nextElement();
                        String value = request.getHeader(name);
                        /**
                         * 遍历请求头里面的属性字段，将logId和token添加到新的请求头中转发到下游服务
                         * */
                        if ("uniqueId".equalsIgnoreCase(name) || "token".equalsIgnoreCase(name)) {
                            logger.debug("添加自定义请求头key:" + name + ",value:" + value);
                            requestTemplate.header(name, value);
                        } else {
                            logger.debug("FeignHeadConfiguration", "非自定义请求头key:" + name + ",value:" + value + "不需要添加!");
                        }
                    }
                } else {
                    logger.warn("FeignHeadConfiguration", "获取请求头失败！");
                }
            }
        };
    }

}

网上很多关于这种方法的博文或者资料，大同小异，但是有一个问题，在开启熔断器之后，这里的attrs就是null，因为熔断器默认的隔离策略是thread，也就是线程隔离，实际上接收到的对象和这个在发送给B不是一个线程，怎么办？有一个办法，修改隔离策略hystrix.command.default.execution.isolation.strategy=SEMAPHORE，改为信号量的隔离模式，但是不推荐，因为thread是默认的，而且要命的是信号量模式，熔断器不生效，比如设置了熔断时间hystrix.command.default.execution.isolation.semaphore.timeoutInMilliseconds=5000，五秒，如果B服务里面sleep了10秒，非得等到B执行完毕再返回，因此这个方案也不可取；但是有什么办法可以在默认的Thread模式下让拦截器拿到上游服务的请求头？自定义策略：代码如下：

import com.netflix.hystrix.HystrixThreadPoolKey;
import com.netflix.hystrix.HystrixThreadPoolProperties;
import com.netflix.hystrix.strategy.HystrixPlugins;
import com.netflix.hystrix.strategy.concurrency.HystrixConcurrencyStrategy;
import com.netflix.hystrix.strategy.concurrency.HystrixRequestVariable;
import com.netflix.hystrix.strategy.concurrency.HystrixRequestVariableLifecycle;
import com.netflix.hystrix.strategy.eventnotifier.HystrixEventNotifier;
import com.netflix.hystrix.strategy.executionhook.HystrixCommandExecutionHook;
import com.netflix.hystrix.strategy.metrics.HystrixMetricsPublisher;
import com.netflix.hystrix.strategy.properties.HystrixPropertiesStrategy;
import com.netflix.hystrix.strategy.properties.HystrixProperty;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.context.request.RequestAttributes;
import org.springframework.web.context.request.RequestContextHolder;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.Callable;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * 自定义Feign的隔离策略;
 * 在转发Feign的请求头的时候，如果开启了Hystrix，Hystrix的默认隔离策略是Thread(线程隔离策略)，因此转发拦截器内是无法获取到请求的请求头信息的，可以修改默认隔离策略为信号量模式：hystrix.command.default.execution.isolation.strategy=SEMAPHORE，这样的话转发线程和请求线程实际上是一个线程，这并不是最好的解决方法，信号量模式也不是官方最为推荐的隔离策略；另一个解决方法就是自定义Hystrix的隔离策略，思路是将现有的并发策略作为新并发策略的成员变量,在新并发策略中，返回现有并发策略的线程池、Queue；将策略加到Spring容器即可；
 *
 * @author mozping
 * @version 1.0
 * @date 2018/7/5 9:08
 * @see FeignHystrixConcurrencyStrategyIntellif
 * @since JDK1.8
 */
@Component
public class FeignHystrixConcurrencyStrategyIntellif extends HystrixConcurrencyStrategy {

    private static final Logger log = LoggerFactory.getLogger(FeignHystrixConcurrencyStrategyIntellif.class);
    private HystrixConcurrencyStrategy delegate;

    public FeignHystrixConcurrencyStrategyIntellif() {
        try {
            this.delegate = HystrixPlugins.getInstance().getConcurrencyStrategy();
            if (this.delegate instanceof FeignHystrixConcurrencyStrategyIntellif) {
                // Welcome to singleton hell...
                return;
            }
            HystrixCommandExecutionHook commandExecutionHook =
                    HystrixPlugins.getInstance().getCommandExecutionHook();
            HystrixEventNotifier eventNotifier = HystrixPlugins.getInstance().getEventNotifier();
            HystrixMetricsPublisher metricsPublisher = HystrixPlugins.getInstance().getMetricsPublisher();
            HystrixPropertiesStrategy propertiesStrategy =
                    HystrixPlugins.getInstance().getPropertiesStrategy();
            this.logCurrentStateOfHystrixPlugins(eventNotifier, metricsPublisher, propertiesStrategy);
            HystrixPlugins.reset();
            HystrixPlugins.getInstance().registerConcurrencyStrategy(this);
            HystrixPlugins.getInstance().registerCommandExecutionHook(commandExecutionHook);
            HystrixPlugins.getInstance().registerEventNotifier(eventNotifier);
            HystrixPlugins.getInstance().registerMetricsPublisher(metricsPublisher);
            HystrixPlugins.getInstance().registerPropertiesStrategy(propertiesStrategy);
        } catch (Exception e) {
            log.error("Failed to register Sleuth Hystrix Concurrency Strategy", e);
        }
    }

    private void logCurrentStateOfHystrixPlugins(HystrixEventNotifier eventNotifier,
                                                 HystrixMetricsPublisher metricsPublisher, HystrixPropertiesStrategy propertiesStrategy) {
        if (log.isDebugEnabled()) {
            log.debug("Current Hystrix plugins configuration is [" + "concurrencyStrategy ["
                    + this.delegate + "]," + "eventNotifier [" + eventNotifier + "]," + "metricPublisher ["
                    + metricsPublisher + "]," + "propertiesStrategy [" + propertiesStrategy + "]," + "]");
            log.debug("Registering Sleuth Hystrix Concurrency Strategy.");
        }
    }

    @Override
    public <T> Callable<T> wrapCallable(Callable<T> callable) {
        RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
        return new WrappedCallable<>(callable, requestAttributes);
    }

    @Override
    public ThreadPoolExecutor getThreadPool(HystrixThreadPoolKey threadPoolKey,
                                            HystrixProperty<Integer> corePoolSize, HystrixProperty<Integer> maximumPoolSize,
                                            HystrixProperty<Integer> keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
        return this.delegate.getThreadPool(threadPoolKey, corePoolSize, maximumPoolSize, keepAliveTime,
                unit, workQueue);
    }

    @Override
    public ThreadPoolExecutor getThreadPool(HystrixThreadPoolKey threadPoolKey,
                                            HystrixThreadPoolProperties threadPoolProperties) {
        return this.delegate.getThreadPool(threadPoolKey, threadPoolProperties);
    }

    @Override
    public BlockingQueue<Runnable> getBlockingQueue(int maxQueueSize) {
        return this.delegate.getBlockingQueue(maxQueueSize);
    }

    @Override
    public <T> HystrixRequestVariable<T> getRequestVariable(HystrixRequestVariableLifecycle<T> rv) {
        return this.delegate.getRequestVariable(rv);
    }

    static class WrappedCallable<T> implements Callable<T> {
        private final Callable<T> target;
        private final RequestAttributes requestAttributes;

        public WrappedCallable(Callable<T> target, RequestAttributes requestAttributes) {
            this.target = target;
            this.requestAttributes = requestAttributes;
        }

        @Override
        public T call() throws Exception {
            try {
                RequestContextHolder.setRequestAttributes(requestAttributes);
                return target.call();
            } finally {
                RequestContextHolder.resetRequestAttributes();
            }
        }
        
也可以放在ContextHandler
 
         @Override
        public T call() throws Exception {
            try {
                ContextHandler.setAll(requestAttributes);
                return target.call();
            } finally {
                ContextHandler.remove();
            }
        }
    }
}

然后使用默认的熔断器隔离策略，也可以在拦截器内获取到上游服务的请求头信息了；

坑点

1、这个地方既然说到了Hystrix，我就提几个注意点，这个hystrix要不被feign整合要不被zuul/gateway整合，微服务组件中场景是这两种整合方式，首先feign整合的hystrix默认隔离策略是线程池；zuul/gateway整合的hystrix默认隔离策略是信号量
2、启动网关如果需要启动hystrix除了在启动类上面加个启动配置之外，我们经常配置超时时间，记住如果是线程池隔离级别才会有熔断器的超时概念，所以说如果是信号量肯定是没有超时的，那么如果启动这个超时时间设置，你可能会这样写hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=5000
hystrix.command.default.execution.isolation.semaphore.timeoutInMilliseconds或者，这样写肯定不会生效的，不要以为你有个thread或者semaphore，需要设置你的隔离模式是什么，比如hystrix.command.default.execution.isolation.strategy=SEMAPHORE/THREAD，这样才可以，否则网关还是走默认的隔离级别是信号量模式，不过如果是信号量一般都会设置并发数也就是信号量的最大值，不会去设置
hystrix.command.default.execution.isolation.semaphore.timeoutInMilliseconds，而是Hystrix的execution.isolation.semaphore.maxConcurrentRequests

暮色里de白雪檐

关注

1
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
Springcloud Feign转发请求头(防止token失效)--Hystrix如何实现上下文数据传递

Feign自动转发HTTP请求头，(防止session失效)微服务开发中经常有这样的需求，公司自定义了通用的请求头，需要在微服务的调用链中转发，比如在请求头中加入了token，或者某个自定义的信息uniqueId，总之就是自定义的一个键值对的东东，A服务调用B服务，B服务调用C服务，这样通用的东西如何让他在一个调用链中不断地传递下去呢？以A服务为例：方案1最傻的办法，在程序中获取，调用B的时候再转发，怎么获取在Controller中国通过注解获取，或者通过request对象获取，这个不难，在请求B服
复制链接

扫一扫