Пусть микросервисы больше не «теряются»: актуальные фрагменты кода и истории применения API-шлюзов

Вы когда-нибудь сталкивались с такой ситуацией — микросервисов в компании становится все больше, каждый сервис имеет свой интерфейс и адрес, и вызвать его — все равно, что найти выход в лабиринте? На какое-то время сервису A необходимо обратиться к данным B, а на какое-то время C должен найти D для проверки разрешений. Просто поддерживать эти телефонные отношения — головная боль. Не говоря уже о контроле безопасности. Разве каждый сервис не может иметь свой собственный набор средств проверки личности?

Вот почему мы должны поговорить об API-шлюзах.

Представьте себе, что микросервисная архитектура — это оживленная вечеринка, а API-шлюз — это секретарша у двери. Он отвечает за проверку списка приглашенных (проверка личности), направление гостей в нужную комнату (запрос маршрутизации), контроль ритма входа (ограничение тока) и запись тех, кто приходит и кто уходит (мониторинг журнала). Без этого партия может легко погрузиться в хаос.

Как это выглядит в коде?

Простой пример конфигурации маршрутизации шлюза

Предполагая, что вы используете Spring Cloud Gateway (который довольно распространен в экосистеме Java), базовая конфигурация маршрутизации может выглядеть следующим образом:

@Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("product_service", r -> r .path("/api/products/**") .filters(f -> f .addRequestHeader("X-Request-Source", "gateway") .circuitBreaker(config -> config .setName("productCB") .setFallbackUri("forward:/fallback/product"))) .uri("lb://PRODUCT-SERVICE")) .route("order_service", r -> r .path("/api/orders/**") .uri("lb://ORDER-SERVICE")) .build(); }

Что делает этот код? Он сообщает шлюзу: все запросы, начинающиеся с /api/products/, перенаправляются в службу с именем PRODUCT-SERVICE. Кстати, добавляется заголовок запроса, и настраиваются автоматические выключатели и понижения версии — в случае, если служба продукта временно не сможет ответить, она будет переведена в резервный план. Маршрутизация службы заказов проще и перенаправляется напрямую.

Видите ли, всего лишь с помощью нескольких строк внешним абонентам не нужно знать, сколько существует микросервисов и на каком IP-адресе они находятся. Им нужно только обратиться к шлюзу.

Преимущества реальны

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

Например, безопасность. Вместо многократной реализации проверки JWT в каждой службе позвольте шлюзу обрабатывать ее единообразно:

# Пример конфигурации фильтров шлюза: - name: JwtAuthFilter args: secretKey: "ваш-секретный-ключ-здесь" ignorePaths: - "/api/public/login" - "/health"

Теперь, за исключением двух общедоступных интерфейсов входа в систему и проверки работоспособности, все остальные запросы должны сначала пройти проверку токена. Если вы хотите изменить правила проверки, вам нужно изменить только это место.

Другой пример — мониторинг. Когда весь трафик проходит через шлюз, у вас внезапно появляется идеальная точка наблюдения. Какие интерфейсы вызываются чаще всего? Каково среднее время ответа? Есть ли какие-либо отклонения в частоте ошибок? Эти данные собираются на уровне шлюза, что гораздо удобнее, чем обращаться к каждому сервису за получением логов.

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

На что следует обратить внимание при выборе?

На рынке существует множество вариантов шлюзов API. Как выбрать? Я не думаю, что нужно гнаться за максимально полными функциями. Ключевым моментом является то, удобны ли эти вещи:

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

Также важна его совместимость с существующим стеком технологий. Если ваши микросервисы в основном написаны на Go, возможно, более практично выбрать шлюз, дружественный к Go и имеющий хорошую поддержку сообщества.

Некоторые соображения во время фактического развертывания

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

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

Ведение журнала также необходимо тщательно планировать. Какие журналы должен вести шлюз? Слишком много повлияет на производительность, слишком малое будет вредно для устранения неполадок. Обычно метаданные запроса и ответа (время, путь, код состояния, IP-адрес клиента) необходимы, но для потенциально большого контента, такого как тело запроса, вам нужно тщательно выбирать, возможно, записывать только тело запроса определенного пути или только выборку записи.

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

Будьте честны

Микросервисная архитектура подобна палке о двух концах. Разделение его на небольшие сервисы делает разработку и развертывание более гибкими, но также увеличивает сложность управления. Шлюз API — это своего рода «стойка регистрации» этой сложной системы. Он не занимается основной деятельностью, но без него всей системе будет трудно нормально работать.

Начав с нескольких строк конфигурации маршрутизации и постепенно добавляя возможности безопасности, мониторинга и ограничения тока, вы обнаружите, что роль «секретаря» становится все более и более важной. Это позволяет серверным службам делать то, что они умеют лучше всего, без необходимости решать сквозные проблемы.

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода.мощностьпредоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.