@ruslanfedoseenko
С++/C# разработчик

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

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

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

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

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

Какие есть еще варианты для правильной организации управления подобными данными?
  • Вопрос задан
  • 292 просмотра
Пригласить эксперта
Ответы на вопрос 3
Griboks
@Griboks
1. Все данные хранятся в одной базе.
2. У базы есть система управления с API. В случае изменения схемы, вы меняете устройство API, но не его внешний интерфейс.
3. Все потребители и генераторы данных используют это общее API. Используют гибко, например, через GraphQL. (Лично мне не хватает его гибкости, я написал своё.) В случае изменения микросервиса, переписывается запрос, а не API.
Ответ написан
Sanes
@Sanes
!
На запись должна быть одна база. На чтение можете сделать репликацию.
Соответстенно по этой схеме каждый сервис, который может работать относительно самостоятельно.

У новостного сайта например могут быть:
  1. Пользователи
  2. Статьи
  3. Комментарии
  4. Баннеры

Любой из этих списков может быть разделён на дополнительные сервисы, чтение/запись.
Итого, вы должны максимально безболезненно пережить отказ мастер сервера (запись) любого из модулей.
Ответ написан
2ord
@2ord
продвинутый чайник
Каждому микро-сервису необходима разная информация по фильму.
Возможно, через брокер сообщений нужно отправлять достаточное количество информации, необходимой для работы каждого сервиса. Тогда не нужно обращаться за данными к другому.

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы