@Molex20021

Как лучше реализовать данную архитектуру?

Хочу написать свой агрегатор контента на go. Архитектурная идея состоит в следующем: при запросе к серверу от конкретного пользователя включается python скрипт, который парсит контент из источников и обновляет бд, затем пользователю выдаётся результат в виде обновленного контента.

Так вот, как такое можно реализовать? А именно, как запускать python скрипт при запросе по выдаче контента?
  • Вопрос задан
  • 133 просмотра
Решения вопроса 1
romesses
@romesses
Backend инженер
Когда пользователь ждет пока агрегатор выполнит свою работу - это нехорошо. Правильнее, чтобы первый захотел некоторый контент и сразу мог получить его, прямиком с БД, а в идеале с кэша частозапрашиваемого контента.
Для этого агрегатору необходимо регулярно выполнять свою работу независимо от посетителей, в фоне. Разумеется, пайплайн агрегатора должен заранее знать откуда заполучать контент или же одноразово получить список источников в начале, пройтись по ним и занести данные в БД. Затем регулярно обновлять с уже известных источников независимо от захода пользователей.

Ну а если в БД пусто и позарез нужно выдать контент, то остается плохой вариант - дать пользователю ждать, пока контент не будет скачан, обработан агрегатором и получен обратно. В данном случае, при попытке получения контента можно выдать сообщение, что мол, "Извините-с-с, заходите чуток позже" или же "Подождите 5 сек, я быстро-быстро". А когда свежий контент уже был обработан, то отправить назад контент по SSE/WebSocket. Или же short polling просто клиент будет периодично выполнять запросы к API с надеждой получить контент.
Вот здесь можно прочесть о способах взаимодействия

Поэтому я вижу такую архитектуру при работе с пользователем:
Client -> API -> cache/DB (read)
             \
              MQ
                 \
               [Aggregator]
                      \
                      DB (write)

Здесь [Aggregator] может означать как монолитный механизм скачивания-обработки, где все в одном, так и микросервисную архитектуру.

По мне, так бизнес-логику на Go писать не очень удобно и ее лучше осуществлять на более высокоуровневых языках. Так что в Go я бы реализовывал механизм скачивания контента и извлечения нужных частей, а в Python/Ruby/Perl и т.д. - логику самого агрегатора (смешение, композитинг контента).
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

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