Как стать автором
Обновить

Комментарии 41

НЛО прилетело и опубликовало эту надпись здесь
Ну, я могу также сказать — взяли с++, компилятор и написали. Что тут особенного? :-)

Дело в том, что когда дело дошло до production-ready сервера быстрых коммуникаций, оказалось, что на рынке нет ничего адекватного, кроме глючного модуля для nginx, внутри которого был необновляемый копипаст ядра nginx :-)

Писать большой плагин для nginx, исходники которого недокументированы — пустая трата времени и сил. Аналогом модели nginx является, с небольшой натяжкой — NodeJS. Имхо решение получилось сбалансированное как по выбору технологии, так и по отдаче.
НЛО прилетело и опубликовало эту надпись здесь
А как теперь в этой схеме работает Nginx с нодой? Или там простое транслирование запросов? Или терминирует на себя вебсокеты и http, а к нодам ходит по другому протоколу?
Да, Nginx просто проксирует запросы на node-процессы, выступая в роли балансировщика. Плюс берет на себя обработку TLS.
Ничего удивительного: выбрали плохую технологию (Node.js) и потом успешно боролись с её непригодностью для программирования: невозможность использования памяти для обработки данных.

В итоге вы не непригодной нодой пользуетесь, а редисом.
Чем плох Node.js?
во-первых, как верно подметил автор текста, Node.js не годиться для хранения и обработки данных в памяти из-за мультипроцессной архитектуры.

Писали бы на Erlang, Java или Go, можно было бы обойтись _одним_ демоном, а это проще отлаживать, развертывать и контролировать.

Во-вторых, Nodejs — это беспощадные коллбеки или промисы, которые не много чем лучше. Отследить, куда утекла память невозможно, да и не нужно, потому что в отличие от эрланга, который может не поперхнувшись использовать 200 гигабайт, а потом обратно сдуться до 500 мегабайт, у Node есть ограничения в памяти по лимиту.

А память — это один из самых быстрых способов хранить и обрабатывать информацию. Просто люди из мира PHP это боятся и не привыкли к этому, ведь в PHP надо всегда пользоваться внешней работающей БД из-за непригодности самого языка.

Плюс, конечно, никакой интроспекции работающей системы в рантайме, как в Эрланге нет и не планируется.
С использованием памяти для обработки данных в ноде все хорошо, проблемы у автора начались при использовании памяти для хранения данных. Но эта же проблема присутствует и в других языках — так для того СУБД и изобрели.
нет, у него проблемы именно с оперативным обменом данными.
Что вы понимаете под «оперативным обменом данными»? Кто и с кем обменивается?
источник данных с клиентами.

Плюс я так и не понял, умеют ли они poll
Не понимаю. В статье про него ничего не говорилось. Нельзя ли подробнее?
Если пуш сервер поддерживает только веб-сокеты, то дела очень плохи, потому что вебсокеты до сих пор не везде проходят. В некоторых местах их режут, где-то даже кешируют плохой ответ. Одни лишь вебсокеты не очень подходят для пуша.

Вы начали с утверждения, что у node.js есть проблема оперативного обмена данными между источников данных с клиентами — и вдруг перескочили на poll… я все еще не понимаю, что вы пытаетесь сказать.
НЛО прилетело и опубликовало эту надпись здесь
Рассматривали ли реализацию на ReactPhp? В свете выхода php7, кажется очень перспективно.
Это ничего что WebSocket допускает только 1 коннект на сайт? Т.е. открыв вторую вкладку, например в Хроме, получим пресловутое «ожидание свободного сокета»
Это сильно зависит от браузера. Ну и обходится одной строкой в DNS-настройках поддомена и одно строкой на клиенте — заодно получаем DNS-балансировку
Это не так. Современные браузеры, поддерживающие технологию WebSocket, не ограничивают браузер одним соединением на сайт.
Разработчики современных браузеров с вами не согласны
конечно наплевать. Равно как и то, что одними вебсокетами жив не будешь: их режут DPI системы у глупых провайдеров.
Хотелось бы больше деталей увидеть. Например,
— почему ws, а не socket.io?
— почему всё-таки ушли от pm2?
— c чем именно связано равное к-во использования клиентами long polling & websocket?
Тоже интересует первый вопрос. Предполагаю, что вместо использования клиентского готового socket.io написан клиентский велосипед.
Клиентская часть уже была написана. И велосипедов там нет. Обработка Ajax-запросов и вебсокет-событий — это минимум кода. Основная часть клиентской библиотеки занимается обработкой данных, которыми обмениваются клиент и сервер.
почему ws, а не socket.io?

Socket.io сам внутри себя использует ws. По статистике npm, ws самый популярный модуль для вебсокетов. Плюс ряд тестов показывают, что он еще и самый быстрый.

почему всё-таки ушли от pm2?

Отказались, как от возможной причины внезапных зависаний системы. PM2 запускало приложение в режиме кластера и выполняло роль балансировщика.

c чем именно связано равное к-во использования клиентами long polling & websocket?

Видимо не совсем понятный график получился :). На нем изображено 100 тысяч вебсокетов и 5 тысяч lp-запросов.
Нет, всё ясно, спасибо за ответы.
Но разве WS поддерживает longpolling?
Насколько мне известно socket.io поддерживает всё, а вот WS, только websocket?
поправьте если ошибаюсь.
Спасибо за ответы :)
Да, все верно. WS умеет только работать с веб-сокетами. Но long-polling в Node.Js реализуется очень просто: входящий запрос не закрываем до тех пор, пока либо не появятся данные, либо не наступит 40 секундный таймаут.
Теперь ясно. Спасибо ;)
у socket.io навернуто сверх нативного websocket очень много. мы его не используем по этой причине — есть сервисы на C#, которым тоже нужно общаться с сервером сообщений, и придется эмулировать «протокол» socket.io, и если они что-то поменяют — все просто может перестать работать. erinarios ws — это нативный websocket.

а так конечно socket.io очень удобный и в нем много чего из коробки есть.
Можно было SockJS использовать тогда.
Но все уже написано — socketio4net.codeplex.com
Released: Jun 26, 2012

по-моему наши как раз его и использовали (ребята тогда нашли только одну либу для этого), но автор на него давно забил. либа работает только с версией socket.io 0.9 и младше, а в 1.x они уже сильно поменяли протокол. поэтому и решили нативный брать, без наворотов.

я когда писал comet-сервер перебрал много разных компонентов — у каких-то на тот момент wss был криво реализован, кто-то не мог проксировать запросы по части урла на одном ip на upgrade

var httpProxy = require('http-proxy');
var proxy = httpProxy.createProxyServer({});

function proxyWebsocketResponse(req, res, head) {
    try {

        var pathname = url.parse(req.url).pathname;

        if ( (config.comet.websocket.proxy) && (pathname === config.comet.websocket.path) ) {
            var options = {
                target: 'ws://' + config.comet.websocket.host + ':' + config.comet.websocket.port + '/',
                ws: true
            };

            proxy.ws(req, res, head, options);

            proxy.on('error', function(e) {
                console.error('WebSocket error: ' + e.message);
                res.end();
            });

        } else {
            res.statusCode = 501;
            res.end('Not Implemented');
        }
    } catch (e) {
        console.error('Error: ' + e.message);
    }
}

httpServer.addListener('upgrade', proxyWebsocketResponse);


поэтому был выбран ws
А вариант отдельного протокола для связи с сервисами на C# не рассматривался?..
НЛО прилетело и опубликовало эту надпись здесь
При чем тут фронтенд вообще?
незачем. ui, comet и различные сишные демоны — это отдельные распределенные компоненты продукта.
Не почему же «незачем»? Чтобы свой велосипед вместо socket.io не писать…
кому «велосипед», а кому успешно и понятно уже год работающий компонент в составе продукта используемого ведущими сотовыми операторами.

я не пионер и не склонен писать «велосипеды», это была осознанная необходимость, в том числе и по безопасности.
Дааа я тоже ждал более технического описания, примеров, аналитики по скорости работы по сравнению с предидущим решением… :(
Почему Redis, а не Rabbit?
Rabbit как-то более предназначен для каналов (очередей) сообщений, да и с роутингом значительно интереснее.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий