如何使用hystrix的配置

本文主要介绍“如何使用海斯特里克斯配置”。在日常操作中，相信很多人对于如何使用hystrix配置有疑问。边肖查阅了各种资料，整理出简单易用的操作方法，希望能帮助大家解决关于如何使用hystrix配置的疑惑！接下来，请和边肖一起学习！

前言

feign是一个优秀的Http请求客户端封装框架。feign-海斯特里克斯是整个框架系统中的模块之一，用于集成海斯特里克斯保险丝。feign和海斯特里克斯都是网飞的开源项目(open假动作已经被独立迭代)。在spring boot项目中，您可以使用spring-cloud-starter-open假死模块来无缝集成feign和海斯特里克斯。但是，hystrix默认使用archius来驱动hytrix的配置系统，这将使archius-core进入hytrix，同时无缝集成。Archaius是一个配置中心项目，类似于spring cloud config和apollo。如果archaius仅用作hystrix配置的驱动程序，则在项目启动时会打印令人讨厌的警告日志，提示您尚未配置动态配置源。项目采用apollo时，可直接淘汰Archaius，两者功能定位高度重合。直接移除依赖关系将导致spring中原始配置的无效。博主也遇到了不小心删除后配置无效的问题，于是想出了这个博文，并记录了过程。稍加修改并结合apollo配置动态分配能力，hystrix的配置可以实时动态生效。

feign:https://github.com/OpenFeign/feign

海斯特里克斯：https://github.com/Netflix/Hystrix

https://github.com/Netflix/archaius

https://github.com/ctripcorp/apollo

archaius警告日志

2020-12-1011:19:41.766 warn 12835-[main]c . n . c . sources . urlsconfigurationsources : ourlswilbepolledasdaldynamicconfiguration sources .

2020-12-1011:19:41 . 766 info 12835-[main]c . n . c . sources . urlconfigurationsource : toenableurlasdynamicconfigures sources，define systememppropertyarchius . configurationsource . additionalurlsmakecoconfig . properties availableonclass path。

2020-12-1011:19:41.772 warn 12835-[main]c . n . c . sources . urlconfigurationsources : ourlswillbolledaskdynamicconfiguries。

2020-12-1011:19:41 . 772 info 12835-[main]c . n . c . sources . urlconfigurationsources : toenableurlasdynamicconfigurations，DefineSystemPropertyArchaius。配置来源。additionalurlsormakecoconfig。属性平均类路径。

我们遇到的问题

在一次系统优化重构中，博主给了整个项目一个360的大瘦身，去掉了所有不用的依赖。包括春云启动器。

-openfeign模块的archaius-core依赖。因为我们已经使用了apollo配置中心，archaius在这个项目里显得很多余，而且还会打印烦人的警告日志。所以就直接排除了，如：

implementation ('org.springframework.cloud:spring-cloud-starter-openfeign'){
    exclude(module:"archaius-core")
}

为此，专门了解了下archaius的来历，并且针对feign的熔断器的Fallback能力进行了测试，一切运行正常。上线一周后，问题暴露出来了，同事反馈，hystrix的配置好像不生效了。现象是，原本设置的hystrix线程执行不超时，却发生了很多执行一秒就超时了，我们的关键配置如下(这不是一个很好的配置示范，后面会调整更细粒度控制)：

#禁止执行超时
hystrix.command.default.execution.timeout.enabled = false

直观感觉就是这个配置不生效了，联想到archaius-core被移除，所以先立马恢复了依赖，重新打包上线，问题解决。就这？为了彻底搞清楚Hystrix的配置加载过程，我们对feign整合hystrix进行了全面的了解。

 

hystrix在feign中的加载过程

在spring-cloud-starter-openfeign的封装下，使用起来非常简单，但是内部的加载流程非常复杂。所以博主也不打算全面铺开来说这块内容，有机会会独立一篇来说。这里根据我们上文遇到的禁用执行超时不生效的问题，博主总结了加载流程中的几个关键的地方：

Feign和Hystrix的桥接器Feign-Hystrix


这个项目是feign和hystrix的桥接器，通过这样的一个桥接器，将两个框架的api能力整合在了一起，下面简要阐述下，加载过程关键类的作用：

• SetterFactory：承载了构造HystrixCommand实例的所有的配置的接口，有一个默认实现Default，在下面会用到，是自定义配置实现的突破口

• HystrixInvocationHandler：这是一个实现了JDK代理接口类，用来代理Feign最终的执行，HystrixCommand类就是在这个实例里被构造执行的，使用的构造方法正是带入参Setter的构造方法，集成方会实现SetterFactory来构造Setter。调试程序时我们将端点打进这个类里，就可以看到配置加载的情况

spring boot自动加载hystrix

@Configuration
@ConditionalOnClass({ HystrixCommand.class, HystrixFeign.class })
protected static class HystrixFeignConfiguration {
   @Bean
   @Scope("prototype")
   @ConditionalOnMissingBean
   @ConditionalOnProperty(name = "feign.hystrix.enabled")
   public Feign.Builder feignHystrixBuilder() {
      return HystrixFeign.builder();
   }
}

这里是Hystrix在feign框架下加载的总入口。这个默认的构建器Builder中，有一个默认实现的SetterFactory，这个SetterFactory专门负责传递参数给Hystrix初始化HystrixCommand用。可以看到这里Bean的实例化加上了@ConditionalOnMissingBean条件约束，既我们可以自定义实现Hystrix的构造器，覆盖这里的实现，在自定义的构造器中，可以通过自定义实现SetterFactory，来注入任意的配置。这个是实现Hystrix配置自定义加载的方式之一，不过不推荐，没必要破坏spirng现有的这种结构，而且代码也会比较冗长(下面{...}省略了一百多行配置处理代码，用来兼容Hystrix现有配置定义)，看起来如下：


 

Hystrix的动态兜底配置

配置是hystrix的核心，各种策略的选择执行都需要配置来驱动，所以，虽然在应用层面不需要太多的配置设置，但是必要的配置hystrix都会填充一个默认值，比如，hystrix默认执行超时设置的1s。Hystrix中的配置有三个层次的加载优先级，如：

1. 最先加载Setter：Setter是用户传递给Hystrix构造器的，所以优先级别最高

2. 其次加载动态配置源：如果必要的配置在Setter里没有找到，则在动态配置源中获取

3. 最后加载默认配置：如果动态配置源中也没有找到配置，则采用默认的配置

其中动态配置源，有一个基于SystemProperties的配置实现HystrixDynamicPropertiesSystemProperties。HystrixCommand在实例化时，如果用户没有给到具体的配置，Hystrix每次都会去SystemProperties中寻找配置。也就是说，我们可以通过-D参数注入任意Hystrix的配置参数，都会生效。有了这个特性，可以非常简单的结合apollo，达到hystrix配置动态生效的效果，而且所有配置兼容Hystrix原本的配置。

 

apollo配置驱动Hystrix

实现这个功能的关键是。系统初始化时，将hystrix.command前缀相关的配置从apollo中获取到然后统统注入SystemProperties。配置更新时，同时更新SystemProperties中的配置即可，非常简单，用代码说话：

/**
 * @author kl (http://kailing.pub)
 * @since 2020/12/10
 */
@Slf4j
@Configuration
@AutoConfigureBefore(value = {FeignClientsConfiguration.class, FeignAutoConfiguration.class})
public class HystrixConfiguration{
    public static final String DYNAMIC_TAG = "dynamic.";
    public static final String DYNAMIC_PREFIX = DYNAMIC_TAG + "hystrix.command.";
    public static final String PREFIX = "hystrix.command.";
    @ApolloConfig
    private Config config;
    @PostConstruct
    public void initHystrix(){
        this.config.addChangeListener(
                event -> this.loadHystrixConfig(event.changedKeys()),
                null,
                Sets.newHashSet(DYNAMIC_PREFIX)
        );
        this.loadHystrixConfig(config.getPropertyNames());
    }
    private void loadHystrixConfig(Setconfigkyes) {
        configkyes.forEach(key -> {
            if (StringUtils.containsIgnoreCase(key, PREFIX)) {
                String value = config.getProperty(key, null);
                String realKey = key.replaceAll(DYNAMIC_TAG,"").trim();
                System.setProperty(realKey, value);
                log.info("Hystrix config: {}={}", key, value);
            }
        });
    }
}

这里注意一个问题：为啥这里多设计了一个dynamic.前缀的配置，这是因为博主在测试过程中触发了apollo配置监听器隐藏的问题，导致Apollo的动态监听器不生效了。Apollo配置加载是以SystemProperties为最高优先级的，当配置发生变化时，apollo会将SystemProperties覆盖到配置之后，才比较本次配置发布是否有更新。因为我们一开始就将相关的配置加载到SystemProperties里了，所以每次变更都会被覆盖成之前的值，导致更新判断失效，一直进不了监听器。如果想要动态更新，就需要维护一份apollo的配置和SystemProperties里的映射关系，而不能保持一致，这样每次修改apollo时，就可以将维护映射关系的前缀去掉，然后将值动态更新到SystemProperties。目前的设计里，既支持原生的所有配置一次性加载，也支持dynamic.前缀拼装原有配置动态加载

配置示例

#初始化时一次性加载
hystrix.command.default.execution.timeout.enabled = true
#每次修改动态生效
dynamic.hystrix.command.default.execution.timeout.enabled = true

到此，关于“如何使用hystrix的配置”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！