DRY – один из самых известных принципов разработки ПО: он помогает избежать ненужного повторения фрагментов кода, которые выполняют одни и те же действия. DRY также стоит применять при настройке конфигурации сложных систем, поскольку этот принцип:
- Делает конфигурацию более компактной и легкой для понимания.
- Упрощает поддержку – когда нужно внести изменения, вы делаете это только в одном месте.
- Повышает читаемость – конфигурация становится более структурированной и логичной, что облегчает ее понимание другими разработчиками или администраторами.
- Улучшает масштабируемость – при усложнении конфигурации принципы DRY помогают сохранять ее управляемой и расширяемой.
- Сокращает время на настройку – используя переиспользуемые компоненты, можно быстрее создавать новые конфигурации или модифицировать существующие.
В качестве примера рассмотрим, как применять DRY при настройке конфигурации API-шлюза Apache APISIX.
DRY-настройка Upstream
Upstream в Apache APISIX выполняет балансировку нагрузки на заданный набор сервисных узлов согласно правилам конфигурации: отвечает за маршрутизацию клиентских запросов и их направление к соответствующим сервисам. При разработке, например, онлайн-магазина, начинающий бэкендер, скорее всего, начнет определение маршрута таким образом:
Довольно быстро разработчик сообразит, что этот подход совершенно ошибочен – он допускает выполнение всех HTTP-методов в каталоге товаров, тогда как добавление, удаление и обновление записей должны быть доступны только авторизованным пользователям. Для решения этой проблемы бэкендер разделит маршрут на две части:
Проблема вроде бы решена, но настройки теперь дублируются – если будет нужно добавить или удалить узлы, это придется сделать в двух местах. И хотя в реальных проектах ноды обычно не перечисляют вручную, а подключают динамически с помощью обнаружения сервисов, смысл ошибки от этого не меняется – дублирование кода/настроек влечет за собой утомительную необходимость внесения изменений во все повторяющиеся фрагменты. В случае с приведенным выше примером дубликацию можно исправить так:
Нужно отметить, что в Apache APISIX есть два способа настроить upstream:
- Встроенный – конфигурация указывается непосредственно в маршруте.
- Ссылка по ID – когда создается отдельный объект upstream, на который ссылаются через
upstream_id.
Эти два подхода являются взаимоисключающими – нельзя одновременно использовать их в одном маршруте.
Принцип DRY в конфигурации плагинов
Большая часть функциональности APISIX реализуется через плагины, и при их настройке тоже важно следовать принципу DRY. Предположим, нужно реализовать версионирование API на основе пути. Для этого нужно переписать URI перед его отправкой:
Здесь есть что оптимизировать – операция по удалению префикса дублируется. Дубликацию можно исправить, если вынести обработку URI в отдельный объект plugin_configs:
В отличие от upstream и upstream_id, настройки plugins и plugin_config_id не являются взаимоисключающими – напротив, APISIX предусматривает их одновременное использование для разделения общих настроек и специфических для конкретного маршрута. При этом конфигурация плагина в маршруте имеет приоритет над конфигурацией в plugin_config_id. Например, при работе с плагином key-auth можно задать переменную apikey на уровне потребителя, но изменить ее значение для конкретного маршрута.
Комментарии