Микросервисы межсвязи-как?
Я работаю над проектом personnal, который заключается в преобразовании монолитного веб-приложения в микрослужбы (каждая служба имеет свою собственную базу данных).
В этот момент монолитный бэкэнд выполнен с NodeJS и способен отвечать на запрос REST. Когда я начал разбивать приложение на несколько сервисов, я столкнулся со следующей проблемой : как сделать общение между ними приятным ?
Сначала я попытался использовать вызов REST в следующем примере : "Служба Регистрации" вставляет интересные вещи в свою базу данных, а затем пересылает (HTTP POST) информацию о пользователе в "Службу пользователей", чтобы сохранить ее в базе данных "пользователя". Из этого примера у нас есть 2 службы, таким образом, 2 базы данных.
В этот момент я понял, что это не лучший выбор . Потому что моя "служба регистрации" зависит от "службы пользователя". Они как бы связаны, и это анти-паттерн концепции микросервисов (из того, о чем я читал ).
Второй идеей было использовать брокер сообщений , как RabbitMQ. "Register Service" по-прежнему вставляет интересные вещи в свою собственную базу данных и публикует сообщение в очереди с пользовательской информацией в качестве данных. "Служба пользователей" использует это сообщение и сохраняет данные в своей базе данных "пользователей". Используя эту концепцию, обе службы полностью изолированы и могут быть отличной идеей.
Но, Как насчет ответа, чтобы отправить клиенту (который сделал запрос на "регистрацию сервиса"). С первой мыслью мы мог бы послать "200, все в порядке !- или 400. Это не проблема. Вторая идея заключается в том, что мы не знаем, сохранил ли потребитель ("пользовательская служба") пользовательские данные, поэтому что мне нужно ответить клиенту ?
У меня та же проблема с магазинной стороной веб-приложения. Клиент размещает товар, который он хочет купить, в разделе "заказать услугу". Этот человек должен проверить виртуальные деньги, которые у него есть, на "обслуживание пользователя", а затем переслать деталь продукта на "обслуживание доставки", если у пользователя есть достаточно денег. Как это сделать с полностью изолированными службами ?
Я не хочу использовать время http-запроса от клиента, чтобы сделать асинхронный запрос / ответ на брокере сообщений.
Я надеюсь, что некоторые из вас просветят меня.2 ответа:
Том предложилдовольно хорошую ссылку , где лучший ответ с его аргументацией и решением-это тот, на который вы можете положиться. Ваша специфическая проблема может корениться в том, что Служба регистрации и Служба пользователей являются отдельными. Может быть, их и не должно быть?
В идеале, служба регистрации должна публиковать событие" UserRegistered " в шине и возвращать 200 и ничего больше. Он вообще не должен заботиться (знать) о каких-либо подписчиках на это событие.
Спасибо за эту ссылку,
Мои проблемы превращают архитектуру, которая у меня есть, в новую. Для людей, у которых есть те же проблемы, что и у меня, есть вещи, которые я сделал благодаря этой ссылке:
Объедините службу регистрации и Службу пользователей. Почему? Потому что все зависит от информации пользователя ( те же требования к базе данных), что и решение IlliakaillI.
Разделите управление деньгами пользователя на "кошелек", который существует только в "Заказывать услуги". Благодаря этому нам не нужно получать информацию о пользователе при выполнении заказа, нам просто нужно проверить информацию о кошельке. (Я закодировал имя пользователя в JWT, когда пользователь выполняет аутентификацию. Таким образом, я могу использовать в своем кошельке имя пользователя в качестве внешнего ключа, чтобы узнать, какой кошелек поставляется или используется и т. д.)
Как вы можете видеть, я больше не использую брокера сообщений, потому что сейчас он мне не нужен. Но я могу разделить логику рассылки на новую микросервисы, а затем использовать брокер сообщений для отправки почты через все мои микросервисы, если это необходимо.
Скажи мне, если я ошибаюсь, но для меня это звучит здорово.