Как правильно организовать микросервисную архитектуру средствами языка Golang?
У меня в планах реализовать проект, суть которого будет заключена в двух сервисах. Один - интерфейс телеграм-бота, в нем осуществлены методы отправки сообщения, проверки обновлений и т.д. Второй - сервис парсинга данных с сайта.
Этот сервис также должен отслеживать новости, например: на сайте, публикующем игры, появился новый обзор, парсер считал информацию о нем, осуществил проверку по айдишнику на наличие и в случае, если такого обзора еще нет, сохранил данные о нем, допустим ,в redis (мне посоветовали его для этих целей).
Вот в чем загвоздка: частью совета были слова, относящиеся к тому, что нужно написать сервер. Как я полагаю, http-сервер. Но есть ли в нем надобность? Ведь ничто не мешает просто написать парсер, который будет запущен и в бесконечном цикле проверять наличие записи и в противном случае складывать данные.
Также я понятия малейшего не имею о том, как все это унифицировать, как избежать лишней проверки на новость в интерфейсе бота, когда парсер уже все проверил. Может как-нибудь отслеживать появляющуюся запись в редисе?
В самом вопросе есть уже проблема - сервисная (да хоть нано-сервисная) архитектура не имеет никакого отношения к языку программирования. Это про интерфейсы, контракты и ограничение контекста
Роман Мирр, я реализовывал это разными способами, сохранял в файле айдишник, а потом в потоке сверял, сохранял в базу и т.д и т.п. Но меня интересует наиболее лучший способ организации.
Роман Мирр, что там что там 1 запрос, а sitemap есть далеко не везде. Да, парсинг html дерева немного тратит CPU, но настолько немного, что я на vps за 200 рублей кручу в докере парсеры, которые пробегают страницы в ~100 потоков без каких либо проблем, а cpu не забивается под завязку, упираюсь чисто в лимит канала.
Роман Мирр, даже если нужно проверять обновления сразу на сотнях сайтов, то о ресурсах нет никакого смысла думать - слишком мизерные цифры. Можно начать думать о ресурсах начиная с десятков тысяч страниц, но это все решается очередями и мониторингом доступных ресурсов системы.
Не нужно смешивать все вопросы в кучу. Отвечаю на вопрос в заголовке.
Как правильно - зависит от масштаба проекта. Если он малый, то не нужно распыляться на много сервисов.
В архитектуре описывают задачи сервисов.
Вариант А (простой).
Процесс-демон сканера-парсера сайтов, пишущий в СУБД (реляционную или документо-ориентированную). Обновляет новые страницы. Можно использовать очереди (тот же Redis) для обработки парсинга.
cron-задача по очистке неактуальных записей.
Телеграм-бот, читающий с СУБД подготовленную информацию.
Вариант Б (сложнее).
Процесс-демон сканера сайтов. Занимается сканированием страниц и кладет сообщение в очередь контент страниц. Потенциально держит много соединений со сканируемыми сайтами, обрабатывает ошибки получения страниц и пробует повторно.
Процесс-демон парсера страниц. Занимается обработкой сообщений из очереди с контентом страниц, извлекает нужный контент и кладет в СУБД (upsert).
cron-задача по очистке неактуальных записей.
REST API для обработки запросов от Телеграм-бота, читающий с СУБД подготовленную информацию. Потенциально может потребоваться их большее количество.
Телеграм-бот обращается к REST API за получением информации и других действий.
В этом случае можно масштабировать каждый сервис отдельно, в зависимости от нагрузки. Само собой, вместо Go можно использовать любой подходящий язык XYZ.
Не претендую на правильность. Это больше размышления на тему как можно сделать.
