Динамическая маршрутизация запроса в микросервисах | OTUS
⚡Подписка от OTUS!
Собери свой пул курсов на выгодных условиях. Подробности в чате →
Написать в чат

Курсы

Программирование
Unity Game Developer. Basic
-15%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Разработчик C#
-8%
Алгоритмы и структуры данных
-8%
Backend-разработчик на PHP
-8%
JavaScript Developer. Professional
-9%
iOS Developer. Professional
-8%
Базы данных
-12%
C# ASP.NET Core разработчик
-6%
Python Developer. Basic
-10%
Java Developer. Professional Web-разработчик на Python Android Developer. Basic PostgreSQL Software Architect Reverse-Engineering. Professional Kotlin Backend Developer React.js Developer VOIP инженер Нереляционные базы данных Scala-разработчик Супер-практикум по использованию и настройке GIT IoT-разработчик JavaScript Developer. Basic Advanced Fullstack JavaScript developer Unity Game Developer. Professional Супер-интенсив Azure
Инфраструктура
Супер-интенсив "Версионирование и командная работа с помощью Git"
-30%
Administrator Linux. Professional
-5%
Супер-интенсив «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Administrator Linux. Advanced
-8%
Infrastructure as a code in Ansible
-12%
Network engineer
-4%
MS SQL Server Developer
-8%
Cloud Solution Architecture Highload Architect Разработчик голосовых ассистентов и чат-ботов Мониторинг и логирование: Zabbix, Prometheus, ELK Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Архитектор сетей Супер-интенсив «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Динамическая маршрутизация запроса в микросервисах

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

Разумеется, каждый сервис из числа сервисов, с которыми мы желаем иметь возможность динамической маршрутизации, должен включать в себя некую метаинформацию с данными, по которым можно будет определить, нужный это сервис либо нет. Spring Cloud (в случае с Eureka), к примеру, дает возможность это сделать путем указания в специальном блоке метаданных в application.yml:

Screenshot_1-1801-2fccd0.png

После того, как такой сервис будет зарегистрирован в Service Discovery, в его com.netflix.appinfo.InstanceInfo#getMetadata появится метка с ключом service.label и значением develop (ее можно получить в runtime). Следует отметить, что важное значение на этапе старта сервиса имеет проверка того, существует ли в Service Discovery инстанс сервиса с данной метаинформацией либо нет — это позволит избежать потенциальных коллизий.

Каковы варианты маршрутизации?

В продолжение разговора скажем, что решение задачи можно, по сути, свести к 2-м вариантам: 1. API Gateway с поддержкой динамической маршрутизации запроса на необходимый сервис. В данном случае клиент должен будет посылать некий признак, который будет определять, что этот запрос должен быть маршрутизирован на необходимый нам сервис, к примеру, в Headers: DestionationService: feature/PRJ-001. У этого подхода есть недостаток: на стороне клиента должна быть логика, причем эта логика при попытке обращения к необходимому сервису должна проставлять соответствующий Header — это надо для возможности выбора необходимого сервиса из имеющегося пула. Есть и достоинство: точка входа будет одна, то есть можно говорить об одном-единственном API Gateway. 2. Поднятие группы API Gateway, причем каждый из интерфейсов станет отвечать за определённый маршрут. К примеру, на картинке внизу запрос, который станет идти через Zuul 1, при попытке запроса endpoint-а типа /api/users/… всегда будет отправлен на инстанс сервиса user, где в метадате находится feature/PRJ-001. Что касается запроса через Zuul 2, то при попытке запроса endpoint-а типа /api/users/… он всегда будет отправляться на инстанс сервиса user, где в метадате лежит feature/PRJ-002. Плюс подхода — можно иметь связку из N API Gateway и N сервисов, следовательно, появляется возможность распараллелить работу нескольких фронтенд- и бэкенд-разработчиков, ведь каждая feature — это, по большему счету, отдельная связка, которая существует изолированно друг от друга и не вносит коллизий для иных участников команды, в отличие от ситуации, когда нужно ждать свою очередь, заливая изменения поочередно в контур. Недостаток — большое число API Gateway. Но если вспомнить, что он относительно легковесный, а главной задачей является просто маршрутизация, то можно сказать, что подход, в целом, вполне себе жизнеспособен.

Схему диспетчеризации запроса можно посмотреть на картинке ниже: Ris_Shema_dispetcherizacii_1_1-1801-2e58d4.jpg

Источник

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться