Весенние свойства горячей перегрузки - PullRequest
Новая
       8

Весенние свойства горячей перегрузки

0 голосов
/ 08 февраля 2019

В проекте у меня есть объект org.apache.commons.configuration.PropertiesConfiguration, зарегистрированный как Бин, для предоставления значений конфигурации вокруг приложения с возможностью горячей перезагрузки.

Пример: я определил DataSource одноэлементный Бин.Затем я создал объект ReloadingDataSource, который переносит и делегирует «реальный» DataSource, и каждый раз, когда файл конфигурации изменяется, он может воссоздать его в поточно-ориентированном режиме.

IЯ хотел бы сделать что-то подобное для простых значений свойств.
Я хотел бы создать простой, Autowire способный объект, который делегирует извлечение в Apache PropertiesConfiguration Bean.

Использование должно бытьпохож на: 

@Property("my.config.database")
private Property<String> database;

И сайт вызова будет просто: 

final String databaseValue = database.get()

Вы скажете, просто обведите объект PropertiesConfiguration.Может быть, вы и правы, но я бы хотел предложить другую абстракцию, более простую в использовании.

Я знаю, что с ProxyFactoryBean можно создать прокси AOP для вызовов методов,Это правильный путь или есть лучшие альтернативы?Может быть, чистый Spring AOP / AspectJ?

Я не хочу использовать Spring Cloud или аналогичные зависимости.

1 Ответ

0 голосов
/ 08 февраля 2019

Spring Cloud воссоздает bean-компоненты, поэтому имейте в виду, какое бы решение вы ни предложили, если у вас есть другой bean-компонент, который читает это значение только один раз, например, когда он инициируется, он не будет повторно инициализировать себя, то естьПроблема Spring Cloud Config решает.

AOP работает только на уровне методов, насколько я понимаю, поэтому вы можете определенно перехватить вызов somebean.getFoo().Но в somebean нет способа прокси-вызовов самой переменной: somebean.foo.Вам нужно будет сбрасывать foo каждый раз, когда ваш PropertiesConfiguration изменяется, и снова имейте в виду, что, если что-то еще будет нуждаться в новом значении foo, вам нужно будет обработать это или откусить пулю с помощью Spring Cloud.

Надо тщательно продумывать накладные расходы, связанные с изменением содержимого во время выполнения, чтобы избежать повторного развертывания.Для Netflix это имеет смысл, потому что у них тысячи и тысячи серверов.Но для небольших игроков я не вижу оправдания, решение добавляет много сложности.Кошмар для тестирования.

  • Вы тестируете изменение своей конфигурации во время выполнения или принимаете риск и предполагаете, что он работает?
  • Тестируете ли вы переход от A -> B, пока под нагрузкойпользователя, выполняющего транзакцию с базой данных?
  • Проверьте другие условия повышения, где foo меняется?

Некоторые вопросы, о которых стоит подумать.

...