Как правильно организовать микросервисную архитектуру средствами языка Golang?

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

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

Вот в чем загвоздка: частью совета были слова, относящиеся к тому, что нужно написать сервер. Как я полагаю, http-сервер. Но есть ли в нем надобность? Ведь ничто не мешает просто написать парсер, который будет запущен и в бесконечном цикле проверять наличие записи и в противном случае складывать данные.

Также я понятия малейшего не имею о том, как все это унифицировать, как избежать лишней проверки на новость в интерфейсе бота, когда парсер уже все проверил. Может как-нибудь отслеживать появляющуюся запись в редисе?
  • Вопрос задан
  • 286 просмотров
Решения вопроса 1
2ord
@2ord
продвинутый чайник
Не нужно смешивать все вопросы в кучу. Отвечаю на вопрос в заголовке.

Как правильно - зависит от масштаба проекта. Если он малый, то не нужно распыляться на много сервисов.

В архитектуре описывают задачи сервисов.

Вариант А (простой).
Процесс-демон сканера-парсера сайтов, пишущий в СУБД (реляционную или документо-ориентированную). Обновляет новые страницы. Можно использовать очереди (тот же Redis) для обработки парсинга.
cron-задача по очистке неактуальных записей.
Телеграм-бот, читающий с СУБД подготовленную информацию.

Вариант Б (сложнее).
Процесс-демон сканера сайтов. Занимается сканированием страниц и кладет сообщение в очередь контент страниц. Потенциально держит много соединений со сканируемыми сайтами, обрабатывает ошибки получения страниц и пробует повторно.
Процесс-демон парсера страниц. Занимается обработкой сообщений из очереди с контентом страниц, извлекает нужный контент и кладет в СУБД (upsert).
cron-задача по очистке неактуальных записей.
REST API для обработки запросов от Телеграм-бота, читающий с СУБД подготовленную информацию. Потенциально может потребоваться их большее количество.
Телеграм-бот обращается к REST API за получением информации и других действий.

В этом случае можно масштабировать каждый сервис отдельно, в зависимости от нагрузки. Само собой, вместо Go можно использовать любой подходящий язык XYZ.

Не претендую на правильность. Это больше размышления на тему как можно сделать.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

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