Правильно ли копировать данные между микросервисами?

Question

[Руслан Федосеенко]

Всем привет.
У нас в проекте используется микро-сервисная архитектура (по крайней мере мы так думаем). Есть приложение по управлению некими сущностями. Для примера возьмем список фильмов. Общение между приложениями происходит как синхронно (HTTP, RPC) так и асинхронном с использованием событий и команд.
Допустим у нас есть микро-сервисы выполняющие следующий функционал:

• API по управлению фильмами
  
• Оплата
  
• Выдача видеопотока
  
• Формирование рекомендаций
  

Каждому микро-сервису необходима разная информация по фильму.
Сейчас у нас сделано так что при создании/изменении/ удалении фильма формируется событие и через брокер сообщений рассылается другим микро-сервисам. Те берут необходимые данные сохраняют в локальную бд и работают с ними. С этим возможна куча проблем в виде несогласованности данных и т. п.

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

Ну и 3 вариант который вижу синхронно запрашивать у API по управлению фильмами.

Какие есть еще варианты для правильной организации управления подобными данными?

Comments

[NewDevLab]

должен быть один источник правды. как и на какой срок вы будете его кешировать и надо ли это, дело ваше.

[Zhainar]

а вам точно нужны микросервисы?

Answer 1

[Griboks]

1. Все данные хранятся в одной базе.
2. У базы есть система управления с API. В случае изменения схемы, вы меняете устройство API, но не его внешний интерфейс.
3. Все потребители и генераторы данных используют это общее API. Используют гибко, например, через GraphQL. (Лично мне не хватает его гибкости, я написал своё.) В случае изменения микросервиса, переписывается запрос, а не API.

Comments

[Everything_is_not_so_bad]

Все данные хранятся в одной базе.

Это верно для монолита, но не для микросервисов.

[Griboks]

Роман Мирр, вы говорите о функциональных микросервисах или о микросервисах хранения данных?

Answer 2

[Sanes]

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

У новостного сайта например могут быть:

1. Пользователи
   
2. Статьи
   
3. Комментарии
   
4. Баннеры
   

Любой из этих списков может быть разделён на дополнительные сервисы, чтение/запись.
Итого, вы должны максимально безболезненно пережить отказ мастер сервера (запись) любого из модулей.

Answer 3

[Everything_is_not_so_bad]

Каждому микро-сервису необходима разная информация по фильму.

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

Те берут необходимые данные сохраняют в локальную бд и работают с ними. С этим возможна куча проблем в виде несогласованности данных и т. п.

Надо бы прояснить отчего несогласованность и прочие проблемы. Иначе как можно помочь, не зная проблемы?

Паттерн Event Sourcing говорит о том, что все изменения состояния приложения должны быть представлены как последовательность событий.
Я не знаю какой брокер сообщений используете вы, но для возможности реконструировать всю последовательность изменений заново в каждом микросервисе, нужно изначально хранить их в каком-то центральном журнале событий. Apache Kafka весьма подходит для этих целей.
Если не Kafka, то нужно обеспечить возможность отправлять одно и то же событие по нескольким каналам, чтобы каждый из микросервисов смог получить всю необходимую информацию.
Изменения в СУБД должны происходить атомарно, чтобы избежать несогласованности данных.

Шаблон источников событий
https://martinfowler.com/eaaDev/EventSourcing.html
https://microservices.io/patterns/data/event-sourc...

Comments

[Руслан Федосеенко]

Брокер RabbitMQ.
Ну у нас событие автоматом роутятся на всех слушателей.
Несогласованность возникает больше из-за нагрузки. Грубо говоря поменяли цену фильму в копии данных цена не успела обновиться и абонент оплачивает по старой цене.

[Everything_is_not_so_bad]

Руслан Федосеенко, не зная подробностей, не могу помочь.