Конфигурация Java систем — как убрать боль

Проблема

Если вы хотя бы однажды разрабатывали большую систему на Java и сопровождали её, то, наверняка, сталкивались с неудобствами настройки тех или иных процессов в системе. 

А именно: размеры различных буферов; параметры почтового ящика; хост, порт, логин, пароль вызова внешних сервисов; всякие таймауты и многое другое.

Каждый раз менять всё это в коде, пересобирать и перенакатывать на реал — не комильфо.

Естественно все эти параметры нужно выносить в файлы конфигов и считывать их оттуда — все так делают.

В Java из коробки для этого есть некий Properties. Но пользоваться им крайне неудобно. Во-первых, UTF-8 там не работают, во-вторых — если вы поменяли какой-нибудь параметр в конфиге, то чтобы новое значение попало в систему — требуется перезапуск приложения. А если вы не хотите его перезапускать, или это невозможно в 11 утра — час пиковой нагрузки. И отложить на потом не вариант — нужно срочно. Что делать? Нужно чтобы конфиги перечитывались на «горячую», т. е. без перезапуска системы.

А ещё очень важно: нужно как-то так придумать чтобы имена параметров конфигов в коде программы соответствовали тем, которые в файле. Т. е. чтобы трудно было ошибиться. Обычно используют для этого константы — помогает, но хотелось бы что-то удобнее, проще и гибче.

И вот ещё что: представьте у вас крупная система в которой уже накопилось около тридцати конфигурационных файлов, и в каждом по десятку параметров. И вам нужно накатить новую инстанцию. Как вы будете настраивать эти конфиги? Создавать каждый вручную? В каждом прописывать имена параметров и их значения, вспоминая что каждый из них значит? А если забыли? А есть документация? А эта документация актуальная? А если вы ошибётесь в одной буковке параметра — позволит ли вам система при старте сразу объяснить что не так? Или она свалится в час ночи, когда вы крепко спите? Вам придётся просыпаться, включать как-то мозг и разбираться во всей этой истории…

Хотелось бы избежать всей этой нервотрёпки.

Надо как-то сделать так, чтобы система создавала все эти конфиги сама, и описывала их всех — что каждый конфиг делает в общем, и каждый параметр в частности. Ну и разработчик не должен сильно напрягаться чтобы поддерживать всю эту автоматизацию в актуальном состоянии.

Всё это должно быстро и легко активироваться — подключил какую-то маленькую библиотечку, прописал какой-то магический код размером не больше пяти-десяти строк (автосгенерированные вашей IDE строки не считаем) — и вуаля — всё работает.

Можно конечно использовать конфигурационный сервер, и даже кто-то это делает (вроде), но это как-то напряжно — хочется что-нибудь проще, но эффективно.

Мы в greetgo! поискали в разных интернетах, но так ничего подходящего не нашли — пришлось пилить самим.

Решение

Основной идеей было использовать Java-интерфейс для чтения данных конфига, и, одновременно, формирования структуры конфига. Вы один раз в интерфейсе написали имя метода — и это имя автоматически становится именем параметра в конфиге. Вам не нужно его писать второй раз в файле конфига, опасаясь допустить ошибку в одной букве — файл пусть создаётся автоматически со всеми параметрами — вам нужно будет только подкорректировать значения параметров.

Например вы хотите вынести в конфиг updateTimeout и batchSize — потому что трудно их подобрать изначально. Для этого создаёте Java-интерфейс:

public interface MyMigrationConfig {   long updateTimeoutMs();   int  batchSize(); }

Хотя вот так будет лучше:

@Description("Миграция состояний в ядро системы"); public interface MyMigrationConfig {   @Description("Максимальное время миграции одной порции в миллисекундах."                + " Если оно будет превышено, то миграция будет немедленно"                + " прервана с ошибкой")   @DefaultLongValue(30000)   long updateTimeoutMs();    @Description("Размер порции мигрируемых данных в записях")   @DefaultIntValue(150)   int batchSize(); }

Теперь этот интерфейс надо зарегистрировать в какой-то классной штуке, которая умеет автоматически создавать магические реализации подобных интерфейсов, и после этого пользоваться, например, таким способом:

@Autowire private MyMigrationConfig config;   public void migrate() {   // ...   System.out.println(" updateTimeoutMs = " + config.updateTimeoutMs());   System.out.println(" batchSize       = " + config.bachSize());   // ... }

Такой простой подход позволяет легко настраивать и сопровождать любые настройки системы, как во время разработки так и во время сопровождения.

Нами была разработана библиотека, которая позволяет реализовать такой подход. Она получилась маленькой и у неё нет никаких других зависимостей. И она уже долго и интенсивно нами используется, другими словами она production ready. Лицензия — MIT.

Называется она greetgo conf — она есть и в maven и в github: https://github.com/greetgo/greetgo.conf

Подключив её к проекту, необходимо создать фабрику конфигов примерно так:

public class MyConfigFactory extends FileConfigFactory {   @Override   public Path getBaseDir() {     return Paths.get("/path/to/directory/where/config/files/are/located");   }    @Override   protected String getConfigFileExt() {     return ".conf";   } }

Дальше создаём инстанцию этой фабрики и пользуемся магическим методом createConfig:   

MyConfigFactory confFactory = new MyConfigFactory();  MyMigrationConfig config =  confFactory.createConfig(MyMigrationConfig.class);

Теперь у нас есть инстанция интерфейса конфига и мы можем считывать данные конфига. Они будут считываться из файла с именем MyMigrationConfig.conf. Этот файл создастся автоматически, если его ещё нет, с примерно таким содержимым:

# Created at 2021-01-29 11:03:21 # Миграция состояний в ядро системы  # Размер порции мигрируемых данных batchSize=150  # Максимальное время миграции одной порции в миллисекундах. Если оно будет # превышено, то миграция будет немедленно прервана с ошибкой updateTimeoutMs=30000

Теперь вы можете менять эти параметры и система автоматически их будет перечитывать. Естественно про оптимизацию мы подумали — всё это внимательно кэшируется, и, если вы будете очень часто считывать параметры (тысячи раз в секунду), то это не вызовет большую нагрузку на файловую систему.

Возможности

Со временем у нас появились распределённые проекты с большим количеством нод и с использованием kubernetes. Хранить настройки в файлах в таких проектах оказалось не удобно, и мы сделали расширение библиотеки, которое позволяет хранить настройки в Zookeeper, для этого нужно просто заменить FileConfigFactory на AbstractZookeeperConfigFactory, ну и прописать параметры доступа к Zookeeper.

Также есть реализация JdbcConfigFactory — которая позволяет хранить настройки в реляционной БД.

Архитектура библиотеки позволяет достаточно просто разрабатывать свои фабрики конфигов, например чтобы хранить конфиги в яндекс-диске.

Также есть возможность использовать аннотацию @FirstReadEnv — которая считывает помеченный ей параметр не из конфига, а из переменной окружения — в kubernetes некоторые параметры удобнее задавать через переменные окружения.

На этом все. Спасибо за внимание.