В этом посте речь пойдет о библиотеке, которая регистрирует ноды внутри себя и перенаправляет запросы извне на конкретную ноду.
Как возникла идея написать этот проект?
После того, как возникла необходимость парсить сайты в больших количествах, я попробовал реализовать такую штуку с помощью селеновой сетки, тогда взял селеноид. подошёл selenoid, но там было много того, что мне не нужно, типа версий и опций браузера, и самое главное отсутствие автомасштабирования (но selenoid нужен не для этого).90% времени кластер простаивает, а затем появляется большая нагрузка, с которой сервер не справляется.
Это приводит к большим затратам на оборудование, которое практически постоянно не работает, да и не справляется.
Я подумал, что было бы здорово, если бы по мере поступления нагрузки количество исполняемых браузеров увеличивалось, а по мере исчезновения нагрузки браузеры удалялись.
К счастью, это можно реализовать, например, через АВС EC2 .
Немного о структуре
- Центр.
Хаб запускается там, где вам удобно; он нужен в одном экземпляре.
При создании докер-контейнера с хабом вам необходимо передать ему переменную среды.
жетон .
После чего он начинает ждать входящие соединения от узлов и пользователей.
Хаб запоминает маршруты, помнит их ровно одну минуту.
В бою , затем удаляет этот маршрут и освобождает узел для другого клиента.
- Морской узел.
Узел можно настроить как базовый контейнер для систем автомасштабирования, например, при средней нагрузке на пул контейнеров, добавить еще один такой же или, в крайнем случае, запустить виртуальный сервер с этим контейнером для длительность запуска при условии оплаты за фактическое время использования сервера.
При создании докер-контейнера с узлом вам необходимо передать ему переменную среды.
жетон И сервер .
Сервер — это IP нашего хаба.
Вариант №1. Запрос с узла
Узел отправляет запрос хабу с установленным заголовком.жетон - это токен из переменной среды.
Хаб проверяет токен из запроса и, если они совпадают, запоминает его.
Хаб начинает пинговать этот узел каждые 4 секунды.
Если 5 попыток ping не увенчались успехом, узел удаляется с отметкой о потере соединения.
Узел, в свою очередь, инициирует ответный пинг раз в 10 секунд в случае потери соединения с хабом.
Это сделано для того, чтобы после потери соединения кластер сам восстанавливал свое состояние.
Вариант №2. Запрос от пользователя
Пользователь делает запрос к хабу с заданными заголовками жетон И число .Токен необходим для того, чтобы только доверенные узлы могли управлять кластером, а номер необходим для того, чтобы мы могли создавать разные сеансы в пределах одного IP-адреса клиента.
Каждая сессия имеет свой уникальный номер.
По каждому запросу хаб проверяет, есть ли уже созданный маршрут или нет; если есть, запрос просто перенаправляется на нужный узел; если такого маршрута нет, запрос пользователя ставится в очередь на освобождение узла.
Как только один из узлов освобождается, хаб создает маршрут для пользовательской сессии и освобожденный маршрут. Теперь все запросы к этой сессии будут идти на конкретный узел.
Минуту спустя.
когда пользователь закрывает соединение, узел освобождается и передается другому запросу пользователя.
Нижняя граница
Пост получился больше похожим на инструкцию по использованию, но тем не менее, я думаю, что этот проект может быть полезен.
P.S. Некоторые разъяснения
Это первый проект, который я начал писать на GOLANG, поэтому если у кого-то есть предложения или замечания, пишите в комментариях (даже на пиар не рассчитываю, но было бы супер круто!) Теги: #golang #phantomjs #docker #тестирование ИТ-систем #программирование-
Совет По Развитию Специального Назначения
19 Oct, 24 -
К Вопросу О Плановом Устаревании
19 Oct, 24 -
Прозрачность И Доверие
19 Oct, 24 -
Иерархия Классов C++ На Коленке
19 Oct, 24 -
Зачем Нужен Список Контактов?
19 Oct, 24 -
Технология Jpeg: Анализ Пространства Решений
19 Oct, 24
