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

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

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

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

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

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

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

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

🪶 Как следовать принципу DRY при настройке 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 на уровне потребителя, но изменить ее значение для конкретного маршрута.

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

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

eFusion
08 января 2020

11 типов современных баз данных: краткие описания, схемы и примеры БД

Любые данные где-то хранятся. Будь это интернет вещей или пароли в *nix. По...
admin
23 февраля 2017

SQL за 20 минут

Предлагаем вашему вниманию статью с кричащим названием "SQL за 20 минут". К...