Как совместно использовать модели Java между микросервисами в микросервисной архитектуре
Я разрабатываю архитектуру своего нового приложения. Я выбрал микросервисную архитектуру. В своей архитектуре я заметил, что у меня есть модели, которые используются разными микросервисами. Я хочу знать, есть ли способ обмениваться кодом моделей между микросервисами вместо того, чтобы писать их в каждом микросервисе.
Кстати, я использую Spring Boot Framework для своего приложения.
Ответы 6
В архитектуре микросервисов каждый из них абсолютно независим от других и должен скрывать детали внутренней реализации.
Если вы разделяете модель, вы связываете микросервисы и теряете одно из самых больших преимуществ, заключающееся в том, что каждая команда может разрабатывать свой микросервис без ограничений и необходимости знать, как развиваются другие микросервисы. Помните, что вы даже можете использовать разные языки в каждом из них, это будет сложно, если вы начнете соединять микросервисы.
@Lino Если вы специально ищете POJO, упакуйте его в банку и используйте в микросервисе.
@MebinJoe это именно то, о чем я думал. По сути, можно было бы иметь службу аутентификации, которая содержит Account-POJO, который, в свою очередь, предоставляется в общем модуле, который может использоваться другим микросервисом. Однако: авторы микросервиса, который использует сервис авторизации, могут решить реализовать свои собственные POJO или другие структуры, которые будут использоваться для сопоставления JSON-ответа с классом или с потребностями потребляющего сервиса.
Вы можете переместить свои классы моделей в другой проект/репозиторий и добавить их в качестве зависимости к своим микросервисам, которым необходимо поделиться ими.
Если вы сделаете это, вы создадите связь между двумя микросервисами и фактически можете получить монолитное приложение, которое просто имитирует микросервисы.
Вы должны делиться только моделями, которые определяют API вашего микросервиса, например. Файлы Protobuff .proto или сгенерированные из них классы Java.
Обычно это делается путем создания отдельного проекта или преобразования ваших проектов микросервисов в многомодульные проекты, где один из модулей представляет собой тонкий модуль API с определением интерфейса.
Нет ничего плохого в совместном использовании кода между микросервисами, но вы должны быть осторожны. Делитесь слишком большим количеством деталей внутренней реализации, и вы получите распределенный монолит вместо микросервисов.
Вы можете создать отдельный проект с общими моделями, создать банку этого проекта и добавить зависимость этой банки в других микросервисах.
Но у меня есть практический опыт, поддерживать этот общий проект — кошмар, потому что на каждое изменение приходится создавать новую версию и обновлять скрипты сборки всех микросервисов.
На мой взгляд, мы не должны делиться моделями между микросервисами.
Я знаю, что опоздал к этому обсуждению. Но если вы решите не использовать отдельный проект для обработки всех моделей и решите повторно использовать каждую модель в каждом микросервисе, вы столкнетесь с той же проблемой. Когда модель изменяется, вы должны изменить все файлы модели из каждой микрослужбы, что в конечном итоге потребует больше работы, чем просто обновить зависимости для каждой микрослужбы.
@RutgerdeGroen Вы правы. Я думал так же. Дайте мне знать правильный путь, если вы узнали, как поделиться моделями. Пример: список ответов от API микросервиса, который будет использоваться другим микросервисом FeignClient. Не думайте, что создание модели снова в новом микросервисе — хорошая идея.
В итоге я создал частный пакет npm со всеми моделями, которые необходимо было использовать между сервисами. Например, я создал REST API и микросервис GraphQL, используя одни и те же модели данных. Оба они получают доступ к моделям через один пакет npm. Таким образом, вы управляете всеми моделями в одном месте, вам нужно только время от времени обновлять зависимости.
Не уверен, что ваши микросервисы используют Swagger, но вы можете использовать Сваггер Кодеген для создания своих моделей.
Например, если у вас есть UserService, который принимает и/или возвращает объект пользователя. Потребитель UserService может использовать подключаемый модуль Swagger Codegen для автоматического создания класса User во время сборки.
Вы можете легко использовать плагин Swagger Codengen maven или gradle.
Если вы драконовски относитесь к этому решению, вы так или иначе столкнетесь с неудовлетворительными условиями. Это зависит от вашего SDLC и динамики команды. В Ipswitch у нас есть много сервисов, которые все сотрудничают, и есть такие общие концепции, как устройство и монитор. Наличие у каждой службы собственной модели было бы неустойчивым. Мы сделали это в одном случае, и перевод просто создал дополнительную работу и внес дефекты несоответствия. Но вся эта система построена вместе и одной большой командой разработчиков. Так что делиться здесь имеет смысл. Но для предприятия, где у вас есть несколько команд и несколько SDLC для микросервисов, имеет смысл изолировать модели, чтобы избежать связывания. Однако даже в этом случае набор тесно сотрудничающих сервисов, которыми управляет данная команда, безусловно, может совместно использовать модель, если команда принимает риск/выгоду от этого. В этом нет ничего плохого, кроме академического и философского.
Короче говоря, делитесь минимально, но также избегайте ненужной работы для вашей команды.
Ну, микросервисы (обычно) должны взаимодействовать друг с другом, поэтому вы имеют, чтобы выставить API, по крайней мере, и с этим API приходит модель.