Spring Cloud Binder: снижение стоимости двойной загрузки - PullRequest
Новая
       58

Spring Cloud Binder: снижение стоимости двойной загрузки

0 голосов
/ 03 декабря 2018

Мы используем Spring Cloud Config (Dalston.SR5), а клиенты Cloud используют Spring Boot 2.x, Spring Cloud Bus и Finchley.SR1.

Я понимаю из этот ответ почему приложение Cloud Client загружается с Config для родительского SpringBootApplication, а затем снова после привязки Cloud Bus.Я в порядке с этим.

Мой вопрос заключается в том, существует ли какой-либо способ различить два запроса начальной загрузки?

Причина, по которой я спрашиваю, состоит в том, что наш сервер Config генерирует учетные данные и возвращает ихклиент для аутентификации.Два загрузчика означают два набора учетных данных, только один из которых используется, и это расточительно.

Насколько я могу судить, одна и та же полезная нагрузка загрузчика отправляется каждый раз с помощью ConfigServicePropertySourceLocator, что не дает Config никакой возможности.

Существует ли переопределение / перехват, чтобы я мог сообщить Config, что он не генерирует учетные данные во второй раз?

(я мог бы заняться со стороны Config / server, но это было бынемного отчаялся, и я не хотел бы пытаться управлять состоянием - через два в остальном идентичных запроса, которые, как оказалось, разнесены на ~ 20 секунд.)

Лучшая идея, которую я имею в данный момент, - это создать подкласс PropertySourceBootstrapConfiguration и обновите spring.factories согласно: 

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

Прежде чем делать какие-либо запросы, я должен иметь возможность изучить PropertySource s и найти любые свойства, которые вернул бы первый успешный загрузчик,Если он присутствует, я бы попытался добавить дополнительную метку или профиль в ConfigServicePropertySourceLocator, чтобы мой сервер Config мог поднять его второй раз.

Я думаю, это может сработать, но есть ли более чистый / более Spring Boot-у тебя?

1 Ответ

0 голосов
/ 12 декабря 2018

Это решение кажется простым и очень эффективным.

Новая автоконфигурация для управления 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 еще раз - но в нашей ситуации этохорошо.Это предотвращает нас от двойного попадания на сервер Config и расточительной генерации учетных данных.

Никаких изменений для PropertySourceBootstrapConfiguration не требуется.Нет изменений на сервере облачных настроек.

...