Микросервисная архитектура моделей общих доменов

Предположим, у нас есть приложение Spring Boot, которое использует архитектуру микросервисов. Каждая из служб имеет свои собственные доменные модели, но каждая служба должна ссылаться на объект домена пользователя. Каков наилучший подход к решению этой проблемы? Было бы лучше, если бы у каждой службы был просто идентификатор пользователя, а затем, при необходимости, запрашивать у пользователя информацию о пользователе или лучше иметь библиотеку общего домена для всех микросервисов?

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

Общая архитектура

Я думаю, что лучшим подходом будет:

• иметь микросервис для общего управления информацией пользователя;
• хранить информацию о конкретном микросервисе пользователя (например, профили, полномочия, предпочтения) в каждом микросервисе (используя референс общего идентификатора)

Дополнительное чтение:

• Эта статья очень хорошо описывает этот вид архитектуры и обоснование, с конкретным случаем авторизации.
• В этой статье описываются проблемы и решения для управления идентификацией пользователей, чтобы избежать доступа всех служб к одному и тому же хранилищу.
• В этой статье описывается, как использовать JWT для передачи идентификатора пользователя между сервисами (отмечая, что некоторая базовая информация может быть предоставлена ​​в токене id, что позволяет избежать необходимости запрашивать сервис пользователя еще раз после входа в систему, по крайней мере, для очень простых Информация).

Совместное использование кода

Теперь, если вы согласны с решением, описанным выше, у нас есть микросервис пользователя (модель инкапсуляции домена для пользователя), а все остальные сервисы являются потребителями того же микросервиса. Вопрос в том, чтобы узнать, хотите ли вы:

• либо каждый микросервис заново изобретает код потребителя, следуя догме сильного разделения для обеспечения гибких и четких циклов выпуска,
• или разделить код потребителя как часть библиотеки, учитывая, что эта фундаментальная информация является расширением шаблона инфраструктуры «шасси» .

Я не буду занимать четкую позицию по этому вопросу, поскольку по этой теме обмена кодами ведутся противоречивые мнения, и я не думаю, что могу занять объективную позицию. Вот уже некоторые дополнительные чтения:

• Эта статья думает, что нет лучшего решения, и все зависит от ваших целей
• Эта позиция статьи заключается в том, что совместное использование кода плохо, только если оно создает сильную связь, а совместное использование кода может принести некоторую синергию
• Эта статья (людей, которые внедрили микросервисы в масштабе) настаивают на необходимости иметь отдельные сборки и потенциальных проблем вывода из эксплуатации старого кода. Наличие общей библиотеки для использования с надежным управлением версиями не предотвращает эти хорошие практики.

Мое собственное мнение по этому поводу состоит в том, что вы НЕ ДОЛЖНЫ ДЕЛИТЬСЯ кодом между пользователем-поставщиком и пользователями-потребителями, чтобы избежать тесной связи. Однако вы МОЖЕТЕ ОБМЕНИТЬ пользовательский код потребления между потребителями, если у вас есть надежное управление версиями. Этот подход будет иметь некоторые преимущества:

• Разные пользовательские микросервисы могут быть созданы с использованием разных версий общего кода пользовательского потребления (при условии, что версии совместимы с независимым поставщиком-пользователем). Та же самая гибкость, что и изобретение колеса, но более высокая производительность.
• Вы можете изменить свой сервис-провайдер самостоятельно, не влияя на потребителей.
• Если ошибка обнаружена на стороне потребления, вы можете исправить ее один раз и развернуть всех потребителей как можно лучше (благодаря управлению версиями). Это может даже привести к повышению качества обслуживания.
• Если по какой-либо причине вы обязаны обновить API пользовательского провайдера, вы можете развернуть обновленное пользовательское потребление более быстро. Если вы сохраняете активными старый и новый сервис провайдера, такая возможность совместного использования может позволить быстрее выводить из эксплуатации старую версию потребителя-провайдера.

Я бы избегал разделяемой библиотеки, если это вообще возможно. Спросите себя, какие свойства пользователя нужны каждому сервису? Часто существует основной домен, в котором будет жить большая часть поведения, окружающего пользователя, причем поддерживающим доменам часто нужен только идентификатор пользователя.

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