Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

4 <h2>Каковы варианты маршрутизации?</h2>

5 В продолжение разговора скажем, что решение задачи можно, по сути, свести к 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. Но если вспомнить, что он относительно легковесный, а главной задачей является просто маршрутизация, то можно сказать, что подход, в целом, вполне себе жизнеспособен.

6 Схему диспетчеризации запроса можно посмотреть на картинке ниже:

7 <a>Источник</a>