Микросервисы как выводить общий профиль?

Question

[Максим]

Всем привет!

Хотел бы спросить как реализуется общий профиль в микросервисах.

У меня есть несколько сервисов одного приложения. Пример двух:

user - служит для аутентификации и единого аккаунта.
event - служит для работы с мероприятиями.

В event есть свои сущности. Сущности, естественно никак не связаны ни в базе, ни в коде другими сервисами. Сущности в event имеют только ссылку по user_id на сервис user.

Пример

- id
- user_id
- first_name
- last_name
- city

И теперь возникает вопрос... Как выводить общий профиль и фотографию в микросервисе event. При условии того, что они должны быть оба независимы?

Пример того, что я имею ввиду можно посмотреть на всем известную платформу Яндекс. У яндекса есть passport где хранятся данные профиля и аватарка. А так же есть другие сервисы: Яндекс такси, Яндекс отзывы...

Соотвественно в яндекс отзывах выводится информация из профиля-сервиса passport: аватарка и фио. Я понимаю так, что имя и фамилия просто копируется из passport в сервис отзывы в свою сущность. Но как поступить с аватаркой?

И ещё вопрос. Как использовать единую систему городов? У всех сущностей нужны города. С точки зрения нормализации их лучше выделить в отдельные таблицы и ссылаться на них. Но тогда опять приходим к связанности. Получается в каждый сервис нужно реализовывать свои города?

Answer 1

[rPman]

Фраза 'выводится' - это значит у вас есть методы, которые занимаются преобразованием данных объектов в представление (html например), это либо часть сущностей user/event/.. (т.е. каждая сущность умеет себя выставлять на показ) либо отдельная сущность, которая знает про все существующие и умеет их рисовать.

Собственно это ответ на ваш вопрос - ваша реализация будет гулять между этими крайностями.

Но когда речь идет об использовании данных, т.е. если вдруг для работы одной сущности нужна часть данных из другой, т.е. к примеру event должен знать дату рождения пользователя чтобы уметь добавлять ДР в календарь, то либо вы должны создать некую абстрактную сущность-посредник, умеющий выдавать дополнительные даты для календаря и знающий откуда их можно брать (и про user и имеющий методы, о которых знает event), либо забить связь между сущностями в код (прописать методы дат у user и напрямую запрашивать, т.е. в методе user необходимо прописать доступ к объектам типа user, точнее класс потом к для всех видов user).

Comments

[Максим]

Я понимаю, что нужно использовать абстракцию между модулями и этим пользуюсь. Для отрисовки использую либо viewModel либо саму сущность. Но дело не в этом.

Как запрашивать данные из user мне понятно. Примерно так же, скорее всего, связывать города.

Это можно делать и без абстракции используя голый SQL запрос который записываем во viewModel. Но речь идёт больше об аватарке. Если посмотреть на яндекс - аватарка там едина во всех сервисах.

Каким образом это осуществить? Предполагаю что нужно сохранять в одно место по id user и доставать во всех сервисах по user_id

[rPman]

Я не понимаю ваше непонимание
Аватарка - это картинка, картинку можно выдавать статично по url, эту ссылку брать у user из соответствующего поля или по идентификатору (лучше поле, чтобы при смене аватара менялась ссылка).

Организация структур внутри проекта максимум определяет, как именно и кто должен делать это запрос в базу данных. user или все кому не лень.

Если не заводить абстракции, то при модификации user придется лезть и править все места, откуда лезут к этим данным, что для крупных проектов обычно фатально. Поэтому городите абстракции, но не переборщите, чтобы не получилось работать ради работы.

[Максим]

rPman, а как бороться в цикле с запросами к user? На каждый вывод сущности будет запрос к user. Кроме того я, скорее всего, данные буду получать через api

[rPman]

а как бороться в цикле с запросами к user?

научите вашу абстракцию делать запросы сразу по нескольким объектам, т.е. у вас должен быть метод, кушающий список идентификаторов - таким образом вы позволите бакэнду оптимизировать и делать только 1 запрос.

[Максим]

rPman, вот так и думаю делать. Обсуждали ниже это же

Answer 2

[grinat]

Шо то не улавливаю проблемы, евент тупо через рест/grpc получает данные и их отображает, тоже с городами.

Comments

[Максим]

Проблема в отражении участников событии, а именно общего аватара. Как с ним быть? Аватар пока будет единый. Единый аватар будет создаваться в user, но аватар может выводиться во всех сервисах: мероприятия, блог, магазин, отзывы... соотвественно у этих микросервисов будут свои сущности-профили, в которых нужно будет выводить общий аватар. Пример Gavatar. Но им пользоваться не хочу.

[grinat]

Максим, не понимаю, что им всем мешает делать get http://user-service/profile/<id> и получать всю инфу включая аватар.

[Максим]

grinat, так в цикле будет куча запросов

[grinat]

Максим, ну если так страшно, то сделай батс метод

get http://user-service/profiles?id[]=<id>&id[]=<id>

[Максим]

grinat, ну как вариант, да. А если все аватарки записывать папку avatars и уже от туда доставать по www.site.ru/avatars/1.jpg

Где 1 = user_id

Хотя тут вопрос с форматом) Если формат один проблем нет. А если png, то проблем чуть больше)

[grinat]

Максим, если это user-service возвращает в поле avatarUrl, то пофиг. Если так другие дергать будут в обход user service то идея говно.

[Максим]

grinat, тоже так думаю. Хлипкая картина будет. Думаю, что все таки пока api лучше. Правильно предлагаете. Подожду ещё комментариев и критики. Если не будет идей, то так и поступлю.