Таблица соединения различных микрослужб

Я все еще пытаюсь разобраться в архитектуре микрослужб.

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

Проблема в том, что предположим, что у нас есть таблица product, которая имеет user_id колонка. Мы хотим сделать поиск продукта, который также возвращает имя пользователя, который создает продукт. Для этого необходимо соединить между столом продукт в товар Микро-услуг и пользователей в таблице пользователей микро-службе. Как вы справляетесь с этим?

3 5
architecture microservices

3 ответа:

Вам придется сделать вызов каждой микросервисе и выполнить соединение вручную или передать соответствующие идентификаторы пользователей каждой службе.

UserMicroservice: 

SELECT * FROM Users WHERE some condition is true

Получить список пользователей обратно, включая их ids.

ProductMicroserivce: 

SELECT * FROM Products WHERE some condition is true AND userId IN (.........)
Таким образом, пользователи и продукты все еще могут находиться в двух разных базах данных, продукты просто должны иметь понятие идентификатора пользователя.

Обратное также можно сделать, ProductMicroserivce: 

SELECT * FROM Products WHERE some condition is true

Извлеките все Затем UserIds вызывают UserMicroservice: 

SELECT * FROM Users WHERE some condition is true AND id IN (.........)
3

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

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

Если у вас, и я понимаю, что это только пример, есть необходимость запрашивать пользователя, подключенного к продуктам, - зачем разделять службу? Ты кончаешь вместо того, чтобы смотреть на то, какие требования предъявляются к данному, как мне кажется, ограниченному контексту, мы разрабатываем сервис для каждой СУБД-сущности.

- Ларс

5

Лучший ответ на такие сценарии-CQRS. Поддерживайте материализованные представления о взаимоотношениях пользователя и продукта. Метериализованные представления могут быть чем угодно, что обеспечивает низкую задержку при чтении, например NoSQL DBs. Всякий раз,когда команда обновляет пользователя или продукт их микросервисами, соответствующие события должны быть сгенерированы и захвачены другой службой, управляющей этим materializedView. Этот сервис будет использоваться для получения интересующего вас запроса. Всегда имейте в виду, архитектура микросервисов верит в конечную последовательность, что, безусловно, не плохо:).Надеюсь, это ответ на ваш вопрос.

1