d'Ivan

Если я верно понял, вопрос о том как сделать так, чтобы можно было слушать gRPC и RabbitMQ с одного сервиса.
Тогда можно в теле main.go

app := NewApp()
app.Start()

в структуре App можно декларировать ссылки на хэндлеры соединений для gRPC, RabbitMQ.

func (a *App) Start() {
  go listenGRPC()
  go listenMQ()
}

Микросервис запустит 2 горутины, каждая из которых будет слушать и обрабатывать свои соединения независимо.

Необходимо, чтобы приложения могли обрабатывать сигнал SIGTERM и по окончанию обработки задачи могли завершиться нормально.

Думаю, при получении сообщений необходимо сохранить в СУБД тело сообщения, id (UUID?), timestamp. При наличии существующего id просто обновить timestamp.
Некоторый сервис может с частотой 1 Гц проверять наличие записей, у которых timestamp подпадает под условие "которое находится в очереди как минимум 10 минут" и всех их отправлять в брокер сообщений и удалять/помечать как удалённые.
Таким образом, обработчики очереди берут из очереди только сообщения, для которых пришло время обработки.
Если темп отправки брокеру сообщений умеренный, нет смысла использовать Kafka. Возможно, достаточно и RabbitMQ. Главное, чтобы очередь не росла и обработчики успевали опустошать её.

Попробуй внешний DNS резолвер https://nip.io/
Тогда нигде и ничего не нужно будет прописывать, а только обращаться к сервису по адресу типа
serviceName.127.0.0.1.nip.io:5001
Но без доступа к интернету не будет работать.

Хотел бы понять что означает

намертво вешает систему.

в контексте микросервисов? И почему это является проблемой?

Тот получает кучу одинаковых заданий

А почему нужно обрабатывать одинаковые URL повторно?
Если, конечно, сильно надо, то можно проверять в K/V хранилище на наличие ключа с таким URL , у которого ограничено время жизни. Тогда при повторном событии просто игнорировать его.

Ну а, вообще, микросервис "Браузер" может работать только в качестве обработчика очереди, получая сообщения, отправленные REST API. Сам же просто складывать в своем темпе результаты сканирования URL в СУБД, а REST API будет проверять наличие в той же СУБД и сообщать результаты клиенту, если готово.

Когда несколько приложений обращаются к одной СУБД, то это усложняет поддержку этих приложений:

• приходится изменять код во всех приложениях при любых изменениях в схеме СУБД
  
• нужно отслеживать как влияют изменения на другие приложения из-за возможной регрессии.
  
• проводить мониторинг соединений и того как запросы одного приложения влияют на другие (timeout, deadlock).
  

Если все приложения должны писать в одну БД, то лучше добавить прослойку для обращения к ней.
DB <= service A
service A <= service B
service A <= service C

Кроме того так будет легче управлять, дебажить и масштабировать в случае нужды. Зона ответственности будет находиться у одного сервиса.

Мне показалось, что архитектура переусложнена. Может, чего-то недопонял. Prometheus метрики забирает (scraping) со всех узлов самостоятельно через http: //apiendpoint/metrics .

То есть схема такова (data flow):
[api 1..N] => Prometheus scraper => Prometheus TSDB

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

Клиент моего продукта получает крайние справа данные за сутки/неделю/месяц по названию группы (group_name) в виде графика

Для получения данных есть язык запросов PromQL по API.

В конфигурации Prometheus можно переопределить интервал сбора метрик с узлов. Каждый узел должен уметь отдавать метрики в заданном формате. Благо, есть библиотеки. Средствами библиотеки пишем метрики (новый запрос к АПИ от клиента - делаем increment группе), которые автоматически агрегируются необходимым образом для Prometheus и выдаются по запросу скрэпера. Ответственность за тайминг сбора метрик лежит на Прометее.

Данные временных серий хранятся в БД Prometheus в оптимальном виде. Или в совместимой с ней VictoriaMetrics, если того мало.

Prometheus для хранения двух метрик users_amount{group=} и users_online{group=}

Вроде бы OK.

тысячи лэйблов в Prometheus - это ок?

А зачем тысячи меток? Из-за кол-ва групп?
Цититрую:

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

То есть не рекомендуют.

если в Prometheus настроена pull модель для двух метрик, то он меня будет пинать раз в 5 минут делая два запроса по каждой метрике и я ему отдаю пачкой данные для тысяч лэйблов, у меня верное понимание?

Метрики собираются одинажды для узла (endpoint), который должен представлять из себя отдельную группу со своими парами users_amount, users_online. Если так нельзя, то тогда Прометей тогда, наверное, не подходит. По крайней мере, я так себе представляю.

Если по каким-то причинам Прометей не устроит, тогда можете рассмотреть ClickHouse, куда данные нужно отправлять пачками (с воркеров или как хотите). Но тогда всю логику сами разгребать будете. Redis'ом или как хотите.

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

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

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

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

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

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

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