Динамическая маршрутизация запроса в микросервисах
Под динамической маршрутизацией запроса понимается ситуация, когда API Gateway (Zuul) получает возможность выбора среди нескольких инстансов одного и того же сервиса, необходимого именно нам. Как правило, данную задачу можно решить, если добавить некий предикат, позволяющий на этапе обработки запроса выбрать нужный сервис из общего списка сервисов с таким же именем.
Разумеется, каждый сервис из числа сервисов, с которыми мы желаем иметь возможность динамической маршрутизации, должен включать в себя некую метаинформацию с данными, по которым можно будет определить, нужный это сервис либо нет. Spring Cloud (в случае с Eureka), к примеру, дает возможность это сделать путем указания в специальном блоке метаданных в application.yml:
После того, как такой сервис будет зарегистрирован в 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. Но если вспомнить, что он относительно легковесный, а главной задачей является просто маршрутизация, то можно сказать, что подход, в целом, вполне себе жизнеспособен.
Схему диспетчеризации запроса можно посмотреть на картинке ниже:
