Передача объектов между микросервисами
Я экспериментирую с перемещением некоторых частей монолита во внешние службы. Пока что мне нравится эта идея, и кажется, что гораздо удобнее заключить все связанные функции в одно приложение. Различные приложения используют RabbitMQ для общения.
У меня есть объект пользователя в одном сервисе. Если я хочу использовать этот же класс в сервисе, я могу легко его сериализовать и отправить сериализованный объект в теле сообщения. Но так как и отправитель, и получатель должны содержать пользовательский класс, я должен был бы поделиться библиотекой, содержащей некоторое представление пользовательского объекта (хотя мне кажется странным помещать реальный пользовательский объект в библиотеку, так как это ядро для основного приложения ). Я думаю, я мог бы также передать массив с user ключ и определенные ключевые значения.
Я также думаю, что если когда-нибудь я создам сервис в чем-то отличном от PHP, он не сможет десериализовать объект пользователя и, следовательно, не будет иметь доступа к данным в сообщении.
Поэтому в целом мне нравится идея передачи сущностей между службами и возможность использовать их как объекты на принимающей стороне, но я не уверен, что это правильный подход.
Мой вопрос: каким будет лучший способ передачи объектов между этими службами?
Решение
Прежде всего, ИМХО, вам НЕ следует делить эти доменные объекты между вашими микросервисами с помощью jar. На самом деле вы не должны делиться своими объектами домена в любом случае. Это может сделать обслуживание и процесс развертывания кошмаром для вас. Вместо этого вы можете иметь вид объектов передачи данных (DTO) в ваших микросервисах.
Лучшим портативным и здоровым способом общения может быть использование некоторого совместимого механизма сериализации, такого как использование json или xml.
И, наконец, микросервисами может быть сложно управлять в долгосрочной перспективе, если вам это действительно не нужно. Поэтому использовать его только потому, что он звучит чище, может быть не очень хорошая идея. Конечно, если у вас сложный и масштабный проект, вы можете пойти на это.
Другие решения
Других решений пока нет …