【问题标题】:Spring Cloud Binder: mitigating cost of double bootstrapSpring Cloud Binder:降低双重引导的成本
【发布时间】:2019-05-04 22:36:13
【问题描述】:

我们使用 Spring Cloud Config (Dalston.SR5),云客户端使用 Spring Boot 2.x、Spring Cloud Bus 和 Finchley.SR1

我从this answer 了解到为什么云客户端应用程序使用父级SpringBootApplication 的配置引导,然后在绑定云总线后再次启动。我没问题。

我的问题是有没有办法区分这两个引导请求?

我问的原因是我们的配置服务器生成凭据并将它们返回给客户端进行身份验证。两个引导程序意味着两组凭据,只有一组被使用,这很浪费。

据我所知,ConfigServicePropertySourceLocator 每次都发送相同的引导有效负载,这使 Config 没有机会。

是否有覆盖/挂钩,以便我可以让 Config 知道不要第二次生成凭据?

(我可以从配置/服务器端解决,但这有点绝望,而且我不愿意尝试管理状态 - 跨越两个恰好相隔约 20 秒的其他相同请求。)


我目前的最佳想法是继承 PropertySourceBootstrapConfiguration 并按照以下方式更新 spring.factories

# Bootstrap components
org.springframework.cloud.bootstrap.BootstrapConfiguration=\
org.springframework.cloud.bootstrap.config.MyCountingPropertySourceBootstrapConfiguration,\

在发出任何请求之前,我应该能够检查PropertySources 并查找第一个成功引导程序会返回的任何属性。如果存在,我会尝试在ConfigServicePropertySourceLocator 中添加一个额外的标签或配置文件,以便我的配置服务器第二次获取。

我想这可能有效,但有没有更清洁/更符合 Spring Boot 的方式?

【问题讨论】:

    标签: java spring-boot spring-cloud-config spring-cloud-bus


    【解决方案1】:

    这个解决方案看起来既简单又非常有效。

    新的自动配置来控制ConfigServicePropertySourceLocator

    @Configuration
    @AutoConfigureBefore(ConfigServiceBootstrapConfiguration.class)
    public class ConfigPropertyLocatorConfiguration {
    
        @Bean
        @ConditionalOnProperty(value = "spring.cloud.config.enabled", matchIfMissing = true)
        public ConfigServicePropertySourceLocator configServicePropertySource(ConfigClientProperties properties) {
            return new CachingConfigServicePropertySourceLocator(properties);
        }
    }
    

    spring.factories:

    org.springframework.cloud.bootstrap.BootstrapConfiguration=\
      autoconfigure.ConfigPropertyLocatorConfiguration
    

    缓存定位器实现:

    public class CachingConfigServicePropertySourceLocator extends
                                               ConfigServicePropertySourceLocator {
    
        private final static Logger LOG = getLogger("...");
    
        private PropertySource<?> cachedProperties;
    
        public CachingConfigServicePropertySourceLocator(ConfigClientProperties props) {
            super(props);
        }
    
        public PropertySource<?> locate(final Environment env) {
            if (cachedProperties == null) {
                cachedProperties = super.locate(env);
            }
            else {
                LOG.debug("Returning cached PropertySource for second bootstrap");
            }
    
            return cachedProperties;
        }
    }
    

    已经获得了第二次引导的机会,完全忽略它并再次返回相同的 PropertySource 似乎有点粗鲁 - 但在我们的情况下这很好。它可以防止我们两次访问配置服务器并浪费地生成凭据。

    无需更改PropertySourceBootstrapConfiguration。云配置服务器没有变化。

    【讨论】:

      猜你喜欢
      • 2019-12-13
      • 2014-02-25
      • 2018-12-15
      • 2019-04-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-16
      相关资源
      最近更新 更多