Какие реализации балансировщиков нагрузки на NodeJS сейчас лучшие и насколько они адекватно работают?

Question

[Dmitriy Mozgovoy]

Как то все покрыто мраком тут в случае с node. Хотелось бы ознакомится с лучшими реализациями, которые хоть где то реально используются. Выдача гугла пестрит тьмой балансировщиков на ноде, но качество их под вопросом- нет никакой информации о публичных тестах, алгоритмах по которых они распределяют нагрузку. Каждый проверять - жизни не хватит=) Пока адекватную балансировку хотя бы в рамках одной машины, между процессами. Балансировщик нужен именно на Ноде, ибо надо допилить его так, чтобы процессу доставались только определенные запросы, другому другие и т.д
Есть ли реализации учитывающие загрузку цп, озу и количество открытых соединений по процессах? Хотя бы от такого оттолкнутся..

Answer 1

[Roman Zhak]

pm2.js

Answer 2

[Тимур Шемсединов]

Учитывать загрузку ЦП и ОЗУ обычно не нужно, это только для эзотерических задач. Для балансировки в рамках одной машины хватает рандомного раскидывания или приклеивания по IP (IP sticky) хватает библиотеки cluster (или более низкоуровневой child_process) для передачи хендлов сокетов из центрального процесса в дочерние через системный механизм IPC (interprocess communication) для обработки. Например, вот тут как я это делаю: /lib/impress.js#L636-L646 в Impress Application Server. Если выходить за рамки одной машины, то чисто нодовская балансировка не годится, нужно применять двухуровневую балансировку, хардварное решение типа F5 Load balancer + внутри машины еще и распределение между процессами через IPC. Софтварные балансировщики на ноде в режиме нескольких машин ни чем не лучше чем Reverse proxy, в этом случае nginx даст Вам лучшие результаты, чем нодовские решения, это точно, он может еще и терминировать SSL очень эффективно и дальше уже передавать в ноду просто HTTP, снижая нагрузку на нодовский сервер. Как на nginx, так и на хардварных решениях, вполне можно сделать любой URL-реврайтинг, стики и объединение нескольких сервосов и портов в один, но хардварные на порядок производительнее.

Comments

[Dmitriy Mozgovoy]

Ну у меня несколько нестандартные просто нужды ибо и архитектура нестандартная- экспериментальная. Вообщем полностью готовый балансировщик, вероятно, и не подойдет, я ради того их ищу - дабы подсмотреть уже выработанные решения, кто как оценивает занятость процесса дабы на их основе написать свое. У меня workerы неравнозначны. Каждый worker выполняет определенный набор приложений, которые распределяются динамически masterом между ними (По крайней мере так должно быть, а для этого надо выработать правильный алгоритм оценки занятости workerов) А приложения - скорее сервисы- просто мелкие независимые модули, а не целый "сайт". ЦП оценивать нужно однозначно, одно ядро пашет на 100%, а в других может быть недогруз, хоть и запросов больше обрабатывает. ОЗУ свободное и занимаемое по процессах тоже не мешает, больше сожрано озу - больше данных внутри памяти js - медленнее, возможно, будет код обрабатываться (хотя над этим нужно подумать) ну а если между машинами - то логичнее ж загружать ту, у которой куча свободного озу.
P.S Хех бегло посмотрел я на Ваш репозиторий - подозреваю что я тоже в похожем направлении провожу эксперименты=)

[Тимур Шемсединов]

У меня как-бы не специфическое, а наоборот, универсальное решение сервера приложений, которое уже работает на кластерах из десятков серверов и протестировано на обслуживание миллионов пользователей и сотен тысяч RPS.

Если Вы хотите маршрутизировать разные URLы в разные воркеры, то cluster (и child_process) с передачей хендла сокета - не катят, потому, что мастер-процесс из сокета может взять только IP, даже заголовков HTTP не может взять и, следовательно, не может получить путь. Если бы мастер это делал, то воркер бы уже не мог прочитать из сокета эти данные. Тут есть два пути:
1. Не пробрасывать запросы, а проксировать, т.е. разбирать заголовки и из мастера делать опять HTTP-запрос в воркеры, и тогда воркеры это совершенно отдельные приложения, открытые на отдельных портах или даже разных машинах. С этой точки зрения, лучше даже использовать nginx, в котором можно правильно проксировать или даже написать свой модуль/плагин к nginx.
2. Передавать запросы от мастера к воркерам не через IPC и не через HTTP, а передавать запросы через MQ (очереди сообщений), как ZeroMQ, RabbitMQ, Redis и т.д.

[Dmitriy Mozgovoy]

Тимур Шемсединов: полезная инфа, я кластеризацию до недавних пор вообще не трогал касательно node, из за ее сыроватости, собственно об реализациях MQ я вообще не в курсе, будем расширять горизонты.
Пока предварительно и собирался на уровне http проксировать, так как о втором возможном варианте c MQ в курсе пока не был.

Да, вижу Вы накодили немало, стальное усердство=) Захабрили, но народ не очень ведется...

[Тимур Шемсединов]

Хомяки пишут rest-crud-mvc-middleware-stateless-orm и что не напишут, все контроллер выходит))) а я чхал на пасочки, у меня системы предназначены для Поднебесной империи, а там столько населенич, что этот маркетинговый цирк некогда разводить, нежно что-то работающее, вот и как только я понял, что все имеющееся в наличии слишком мало, то довелось делать... Ине фиолетово, сколько людей подключатся к этому, главное их качество, квалификация и опыт. В принципе уже мнйчас людей достаточно, чтобы сднлать полноценный сервер приложениц.

Answer 3

[sim3x]

nginx
чем тупее будет балансер - тем лучше он будет выполнять свои задачи

upstream upstream1{}
upstream upstreamX{}
...

location /api/v1/todo1 {
     proxy_pass http://upstreamN;
}

location /api/v1/todoX {
     proxy_pass http://upstreamN;
}

Answer 4

[Тимофей]

https://www.phusionpassenger.com