Хочешь уверенно проходить IT-интервью?
![Готовься к IT-собеседованиям уверенно с AI-тренажёром T1!](https://media.proglib.io/banner/2025/01/28/t1.jpg)
Мы понимаем, как сложно подготовиться: стресс, алгоритмы, вопросы, от которых голова идёт кругом. Но с AI тренажёром всё гораздо проще.
💡 Почему Т1 тренажёр — это мастхэв?
- Получишь настоящую обратную связь: где затык, что подтянуть и как стать лучше
- Научишься не только решать задачи, но и объяснять своё решение так, чтобы интервьюер сказал: "Вау!".
- Освоишь все этапы собеседования, от вопросов по алгоритмам до диалога о твоих целях.
Зачем листать миллион туториалов? Просто зайди в Т1 тренажёр, потренируйся и уверенно удиви интервьюеров. Мы не обещаем лёгкой прогулки, но обещаем, что будешь готов!
Реклама. ООО «Смарт Гико», ИНН 7743264341. Erid 2VtzqwP8vqy
DRY – один из самых известных принципов разработки ПО: он помогает избежать ненужного повторения фрагментов кода, которые выполняют одни и те же действия. DRY также стоит применять при настройке конфигурации сложных систем, поскольку этот принцип:
- Делает конфигурацию более компактной и легкой для понимания.
- Упрощает поддержку – когда нужно внести изменения, вы делаете это только в одном месте.
- Повышает читаемость – конфигурация становится более структурированной и логичной, что облегчает ее понимание другими разработчиками или администраторами.
- Улучшает масштабируемость – при усложнении конфигурации принципы DRY помогают сохранять ее управляемой и расширяемой.
- Сокращает время на настройку – используя переиспользуемые компоненты, можно быстрее создавать новые конфигурации или модифицировать существующие.
В качестве примера рассмотрим, как применять DRY при настройке конфигурации API-шлюза Apache APISIX.
DRY-настройка Upstream
Upstream в Apache APISIX выполняет балансировку нагрузки на заданный набор сервисных узлов согласно правилам конфигурации: отвечает за маршрутизацию клиентских запросов и их направление к соответствующим сервисам. При разработке, например, онлайн-магазина, начинающий бэкендер, скорее всего, начнет определение маршрута таким образом:
![🪶 Как следовать принципу DRY при настройке Apache APISIX](https://media.proglib.io/posts/2024/09/23/3bd08fe178021a0232a65a3988cd0579.png)
Довольно быстро разработчик сообразит, что этот подход совершенно ошибочен – он допускает выполнение всех HTTP-методов в каталоге товаров, тогда как добавление, удаление и обновление записей должны быть доступны только авторизованным пользователям. Для решения этой проблемы бэкендер разделит маршрут на две части:
![🪶 Как следовать принципу DRY при настройке Apache APISIX](https://media.proglib.io/posts/2024/09/23/212f08a70ec3e58a57021d22621e97d4.png)
Проблема вроде бы решена, но настройки теперь дублируются – если будет нужно добавить или удалить узлы, это придется сделать в двух местах. И хотя в реальных проектах ноды обычно не перечисляют вручную, а подключают динамически с помощью обнаружения сервисов, смысл ошибки от этого не меняется – дублирование кода/настроек влечет за собой утомительную необходимость внесения изменений во все повторяющиеся фрагменты. В случае с приведенным выше примером дубликацию можно исправить так:
![🪶 Как следовать принципу DRY при настройке Apache APISIX](https://media.proglib.io/posts/2024/09/23/45f2ddf604115430fd70e8bde08018b1.png)
Нужно отметить, что в Apache APISIX есть два способа настроить upstream:
- Встроенный – конфигурация указывается непосредственно в маршруте.
- Ссылка по ID – когда создается отдельный объект upstream, на который ссылаются через
upstream_id
.
Эти два подхода являются взаимоисключающими – нельзя одновременно использовать их в одном маршруте.
Принцип DRY в конфигурации плагинов
Большая часть функциональности APISIX реализуется через плагины, и при их настройке тоже важно следовать принципу DRY. Предположим, нужно реализовать версионирование API на основе пути. Для этого нужно переписать URI перед его отправкой:
![🪶 Как следовать принципу DRY при настройке Apache APISIX](https://media.proglib.io/posts/2024/09/23/17921d97fbc8edb4f042e808533eac80.png)
Здесь есть что оптимизировать – операция по удалению префикса дублируется. Дубликацию можно исправить, если вынести обработку URI в отдельный объект plugin_configs
:
![🪶 Как следовать принципу DRY при настройке Apache APISIX](https://media.proglib.io/posts/2024/09/23/15d94932fcc37c10dac2390a2cba9f8f.png)
В отличие от upstream
и upstream_id
, настройки plugins
и plugin_config_id
не являются взаимоисключающими – напротив, APISIX предусматривает их одновременное использование для разделения общих настроек и специфических для конкретного маршрута. При этом конфигурация плагина в маршруте имеет приоритет над конфигурацией в plugin_config_id
. Например, при работе с плагином key-auth можно задать переменную apikey на уровне потребителя, но изменить ее значение для конкретного маршрута.
Комментарии