前言

feign是一个杰出的Http申请客户端封装框架，feign-hystrix是整个框架体系里的其中一个模块，用来集成hystrix熔断器的，feign和hystrix这两个我的项目都是Netflix开源的(openfeign已独立迭代)。在spring boot我的项目中，能够应用spring-cloud-starter-openfeign模块，无缝集成feign和hystrix。然而，hystrix默认采纳的Archaius来驱动hystrix的配置零碎，无缝集成的同时，也会把archaius-core给引入进来。archaius是一个配置核心我的项目，相似spring cloud config和apollo，如果archaius只是作为hystrix配置的驱动，我的项目启动时会打印烦人的正告日志，提醒你没有配置任何动静配置源。当我的项目里曾经采纳了apollo时，能够间接剔除掉Archaius，他们的功能定位高度重合了。间接剔除依赖，会导致本来配置在spring中的配置不失效，博主也是在不小心剔除后，遇到了配置不失效的问题，才有了本篇博文，记录下过程。只有稍加改变，联合apollo配置动静下发能力，能够做到hystrix的配置实时动静失效。

  • feign：https://github.com/OpenFeign/...
  • hystrix：https://github.com/Netflix/Hy...
  • archaius：https://github.com/Netflix/ar...
  • apollo：https://github.com/ctripcorp/...

archaius正告日志

2020-12-10 11:19:41.766 WARN 12835 --- [ main] c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.2020-12-10 11:19:41.766 INFO 12835 --- [ main] c.n.c.sources.URLConfigurationSource : To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.2020-12-10 11:19:41.772 WARN 12835 --- [ main] c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.2020-12-10 11:19:41.772 INFO 12835 --- [ main] c.n.c.sources.URLConfigurationSource : To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.

咱们遇到的问题

在一次系统优化重构中，博主给整个我的项目来了一个360的大瘦身，把所有的未应用的依赖通通给挪走了。其中就包含了spring-cloud-starter-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(Set<String> configkyes) {        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

结语

Feign-hystrix的配置，有了Apollo，还用Archaius吗？当然不必，采纳apollo实现计划，既兼容了所有原生配置，还能够做到动静失效，岂不美哉。