Потребитель триггерных сервисов для повседневных задач — Архитектура

#architecture #microservices

#архитектура #микросервисы

Вопрос:

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

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

Какой наилучший вариант посредника сообщений для наших нужд? Кроме того, это лучшее решение или уже существует лучшая практика для таких нужд?

Ответ №1:

Я бы использовал RabbitMQ для передачи сообщений, если вы хотите управлять им самостоятельно. В противном случае, если вы хотите упростить задачу, вариант, размещенный в облаке (например, SQS), хорошо подходит для таких вариантов использования.

Если я правильно понимаю ваш вариант использования, вы хотите накапливать обзоры в очередях сообщений в течение дня, а в конце дня вы хотите запустить одно задание, которое обрабатывает сообщения и обновляет результаты в БД.

Если имеется огромное количество сообщений, память / диск сервера RabbitMQ могут быть переполнены, или задание, которое выполняет вычисления в конце дня, может занять слишком много времени.

Другим вариантом, который вы можете рассмотреть, было бы хранить обзоры в БД, используя индекс, оптимизированный для запросов диапазона, как в MySQL, чтобы очень быстро собирать данные за 1 день, а затем запускать задание на основе этого.

Кроме того, вы можете рассмотреть более детальный подход, при котором ваш сервис рассчитывает обзоры чаще, чем раз в день (возможно, раз в несколько часов). Это уменьшит количество операций с БД, но также распределит нагрузку на эту работу по всему дню.