Комментарии 5
Как вы защищаете клиентов (game-service, user-service). Разве у них не открытый порт?
Через Spring Security. Посмотрите раздел «Класс конфигурации Reactive Spring Boot Security MicroserviceSpringSecurityWebFluxConfig.java».
В микросервисы импортирующие этот конфиг приходит JWT токен, который проверяется в фильтре MicroserviceServiceJwtAuthWebFilter и на основе authorities находящихся в токене происходит авторизация внутри данного микросервиса.

В моем примере в docker-compose.yml порты открыты, но это было сделано для удобства. Вы можете не открывать порты этих сервисов, а оставить видным наружу только gateway-server.
Отличная статья. Сам недавно только начал вариться в инфраструктуре Spring cloud. Возник вопрос по metadata-map. Насколько это безопасно шарить между всеми discovery клиентами эти данные с username/password? С одной стороны я могу понять, что эти данные нужны для admin-server, чтобы он мог брать данные со всех подключенных сервисов. Но непонятно тогда для чего эти данные другим клиентам и собственно для чего сам admin-server шарит свои пароли?
Если вы говорите про эти пароли Actuator'а, то это необходимо, чтобы admin-server мог забирать у discovery-clients данные и мониторить их. admin-service шарит свой spring.secruity.user.password для тех же целей, чтобы он мог мониторить сам себя и он автоматически определяет сервисы, которые надо мониторить через discovery-service.

Я сегодня обновил пример, а то на предыдущей машине работало, а на этой не работал.
Вроде бы основные моменты понял, благодарю.
Единственное что мне все еще не дает покоя это gateway.
Многие в гайдах напрямую с gateway проксируют запросы в те же user/game сервисы, хотя как по мне это такое себе решение, ведь формат сообщений с этих двух сервисов совсем может быть не подготовлен для отдачи для фронта, либо придется слать несколько запросов в разные сервисы дабы мерджить результат в случае сложного запроса.
Здесь я уже увидел webapi-service, gateway проксирует только к нему. По сути то что я расписал выше решается именно в webapi. Но тогда ведь полностью теряется смысл в gateway, ведь все эти обязанности мы же можем возложить на webapi, в котором уже будут использоваться клиенты для других наших сервисов.
Единственный какой кейс в этом случае я вижу, чтобы gateway разрешить все же ходить не только к webapi, но и к другим сервисам (разумеется открывавать не все роуты, а там, где не требуется тот же мердж результата, либо формат данных подходит для конкретного запроса).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.