实用技巧:Hystrix传播ThreadLocal对象(两种方案)

简介: 原文:http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/采用 CC BY 3.0 CN 许可协议。

原文:http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/
采用 CC BY 3.0 CN 许可协议。可自由转载、引用,但需署名作者且注明文章原文地址。

目前,Spring Cloud已在南京公司推广开来,不仅如此,深圳那边近期也要基于Spring Cloud新开微服务了。

于是,领导要求我出一套基于Spring Cloud的快速开发脚手架(近期开源)。在编写脚手架的过程中,也顺带总结一下以前在项目中遇到的问题:

使用Hystrix时,如何传播ThreadLocal对象?

我们知道,Hystrix有隔离策略:THREAD以及SEMAPHORE。

如果你不知道Hystrix的隔离策略,可以阅读我的书籍《Spring Cloud与Docker微服务架构实战》,或者参考文档:https://github.com/Netflix/Hystrix/wiki/Configuration#executionisolationstrategy

引子

当隔离策略为 THREAD 时,是没办法拿到 ThreadLocal 中的值的。

举个例子,使用Feign调用某个远程API,这个远程API需要传递一个Header,这个Header是动态的,跟你的HttpRequest相关,我们选择编写一个拦截器来实现Header的传递(当然也可以在Feign Client接口的方法上加RequestHeader )。

示例代码:

public class KeycloakRequestInterceptor implements RequestInterceptor {

    private static final String AUTHORIZATION_HEADER = "Authorization";

    @Override
    public void apply(RequestTemplate template) {
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
        Principal principal = attributes.getRequest().getUserPrincipal();

        if (principal != null && principal instanceof KeycloakPrincipal) {
            KeycloakSecurityContext keycloakSecurityContext = ((KeycloakPrincipal) principal)
                    .getKeycloakSecurityContext();

            if (keycloakSecurityContext instanceof RefreshableKeycloakSecurityContext) {
                RefreshableKeycloakSecurityContext.class.cast(keycloakSecurityContext)
                        .refreshExpiredToken(true);
                template.header(AUTHORIZATION_HEADER, "Bearer " + keycloakSecurityContext.getTokenString());
            }

        }
        // 否则啥都不干
    }
}

你可能不知道Keycloak是什么,不过没有关系,相信这段代码并不难阅读,该拦截器做了几件事:

  • 使用 RequestContextHolder.getRequestAttributes() 静态方法获得Request。
  • 从Request获得当前用户的身份,然后使用Keycloak的API拿到Token,并扔到Header里。
  • 这样,Feign使用这个拦截器时,就会用你这个Header去请求了。

注:Keycloak是一个非常容易上手,并且功能强大的单点认证平台。

现实很骨感

以上代码可完美运行——但仅限于Feign不开启Hystrix支持时。

注:Spring Cloud Dalston以及更高版可使用 feign.hystrix.enabled=true 为Feign开启Hystrix支持。

当Feign开启Hystrix支持时,

ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();

null

原因在于,Hystrix的默认隔离策略是THREAD 。而 RequestContextHolder 源码中,使用了两个血淋淋的ThreadLocal

解决方案一:调整隔离策略

将隔离策略设为SEMAPHORE即可:

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

这样配置后,Feign可以正常工作。

但该方案不是特别好。原因是Hystrix官方强烈建议使用THREAD作为隔离策略! 参考文档:

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.

于是,那么有没有更好的方案呢?

解决方案二:自定义并发策略

既然Hystrix不太建议使用SEMAPHORE作为隔离策略,那么是否有其他方案呢?答案是自定义并发策略,目前,Spring Cloud Sleuth以及Spring Security都通过该方式传递 ThreadLocal 对象。

下面我们来编写自定义的并发策略。

编写自定义并发策略

编写自定义并发策略比较简单,只需编写一个类,让其继承HystrixConcurrencyStrategy ,并重写wrapCallable 方法即可。

代码示例:

@Component
public class RequestAttributeHystrixConcurrencyStrategy extends HystrixConcurrencyStrategy {
    private static final Log log = LogFactory.getLog(RequestHystrixConcurrencyStrategy.class);

    public RequestHystrixConcurrencyStrategy() {
        HystrixPlugins.reset();
        HystrixPlugins.getInstance().registerConcurrencyStrategy(this);
    }

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

    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();
            }
        }
    }
}

如代码所示,我们编写了一个RequestHystrixConcurrencyStrategy ,在其中:

  • wrapCallable 方法拿到 RequestContextHolder.getRequestAttributes() ,也就是我们想传播的对象;
  • WrappedCallable 类中,我们将要传播的对象作为成员变量,并在其中的call方法中,为静态方法设值。
  • 这样,在Hystrix包裹的方法中,就可以使用RequestContextHolder.getRequestAttributes() 获取到相关属性——也就是说,可以拿到RequestContextHolder 中的ThreadLocal 属性。

