#java #spring #rabbitmq #microservices
#java #spring #rabbitmq #микросервисы
Вопрос:
Я создаю приложение, которое состоит из нескольких микросервисов. Один из микросервисов, который называется Hera, управляет пользователями. Другой микросервис управляет авторизацией и аутентификацией. Этот микросервис называется Zeus и является реализацией Spring OAuth 2.0.
Когда пользователь создается, обновляется или удаляется в Hera, я хотел бы скопировать определенную информацию в Zeus через RabbitMQ. Эта информация включает имя пользователя, тип пользователя (перечисление) и флаг, указывающий, включен ли пользователь.
Я уже настроил RabbitMQ, и все работает должным образом. Единственное, в чем я не уверен, это в содержимом тела сообщения. Как эта информация должна быть упакована в сообщении? Например, должен ли я создать проект maven, содержащий POJO с требуемыми свойствами, которые будут упорядочены и отправлены через RabbitMQ, и добавить зависимость к этому проекту как в Hera, так и в Zeus? Или я должен просто добавить эту информацию в виде списка простых свойств?
Я не смог найти никаких рекомендаций по этому вопросу, поэтому я спрашиваю вас.
Заранее благодарю вас!
Ответ №1:
Я бы использовал общую библиотеку для DTO, но вам нужна сериализация, которая является терпимой и допускает различия в версиях, например, обрабатывать добавленные / удаленные поля или изменение типов данных. Если вы предоставляете общий доступ к коду, вы должны разрешить запуск разных версий кода в каждой службе, чтобы при обновлении одной службы вам не приходилось обновлять какую-либо другую.
Ответ №2:
Я думаю, что пользовательский объект в Hera и пользовательский объект в Zeus указывают на один и тот же идентификатор, но они разные объекты и должны быть реализованы в каждой службе в соответствии с потребностями службы.
Общая библиотека требует повторного использования ВСЕХ служб, которые зависят от нее. Если вы захотите сохранить некоторую дополнительную информацию в Hera (в новом поле), вам придется повторно развернуть Zeus или начать работать с разными версиями библиотеки (что снова приведет вас к двум разным объектам).
Ответ №3:
Я предлагаю вам использовать POJO JSON GSON следующим образом:
POJO (DTO) -> Сериализовать в JSON (используя GSON) -> Передать его через посредник сообщений (RabbitMQ) -> Десериализовать его (используя GSON) -> Снова получить POJO (DTO) и использовать его.
Этот подход распространен, когда вы используете Event sourcing CQRS и когда вы хотите придерживаться теоремы CAP и использовать BASE вместо ACID (ACID невозможно реализовать в системах распространения)