Сервис отправки Webhook-уведомлений на Go (для всех)

1. Цель проекта Разработать сервис на языке Go для отправки HTTP-запросов (вебхуков) на указанные URL с учетом следующих требований: Поддержка методов GET, POST, PUT. Передача заголовков, параметров и тела запроса. Ограничение количества запросов для каждого домена (по умолчанию 1 запрос в секунду, с возможностью настройки). Отправка всех вебхуков с одного IP-адреса, независимо от количества подов или нод. Управление очередью задач, обработка ошибок и предоставление интерфейса для мониторинга и управления. 2. Функциональные требования 2.1. Получение задач Сервис принимает задачи через очередь RabbitMQ. Описание полей: task_id: Уникальный идентификатор задачи. initiator: Название сервиса, инициировавшего задачу. method: HTTP-метод (GET, POST, PUT). url: URL для отправки запроса. headers: Заголовки запроса (опционально). params: Параметры для GET-запросов (опционально). body: Тело запроса для POST/PUT (опционально). 2.2. Очередь задач Задачи хранятся в RabbitMQ и обрабатываются в порядке поступления (по принципу FIFO). Поддержка пачечной обработки для повышения производительности. 2.3. Обработка задач Используется пул worker’ов (горутин) для параллельной обработки задач. Логика обработки: Извлечение домена из url (например, example.com). Проверка лимита запросов для домена через Redis. Если лимит не превышен, отправка HTTP-запроса через прокси (для использования одного IP). Обработка ответа: Код 200: Успех, задача завершена. Любой другой статус (4xx, 5xx, таймауты, сетевые ошибки): Увеличить attempts на 1. Если attempts < 30, отложить задачу с экспоненциальной задержкой (например, 2^attempts секунд). Если attempts >= 30, переместить задачу в Dead Letter Queue (DLQ). 2.4. Rate Limiting Для каждого домена устанавливается лимит запросов в секунду (по умолчанию 1 запрос/сек). Лимиты хранятся в PostgreSQL и кэшируются в Redis. При появлении нового домена он автоматически добавляется с дефолтным лимитом (1 запрос/сек). Worker’ы проверяют лимит перед отправкой каждого запроса. 2.5. Отправка с одного IP-адреса Все запросы отправляются через прокси-сервер (например, Squid) или NAT, чтобы использовать единый выходной IP-адрес. 2.6. Управление доменами Данные о доменах хранятся в PostgreSQL Логика: При поступлении задачи с новым доменом добавляется запись с rate_limit = 1 и is_active = true. Администратор может изменять rate_limit или деактивировать домен (is_active = false), что приостанавливает обработку задач для этого домена и все задачи будут уходить в DLQ. 2.7. Dead Letter Queue (DLQ) Задачи, не доставленные после 30 попыток, перемещаются в DLQ (отдельная очередь в RabbitMQ). Дополнительно задачи сохраняются в PostgreSQL. Админ-панель для DLQ: Возможность выбрать задачи и переотправить их пачкой. При переотправке создается новая задача в основной очереди с attempts = 0. Удаляется запись из DLQ и таблицы dlq_tasks. 2.8. Админ-панель Веб-интерфейс для управления: Домены: Просмотр списка, редактирование rate_limit и is_active. Очередь задач: Просмотр текущих задач, фильтрация по initiator, домену, статусу. DLQ: Просмотр, фильтрация, переотправка задач пачкой. Реализация аутентификации (например, JWT или базовая аутентификация). 2.9. Мониторинг Использование Prometheus для сбора метрик: Длина основной очереди и DLQ. Количество ошибок и сбоев. Использование лимитов (rate limiting). Время нахождения задач в очереди. Настройка Grafana для визуализации метрик. Настройка алертов на превышение лимитов или большое количество ошибок. 3. Нефункциональные требования Производительность: Способность обрабатывать до 1000 задач в минуту. Масштабируемость: Поддержка горизонтального масштабирования worker’ов. Надежность: Повторные попытки до 30 раз при неудаче. Идемпотентность обработки задач через уникальный task_id. Безопасность: Защита админ-панели аутентификацией. Хранение секретов (паролей, ключей) в переменных окружения или Vault. Логирование: Подробные логи с указанием task_id, initiator, URL и статуса ответа. Конфигурирование: Все настройки сервиса выносятся в config.yaml 4. Технологии Язык программирования: Go. Очередь: RabbitMQ. База данных: PostgreSQL. Rate Limiting: Redis. Веб-сервер для админ-панели: Gin или Echo. Мониторинг: Prometheus + Grafana. 5. Архитектура Worker Service: Основной сервис для обработки задач из очереди. Admin Service: Веб-интерфейс для управления доменами, очередью и DLQ. Rate Limiter: Redis для отслеживания и ограничения запросов. Коммуникация: RabbitMQ для передачи задач. Хранилище: PostgreSQL для хранения данных о доменах и DLQ. 7. Дополнительные требования Документация: Подготовить документацию API для админ-панели. Тестирование: Написать юнит-тесты для модулей rate limiter и обработки задач. CI/CD: Настроить автоматизацию деплоя (например, через GitHub Actions или GitLab CI). 8. Сроки и бюджет обсуждаются, напишите ваш опыт и предложение!