Если вы использовали микросервисы, чтобы получить выгоду от масштабируемости, слабой связи и простой независимой модификации каждого сервиса, вам следует придерживаться его в максимально возможной степени.
Общая архитектура
Я думаю, что лучшим подходом будет:
- иметь микросервис для общего управления информацией пользователя;
- хранить информацию о конкретном микросервисе пользователя (например, профили, полномочия, предпочтения) в каждом микросервисе (используя референс общего идентификатора)
Дополнительное чтение:
- Эта статья очень хорошо описывает этот вид архитектуры и обоснование, с конкретным случаем авторизации.
- В этой статье описываются проблемы и решения для управления идентификацией пользователей, чтобы избежать доступа всех служб к одному и тому же хранилищу.
- В этой статье описывается, как использовать JWT для передачи идентификатора пользователя между сервисами (отмечая, что некоторая базовая информация может быть предоставлена в токене id, что позволяет избежать необходимости запрашивать сервис пользователя еще раз после входа в систему, по крайней мере, для очень простых Информация).
Совместное использование кода
Теперь, если вы согласны с решением, описанным выше, у нас есть микросервис пользователя (модель инкапсуляции домена для пользователя), а все остальные сервисы являются потребителями того же микросервиса. Вопрос в том, чтобы узнать, хотите ли вы:
- либо каждый микросервис заново изобретает код потребителя, следуя догме сильного разделения для обеспечения гибких и четких циклов выпуска,
- или разделить код потребителя как часть библиотеки, учитывая, что эта фундаментальная информация является расширением шаблона инфраструктуры «шасси» .
Я не буду занимать четкую позицию по этому вопросу, поскольку по этой теме обмена кодами ведутся противоречивые мнения, и я не думаю, что могу занять объективную позицию. Вот уже некоторые дополнительные чтения:
- Эта статья думает, что нет лучшего решения, и все зависит от ваших целей
- Эта позиция статьи заключается в том, что совместное использование кода плохо, только если оно создает сильную связь, а совместное использование кода может принести некоторую синергию
- Эта статья (людей, которые внедрили микросервисы в масштабе) настаивают на необходимости иметь отдельные сборки и потенциальных проблем вывода из эксплуатации старого кода. Наличие общей библиотеки для использования с надежным управлением версиями не предотвращает эти хорошие практики.
Мое собственное мнение по этому поводу состоит в том, что вы НЕ ДОЛЖНЫ ДЕЛИТЬСЯ кодом между пользователем-поставщиком и пользователями-потребителями, чтобы избежать тесной связи. Однако вы МОЖЕТЕ ОБМЕНИТЬ пользовательский код потребления между потребителями, если у вас есть надежное управление версиями. Этот подход будет иметь некоторые преимущества:
- Разные пользовательские микросервисы могут быть созданы с использованием разных версий общего кода пользовательского потребления (при условии, что версии совместимы с независимым поставщиком-пользователем). Та же самая гибкость, что и изобретение колеса, но более высокая производительность.
- Вы можете изменить свой сервис-провайдер самостоятельно, не влияя на потребителей.
- Если ошибка обнаружена на стороне потребления, вы можете исправить ее один раз и развернуть всех потребителей как можно лучше (благодаря управлению версиями). Это может даже привести к повышению качества обслуживания.
- Если по какой-либо причине вы обязаны обновить API пользовательского провайдера, вы можете развернуть обновленное пользовательское потребление более быстро. Если вы сохраняете активными старый и новый сервис провайдера, такая возможность совместного использования может позволить быстрее выводить из эксплуатации старую версию потребителя-провайдера.