🪶 Как следовать принципу DRY при настройке Apache APISIX

Объясняем, как принцип DRY (Don't Repeat Yourself) помогает избежать дублирования и упростить настройку Apache APISIX, делая конфигурацию более компактной и управляемой.

Этот материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.

📧 Подписаться

(function () { let link = document .getElementById ("82223eb3-b78d-464d-8178-77f902fb842f-https://proglib.io/w/cf351d3d-2"); if (! link) return; let href = link .getAttribute ("href"); if (! href) return; let prefix = link .dataset .prefix; let action = link .dataset .action; link .addEventListener ("click", function (e) { let data = new FormData (); data .append ("url", href); apiFetch (action, { method: "POST", body: data }) .then (function (res) {}) .catch (function (err) { console .error (err); }); }) })();

DRY – один из самых известных принципов разработки ПО: он помогает избежать ненужного повторения фрагментов кода, которые выполняют одни и те же действия. DRY также стоит применять при настройке конфигурации сложных систем, поскольку этот принцип:

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

В качестве примера рассмотрим, как применять DRY при настройке конфигурации API-шлюза Apache APISIX.

DRY-настройка Upstream

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

Довольно быстро разработчик сообразит, что этот подход совершенно ошибочен – он допускает выполнение всех HTTP-методов в каталоге товаров, тогда как добавление, удаление и обновление записей должны быть доступны только авторизованным пользователям. Для решения этой проблемы бэкендер разделит маршрут на две части:

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

Нужно отметить, что в Apache APISIX есть два способа настроить upstream:

• Встроенный – конфигурация указывается непосредственно в маршруте.
• Ссылка по ID – когда создается отдельный объект upstream, на который ссылаются через upstream_id.

Эти два подхода являются взаимоисключающими – нельзя одновременно использовать их в одном маршруте.

Статья по теме

10 заповедей разработки и тестирования

Принцип DRY в конфигурации плагинов

Большая часть функциональности APISIX реализуется через плагины, и при их настройке тоже важно следовать принципу DRY. Предположим, нужно реализовать версионирование API на основе пути. Для этого нужно переписать URI перед его отправкой:

Здесь есть что оптимизировать – операция по удалению префикса дублируется. Дубликацию можно исправить, если вынести обработку URI в отдельный объект plugin_configs:

В отличие от upstream и upstream_id, настройки plugins и plugin_config_id не являются взаимоисключающими – напротив, APISIX предусматривает их одновременное использование для разделения общих настроек и специфических для конкретного маршрута. При этом конфигурация плагина в маршруте имеет приоритет над конфигурацией в plugin_config_id. Например, при работе с плагином key-auth можно задать переменную apikey на уровне потребителя, но изменить ее значение для конкретного маршрута.

💻 Библиотека программиста

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»