209 похожих чатов

Всем привет, кто шарит, сориентируйте пожалуйста по поводу флоу регистрации

в микросервисах. Правильно ли использовать такой подход?
1. Пользователь c клиента отправляет запрос на регистрацию, его перехватывает API gateway и бросает команду на регистрацию пользователя в очередь RabbitMQ (AUTH_QUEUE) (на самом деле в Exchange, но для упрощения скажем, что в очередь).
2. Consumer Auth MS читает команду из очереди AUTH_QUEUE на регистрацию пользователя и отправляет команду на создание нового пользователя в RabbitMQ.
3. Consumer User MS читает команду на создание пользователя, создает его и возвращает результат.
4. По цепочке return-ов созданный пользователь возвращается обратно в контроллер ApiGateway.

6 ответов

12 просмотров

А зачем два микросервиса?

Andrew- Автор вопроса
⁤ ⁤
А зачем два микросервиса?

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

Andrew
потому что у них роли разные, в теории микросервис...

так и оставь кучу всего в юзер сервисе, а в ауф сервисе сделай таблицу с пользователями чисто для регистрации и логина, потом в юзер сервисе просто имей ссылку в виде id пользователя в ауф сервисе

Andrew
потому что у них роли разные, в теории микросервис...

Не нужно на каждый пук плодить микросервис, это не декомпозиция а усложнение логики. Если точно не знаешь зачем создавать мс - не создавай

Vadim a.k.a Masta
Распределённый монолит? :))

монолит это когда две логические разные сущности в одном проекте используются получается?

Похожие вопросы

Обсуждают сегодня

Карта сайта