Усовершенствованный HTTP / 2-прокси для балансировки нагрузки распределенного решения по очистке

Question

Я построил решение распределенного HTTP-скребка, которое использует различные адреса «адресов выхода» по своему дизайну, чтобы сбалансировать нагрузку на сеть.

Решение поддерживает IPv4, IPv6 и HTTP-прокси для маршрутизации трафика.

Каждый процессор отвечал за определение наиболее эффективного маршрута для балансировки трафика, и он был временно реализован вручную для создания прототипа. В настоящее время решение растет и с ростом числа процессоров по мере того, как усложняется задача балансировки нагрузки, поэтому мне нужен способ создания выделенного для него компонента.

Я провел довольно обширное исследование, но, похоже, не смог найти решение для балансировки нагрузки трафика между IPv6, IPv4 (тысячи локальных адресов) и общедоступными прокси-серверами HTTP. Решение должно поддерживать весовые коэффициенты, проверки ответов на уровне приложений и периоды охлаждения.

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

Спасибо за вашу помощь!

Answer 1

Вы проверили этот проект? https://Traefik.io, который поддерживает http / 2 и tcp балансировку нагрузки. Проект с открытым исходным кодом и доступен на GitHub. Это сборка с использованием Go. Сейчас я использую его в качестве обратного прокси-сервера с балансировкой нагрузки практически для всего.

Я также написал небольшой пост в блоге на Docker и Go, где я демонстрирую использование Traefik. Это также может помочь вам в поиске. https://marcofranssen.nl/docker-tips-and-tricks-for-your-go-projects/

В базе кода traefik вы можете найти свой ответ, или вы можете использовать traefik для достижения своей цели вместо решения, разработанного собственными силами.

См. Здесь хорошее объяснение скорого появления Traefik 2.0 с поддержкой TCP. https://blog.containo.us/back-to-traefik-2-0-2f9aa17be305

Answer 2

Если вы ищете load balancing proxy, вы обнаружите Cache Array Routing Protocol (CARP).Это CARP может не соответствовать тому, что вы ищете, и существуют серверы только для прокси-кеша, чего я никогда не знал до сих пор.
Тем не менее, эти серверы тоже имеют свои load balancers, и, возможно, это деталь, гдеСтоит поискать больше.

Я нашел презентацию с упоминанием CARP как выдающегося решения: https://cs.nyu.edu/artg/internet/Spring2004/lectures/lec_8b.pdf

Пример: для прокси-массивов в Netra Proxy Cache Server: https://docs.oracle.com/cd/E19957-01/805-3512-10/6j3bg665f/index.html

Также существует несколько концепций для балансировки нагрузки (https://link.springer.com/article/10.1023/A:1020943021842):

The three proposed methods can broadly be divided into centralized and decentralized
approaches. The centralized history (CH) method makes use of the transfer rate of each
request to decide which proxy can provide the fastest turnaround time for the next job.
The route transfer pattern (RTP) method learns from the past history to build a virtual
map of traffic flow conditions of the major routes on the Internet at different times of the
day. The map information is then used to predict the best path for a request at a particular time of the day. The two methods require a central executive to collate information
and route requests to proxies. Experimental results show that self-organization can be
achieved (Tsui et al., 2001). The drawback of the centralized approach is that a bottleneck and a single point of failure is created by the central executive. The decentralized
approach—the decentralized history (DH) method—attempts to overcome this problem
by removing the central executive and put a decision maker in every proxy (Kaiser et al.,
2000b) regarding whether it should fetch a requested object or forward the request to another
proxy.

Поскольку вы используете публичные прокси-серверы, вероятно, вы не будете использовать decentralized history (DH), но centralized history (CH) ИЛИ route transfer pattern (RTP).

Возможно, было бы даже полезно полностью заменить собственное решение, например, так: https://github.blog/2018-08-08-glb-director-open-source-load-balancer/. У меня нет причин для этого особого примера, он просто случайный по результатам поиска, которые я нашел.

Поскольку я не работаю с прокси-серверами, этот пост является просто набором выводов, но, возможно, есть полезная деталь для вас. Если нет, не возражайте - возможно, вы знаете большинство или все ужеи это никогда не добавляет ничего нового для тебя.Также я никогда не упоминаю ни одного конкретного решения.