经过测试,代码能正常工作。

新的问题

至此,我们已经实现了ThreadLocal 属性的传递,然而Hystrix只允许有一个并发策略!这意味着——如果不做任何处理,Sleuth、Spring Security将无法正常拿到上下文!(上文说过,目前Sleuth、Spring Security都是通过自定义并发策略的方式来传递ThreadLocal对象的。)

如何解决这个问题呢?

我们知道,Spring Cloud中,Spring Cloud Security与Spring Cloud Sleuth是可以共存的!我们不妨参考下Sleuth以及Spring Security的实现:

  • Sleuth:org.springframework.cloud.sleuth.instrument.hystrix.SleuthHystrixConcurrencyStrategy
  • Spring Security:org.springframework.cloud.netflix.hystrix.security.SecurityContextConcurrencyStrategy

阅读完后,你将恍然大悟——于是,我们可以模仿它们的写法,改写上文编写的并发策略:

public class RequestAttributeHystrixConcurrencyStrategy extends HystrixConcurrencyStrategy {
    private static final Log log = LogFactory.getLog(RequestAttributeHystrixConcurrencyStrategy.class);

    private HystrixConcurrencyStrategy delegate;

    public RequestAttributeHystrixConcurrencyStrategy() {
        try {
            this.delegate = HystrixPlugins.getInstance().getConcurrencyStrategy();
            if (this.delegate instanceof RequestAttributeHystrixConcurrencyStrategy) {
                // 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();
            }
        }
    }
}

简单讲解下:

  • 将现有的并发策略作为新并发策略的成员变量
  • 在新并发策略中,返回现有并发策略的线程池、Queue。

Pull Request

笔者已将该实现方式Pull Request:https://github.com/spring-cloud/spring-cloud-netflix/pull/2509 ,希望官方能够接纳,也希望在不久的将来,能够更舒服、更爽地使用Spring Cloud。

PS. Pull Request的代码跟博客中的代码略有区别,有少量简单的优化,主要是增加了一个开关。

灵感来自

目录
相关文章
|
5月前
|
Java
通用快照方案问题之调整Hystrix的信号量隔离模式的并发限制如何解决
通用快照方案问题之调整Hystrix的信号量隔离模式的并发限制如何解决
32 0
|
5月前
|
监控 Cloud Native Java
通用快照方案问题之Hystrix和Ribbon在超时设置上的冲突如何解决
通用快照方案问题之Hystrix和Ribbon在超时设置上的冲突如何解决
54 0
|
5月前
|
Prometheus 监控 数据可视化
通用快照方案问题之Hystrix进行指标监控如何解决
通用快照方案问题之Hystrix进行指标监控如何解决
46 0
hystrix服务降级处理方案
当一个服务端的业务响应的时间过长的时候或者业务处理逻辑处理异常,不应该等待,应该给出一种处理方法
hystrix服务降级处理方案
|
Java 应用服务中间件 UED
分布式系统架构中高可用方案技术选型:Hystrix 框架实现服务保护使用详解
本篇文章介绍了分布式系统架构下的经典的高可用框架Hsytrix实现的断路器,服务降级,服务熔断,服务隔离以及解决服务雪崩效应的问题。详细分析了基于Hystrix框架解决分布式系统中服务雪崩效应的几种机制,以及在项目中如何集成Hystrix框架并且在项目中使用Hystrix框架实现分布式系统中的服务治理。
782 0
分布式系统架构中高可用方案技术选型:Hystrix 框架实现服务保护使用详解
|
缓存 Java Maven
Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失
Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失
241 0
|
负载均衡 Java 测试技术
Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失(续)
Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失(续)
403 0
|
6月前
springCloud之服务降级熔断Hystrix、OpenFeign
springCloud之服务降级熔断Hystrix、OpenFeign
356 0
|
7月前
|
监控 Java API
Spring cloud Hystrix 、Dashboard、API(zuul)相关报错
Spring cloud Hystrix 、Dashboard、API(zuul)相关报错
75 2
|
3月前
|
XML 监控 Java
Spring Cloud全解析:熔断之Hystrix简介
Hystrix 是由 Netflix 开源的延迟和容错库,用于提高分布式系统的弹性。它通过断路器模式、资源隔离、服务降级及限流等机制防止服务雪崩。Hystrix 基于命令模式,通过 `HystrixCommand` 封装对外部依赖的调用逻辑。断路器能在依赖服务故障时快速返回备选响应,避免长时间等待。此外,Hystrix 还提供了监控功能,能够实时监控运行指标和配置变化。依赖管理方面,可通过 `@EnableHystrix` 启用 Hystrix 支持,并配置全局或局部的降级策略。结合 Feign 可实现客户端的服务降级。
187 23