Обмен огромными данными между микросервисами

Question

Я разрабатываю платформу анализа анализа в архитектуре микросервисов.

Приложение работает, как показано ниже;

• все отзывы о продукции, извлекаемые из электронной коммерции-сайта-а (сайт-а) в качестве файла Excel
• Отзывы загружаются в систему с первенствует
• Анализ агент может перечислить все отзывы, редактировать некоторые из них, удалить или одобрить
• Аналитический агент может экспортировать все обзоры для сайта-a
• Автоматические проверки на основе регулярного выражения применяются для каждого обзора при загрузке и редактировании.

У меня есть 3 микросервиса.

• Отзывы: Ответственные за операции Обзор Crud плюс операций, аналогичных утвердить/отклонить ..
• Validations: Ответственный за определение и применение правил проверки на рассмотрение.
• Экспорт/Импорт: экспорт Экспорт услуг огромные файлы, указанные имя сайта (например, сайт-а)

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

Одним из возможных решений является

• Когда служба проверки требует обзоров для сайта, он запрашивает шлюз, шлюз перенаправляет запрос Отзывы службы и реагирования приняты.

Два возможные недостатки этого подхода является

• служба проверки знает о шлюзе? Это приносит зависимость?
• в случае, если у меня есть 1b обзоров для сайта, получение всех отзывов через запрос на отдых может быть проблемой. (Или нет, я могу сделать запросы от разбитых на страницах службы проверки шлюза ..)

Так что лучшая практика для обмена больших объемов данных между микро-услугами без

• разделения сущности
• и dublicating данные

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

Редактировать 1: Вместо совместного использования объекта, использование хранилищ данных с API для отдыха может быть решением?Предположим, что я использую mongodb вместо совместного использования объекта объекта между микросервисами, я могу использовать интерфейс отдыха mongo (http://restheart.org/) и запрашивать данные, когда это возможно.

Answer 1

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

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

Таким образом, я бы сказал, что ваша цель должна быть потоком. Пусть валидатор запросит все из Обзоров о сайте А, но не в одном объеме, а в потоке отдельных или небольших пакетов обзоров.

Validator теперь может обрабатывать обзоры один за другим, при постоянной памяти и потреблении процессора. Чтобы повысить производительность, вы можете сделать несколько экземпляров Validator, которые одновременно используют разные, разобщенные фрагменты потока. Аналогичным образом, вы можете создать несколько экземпляров микросервиса Reviews, если один из них не сможет ответить достаточно быстро.

Валидатор не поддерживает этот поток, он производит только ошибки и сохраняет или отправляет их где-то; это должно соответствовать вашим требованиям без дублирования без обмена.

Answer 2

Ваша проблема здесь не в разделении огромных данных, а на границах, которые вы выбираете для разделения ваших микросервисов на основе.

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

Я бы посоветовал вам пересмотреть свое дизайнерское решение и рассмотреть «Рецензии» как единый микросервис, который обрабатывает все операции с отзывами и логику как черный ящик.