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

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

  

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

  

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

  

Также я понятия малейшего не имею о том, как все это унифицировать, как избежать лишней проверки на новость в интерфейсе бота, когда парсер уже все проверил. Может как-нибудь отслеживать появляющуюся запись в редисе? 

 Не нужно смешивать все вопросы в кучу. Отвечаю на вопрос в заголовке.  

  

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

  

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

  

Вариант А (простой).  

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

cron-задача по очистке неактуальных записей.  

Телеграм-бот, читающий с СУБД подготовленную информацию.  

  

Вариант Б (сложнее).  

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

Процесс-демон парсера страниц. Занимается обработкой сообщений из очереди с контентом страниц, извлекает нужный контент и кладет в СУБД (upsert).  

cron-задача по очистке неактуальных записей.  

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

Телеграм-бот обращается к REST API за получением информации и других действий.  

  

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

  

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

<https://github.com/micro/go-micro>  

  

<https://github.com/go-kit/kit>