Сохранение идентификаторов REST API в другом микросервисе
Является ли хорошей практикой сохранение идентификатора пользователя в микросервисе заказов (то есть в базе данных, поддерживающей микросервис)? (или, в общем случае, ID объекта, управляемого микросервисом, в другом микросервисе)
Если бы это было не так, то вы бы просто не смогли связать два ресурса, которые происходят из разных микросервисов.
Хорошо, что вы уже сосредоточились на идентификаторе пользователя, а не на всех его данных, потому что именно таким является подход по умолчанию для микросервисов. Вы храните только ссылку на ресурс в других микросервисах. Фактические данные остаются в "домашнем" микросервисе, а другие микросервисы должны запрашивать их (на основе сохраненной ссылки).
Тем не менее, бывают случаи, когда необходимо скопировать некоторые данные, но это зависит от конкретной ситуации и связано с определенными затратами. В качестве базового уровня вы должны стараться избегать таких ситуаций и хранить только ссылки (т.е. идентификаторы), внешние по отношению к "домашнему" микросервису.
Я предполагаю, что должна быть какая-то служба сопоставления, которая, задав email или номер телефона, возвращает идентификатор пользователя для использования в REST-вызовах? Где должна быть открыта эта служба перевода? В микросервисе Users?
Поскольку микросервис Users является единственным сервисом, который хранит данные пользователя, он по своей сути единственный, кто может перевести поле данных в ID. Поэтому да, микросервис Users должен предоставлять конечную точку API для обеспечения этой функциональности.
Будет ли это целевая конечная точка (получить ID пользователя по электронной почте) или широкая (получить пользователей, с множеством возможных фильтров); зависит от того, что имеет наибольший смысл в вашем сценарии.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: