Посторонись, пресловутый PHP! Долой Java! Старичок Perl, тебе так вообще давно пора на пенсию. И как же вы уже достали, попсовые Ruby и Python! Все эти давно знакомые технологии уже не торкают. Зато сегодня мы посмотрим на чрезвычайно прогрессивный подход, когда для написания серверного кода используется… JavaScript.

Есть идея для стартапа. Теперь вопрос: на чем его писать? Конечно, есть всеми любимый РНР — что может быть легче для веб-сайта!

Но скажи честно, как-то не тянет, правда? Ведь чтобы сделать чтото стоящее, голого РНР не хватит. Сразу придется прикручивать еще и AJAX, чтобы данные незаметно подгружались без обновления всей страницы целиком, да и это не решит всех проблем. О том, что PHP не так хорош, ты задумаешься в тот самый момент, когда к тебе разом ломанется много народа. А все потому что РНР (как и подавляющее большинство других языков, на которых строят сайты) даже в нашем, черт подери, двадцать первом веке, работают по классической схеме «запрос-ответ». Запрос страницы заставляет веб-сервер поднять указанный скрипт, выполнить его (линейно, строка за строкой весь твой код), а результат возвратить браузеру клиента. После этого скрипт «умирает», а следующий же запрос запустит всю эту адскую машинку заново. А если таких запросов одновременно тысяча? Старый добрый подход называется CGI (интерфейс взаимодействия веб-сервера и интерпретатора языка, на котором написана страница). Хитрые надстройки вроде FastCGI расширяют протокол, позволяя избежать выгрузки скрипта после первого запроса. Таким образом, когда второй пользователь запросит ту же страницу, для него будет уже все готово, останется только выполнить скрипт с новыми параметрами. Но все эти ухищрения — все равно не то.

 

Что такое хорошо, а что такое плохо

Многие разработчики всегда считали JavaScript просто «примочкой» к браузеру, эдаким недоязыком, который годится разве что для управления формами и манипулирования DOM-деревом веб-страницы. Некоторые до сих пор думают, что «java» в названии что-то да значит! 🙂 Действительно, язык очень простой. Впрочем, настоящие программисты давно научились творить с его помощью чудеса, предоставив нам потрясающе удобные онлайн-сервисы, которыми мы ежедневно пользуемся. Многие из таких профи пошли дальше и, трезво посмотрев на сам язык и его возможности, особенно по части работы с событиями, решили: а что если на JavaScript написать сервер? Ты получаешь возможность написать на одном и том же языке все части сайта: что серверную часть, что саму клиентскую страничку. Кроме того, JS отлично, просто идеально подходит для разных веб-штучек. Он очень простой и одновременно гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем.

А главное — это тотальная асинхронность. Это значит, что твой код будет выполняться не последовательно, как в случае с PHP/ Perl-скриптами, а именно в тот момент, когда для него будут готовы все данные. Ведь для веба не надо большой вычислительной мощности — большую часть времени сервер ожидает событий вроде получения данных формы, выборки из базы данных или, что еще хуже, ответа на запрос к другому серверу. Обычный РНР-скрипт в такое время простаивает, а значит, простаивает весь поток, не позволяя серверу задействовать его для других пользователей. В такой ситуации не спасает даже Nginx. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Такая функция называется callback, или обработчик событий. Хотя писать действительно сложный код в таком стиле немного неудобно, особенно если твоя функция зависит от нескольких событий сразу, но и для этого уже придумали свои фреймворки, зачастую гораздо более мощные и элегантные, чем все эти РНР/Ruby/Python.

 

А к чему она вообще, эта асинхронность?

Для примера ограничений последовательного выполнения кода рассмотрим два типовых примера кода на PHP и JavaScript, выполняющих одно и то же. Начнем с любимого PHP:

$result = $db->fetchOne('SELECT user_name FROM user_
accounts WHERE id = 1');
echo 'Мое имя: ' . $result . ';';

В первой строке мы посылаем простой SQL-запрос к БД на выборку имени пользователя, у которого id = 1.Обрати внимание: в этом месте скрипт останавливается, и следующая строка не будет выполнена до того самого момента, пока запрос не будет обработан базой, а результат не возвратится в переменную $result. Да, в нашем примере это тысячные доли секунды, но в реальности и запросы гораздо сложнее, и базы по размеру зачастую составляют гигабайты, и запросов таких может одновременно быть пара тысяч.

А теперь попробуем написать код на JS, используя асинхронный стиль:

db.query('SELECT user_name FROM user_accounts WHERE
id = 1', function(err, res){
if (!err) sys.log('Мое имя: ' + res);
});
sys.log('Продолжаем выполнение');

Тут опять же создается запрос к базе данных, однако кроме самого SQL-выражения в запросе передается еще и функция-обработчик (callback). Эта функция будет вызвана именно тогда, когда придет ответ от базы данных, а до этого момента выполнение скрипта ни в коем случае не будет стопориться. Для примера в следующей строке мы просто выводим строку в консоль, чтобы показать, что выполнение сценария продолжается сразу после формирования запроса, не ожидая его завершения. Собственно, в основе любого варианта серверного JavaScript заложена концепция событий и callback'ов, то есть обработчиков событий. Ты можешь описывать собственные события. Тогда ход выполнения приложения будет зависеть от событий, которые возникают в результате активности пользователя на странице («форма заполнена» или «новое сообщение» и т.д.) или генерируются внутри самого сервера (как, например, в случае с обращением к базе данных). Те действия, которые необходимо выполнять в случае наступления событий, описываются внутри функций обработчиков событий.

 

Движок, вот в чем вопрос

Короче говоря, использовать JavaScript не только для клиентской части, но и на серверной стороне — это хорошо и даже приятно. Другой вопрос — каким образом это возможно осуществить? Сегодня есть четыре основных движка, которые используются на серверах.

Rhino — движок от компании Mozilla, написанный на Java и поддерживающий последнюю 1.7 версию стандарта JS, который к тому же дополняет язык собственными расширениями и объектами. Основным преимуществом движка является работа поверх стандартной JVM, а значит, его можно использовать в любой среде, где работает Java. Другими словами, можно применять современные веб-серверы типа jetty, но при этом писать на любимом JS. Кстати, Rhino применяют на облачном хостинге от Google! А вот с производительностью сложнее. Она зависит, с одной стороны, от движка и применяемых там технологий, вроде JIT-компиляции, и от работы самой Java-машины. Кстати, многие тестеры, которые говорят, что Rhino очень медленный, забывают, что движок имеет два режима работы: интерпретации, когда скрипт каждый раз преобразуется в Java байт-код (аналогично PHP), и компиляции, когда такое преобразование происходит только раз, а потом многократно исполняется. Первый режим выгоден, когда ты отлаживаешь код, который меняется каждую минуту, второй больше подходит для рабочей версии проекта, работающей под нагрузкой. SpiderMonkey — еще один движок от Mozilla, на этот раз на C.

Кстати, это вообще первый в мире движок JS, написанный еще в Netscape — сегодня он открыт и используется в таких популярных продуктах как Firefox, Adobe Acrobat и даже в одном из эмуляторов серверов онлайн-игры Ultima Online. Далее разработчики сильно модифицировали его, добавив компиляцию JS напрямую в ассемблерный код, и переименовали в TraceMonkey — именно этот движок используется в ветке 3.6 Firefox’а. В основном SpiderMonkey используют в ПО, которое написано на С/С++ и нуждается в скриптовом языке. Из известных продуктов: Comet-сервер APE, noSQL БД CouchDB, серверная платформа Jaxer и модуль к Apache mod_js. Futhark — это движок от Opera, который, кроме браузера, используется в их инновационном сервисе Unite (типа встроенный сервер в каждом браузере), а также на их серверах, обслуживающих мобильный браузер Opera Mini. Жаль, что движок закрыт, и его пока нигде за пределами самой Opera не применяют.

V8 — движок от Google, который используется в Chrome и является основой будущей Chrome OS. Сегодня это самый крутой, быстрый и мощный движок, в котором JS-код напрямую преобразуется в ассемблер целевого процессора, что позволяет обойти по скорости все остальные движки. Кроме этого гугловцы используют множество ухищрений для оптимизации, хранят в памяти скомпилированный код, оптимизируют его на лету (например, удаляют блоки кода, которые по решению компилятора вообще не могут быть задействованы, и т.п.). На базе этого движка построена самая популярная и быстроразвивающаяся серверная платформа — Node.JS.

 

NODE.JS

Вероятно, именно после выхода Chrome разработчики смекнули, что такой быстрый движок можно успешно использовать и на сервере. Первым опытом стал проект V8cgi, который просто позволял писать серверные сценарии, работающие с любым веб-сервером по стандартному протоколу CGI. Дальнейшие эксперименты привели к рождению проекта Node.js — полностью самостоятельной платформы, включающей, кроме движка, встроенный сервер (HTTP и TCP/UDP/Unix-soket) и базовый набор библиотек, а также предоставляющей полностью асинхронную работу с файлами и сетевыми устройствами.

Проект развивается настолько быстро и активно, что уже сейчас готов к промышленному использованию. Это, в частности, доказывает опыт парней из Plurk (азиатский аналог твиттера), которые полностью перенесли свой comet-сервер, изначально написанный на Java и солидном JBoss Netty, на Node.js и, по отзывам, сократили потребление памяти буквально на гигабайты. А масштабы у них еще те — более сотни тысяч одновременных соединений. Запустить HTTP-сервер, способный обрабатывать асинхронно тысячи подключений — это несколько строк кода:

var sys = require('sys'),
http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(80, "127.0.0.1");
sys.puts('Server running at http://127.0.0.1:80/');

Чтобы запустить сервер, скопируй код в файл example.js и укажи его при запуске демона node:

% node example.js
Server running at http://127.0.0.1:80/

Маленький тест провести очень просто. Можно взять программу Apache Bench — очень простую тулзу для проведения нагрузочного тестирования, и запустить ее: running «ab -n 1000 -c 100 ‘http://127.0.0.1:80/’». Таким образом, бенчмарк будет «обстреливать» сервер тысячами запросов, используя 100 одновременных подключений. На моем ноутбуке сервер выдержал больше 3000 запросов в секунду. Это очень много!

Сам сервер написан на C++ и совсем немножко на ассемблере, однако большая часть библиотек из дистрибутива разработана на JavaScript. В состав базового набора сервера входят только основные функции, остальное оставлено на плечах разработчиков, которые уже написали сотни разных библиотек и фреймворков.

Впрочем, молодость проекта дает о себе знать: многих привычных для других решений модулей еще нет, а у многих библиотек текущая версия — 0.0.1, что не придает уверенности в их стабильности. Некоторые тривиальные задачи могут вообще не иметь готового к закачке решения, но бывает и наоборот — количество реализаций, зачастую радикально разных по архитектуре, исчисляется десятками (доступ к базе MySQL, например). Хотя большинство библиотек написано на чистом JavaScript, есть и такие, что требуют компиляции модуля к серверу, что обещает гораздо большую скорость — они просто расширяют стандартный API сервера.

 

Особенности NODE.JS

Основной особенностью Node, кроме полной асинхронности, яв ляется его однопоточная модель. Другими словами, все операции выполняются в одном и том же потоке ОС, даже если у твоего сервера тысяча одновременных пользователей. Правда, доступно создание дочерних процессов и низкоуровневое управление исполнением скриптов (загрузка, компиляция, работа с ассемблерным кодом, исполнение). Для реализации многопоточности и задействования всех ядер современных процессоров рекомендуется просто загружать несколько копий приложения, но можно взять на вооружение WebWorker из стандарта HTML5 и распределить работу приложения по нескольким дочерним процессам. Не думай, что раз нет многопоточности — это тормоз и отстой. Вспомни, что веб-приложение делает полезную работу очень быстро, а большую часть времени просто ожидает чего-то (данных от базы, от memcached'а или новомодной NoSQL-базы), либо просто держит в памяти открытые соединения для Comet'а, поэтому в одном потоке можно обработать и десяток тысяч, не прибегая к кластеризации.

Второй особенностью архитектуры Node является событийность. Почти каждая операция имеет коллбэки, генерирует событие, а пользователю доступен объект EventEmiter, через который можно буквально одной строкой генерировать свои события (это несложно, ведь событие — это просто строка с названием, а также список параметров, которые передаются в обработчик). Сам по себе Node построен вокруг EventLoop — глобального цикла обработки событий, который на каждом тике проверяет, готовы ли данные для какого-либо из определенных пользователем коллбэков. Если данные есть, начинается выполнение кода. Если не осталось больше кода — ожидаем следующего вызова. Цикл выполняется вне JS, а в самом движке, написанном на C, вследствие чего это происходит очень и очень быстро (порядка сотен тысяч раз в секунду). Что-то типа бесконечного цикла. В дополнение к этому в сервер встроен очень эффективный сборщик мусора (GC), поэтому даже тысячи подключений не вызывают переполнения памяти и падения сервера. Node.js обладает встроенной родной системой работы с событиями.

 

Простейший STEAMING-сервер

Попробуем написать простой, но в тоже время полезный пример, который в реальном времени будет выдавать пользователю полезную информацию без перезагрузки страницы. Вот идея для нашего приложения — брать новые данные, которые добавляются в текстовый лог, и выводить их в реальном времени на веб-странице:

var sys = require('sys'),
net = require('net'),
spawn = require('child_process').spawn,
http = require("http");
sys.puts('\nMy process PID: ' +
process.pid + '\n');
var tail = spawn('tail', ['-f',
'/var/log/nginx/access.log']);
// указываем названия логфайла
sys.puts("Start tailing");
tail.stdout.addListener("data",
function (data) {
sys.puts(data);
//дублируем себе на консоль
});
http.createServer(function(req,res){
res.sendHeader(200,{"Content-Type":
"text/plain"});
tail.stdout.addListener("data", function
(data) { res.write(data); });
}).listen(80);

С помощью функции spawn() мы создаем дочерний процесс утилиты tail, которая, собственно, и занимается тем, что считывает новые данные, которые появляются в логфайле. Процесс запускается только раз во время старта сервера. Собственно, наша задача — отлавливать моменты, когда команда tail будет выводить новые данные из логфайла и транслировать вывод на веб-страницу каждому подключившемуся клиенту. Для этого мы будем следить за возникновением события data (появлением новых данных) для переменной, к которой запущен процесс утилиты tail, и выводить их на страницу с помощью команды write(). Таким образом, соединение будет оставаться открытым для каждого HTTP-запроса. Вот и все. Следить за активностью процесса не так просто для обычного веб-приложения, но ничего не стоит для неблокируемой архитектуры node.js и логики выполнения, основанной на событиях. Нам остается только запустить скрипт: «node tail.js error.log» и открыть в браузере http://localhost:80.

На странице будут отображаться все сообщения, которые появляются в логфайле error.log.

 

Вот и сказочке конец

Сейчас, выбирая на чем бы таком написать очередное web 2.0 приложение, где не только красивый клиентский код, но и что-то надо делать на сервере, тебя парит одна грустная мысль о том, что все уже изобрели и написали до тебя. Те же языки, что и десять лет назад, те же библиотеки, протоколы и сервера. РНР уже ого сколько лет, Perl так вообще седой, Python у всех на слуху, а Ruby успел надоесть. Писать для веба стало рутиной — посмотри, как твои друзья сидят и думают, что же сделать с 25-мегабайтным монстром Zend-framework. А тебе хочется что-то нового, быть на острие прогресса, создавать то, на чем потом будут писать все, а сейчас знают только увлеченные хакеры и ищущие себя дзен-программеры? Посмотри на JavaScript в сервере, он просто создан для этого. Очень простой, мощный, еще не погрязший в тонне библиотек и фреймворков. Задачи, которые на РНР не решить вообще, на базе Node.JS решаются буквально десятком строк. И, возможно, именно такое программирование, наконец, принесет утраченное чувство наслаждения от разработки!

 

Готовые наработки для серверного Javascript

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

  • Narwhal (narwhaljs.org) — мощное решение, работающее поверх многих JS-движков. Таким образом, программистам не надо париться по поводу различия различных серверов — они могут просто писать код.
  • CommonJS (commonjs.org) — попытка стандартизировать платформу и дать общий API для всех движков, предлагая низкоуровневый API, а также API для подключения различных готовых модулей.
  • JSGI (JavaScript gate interface) — разработан специальный протокол взаимодействия связи веб-демона и серверных сценариев на JavaScript. Увы, спецификацию пока полностью поддерживает только проект Rhino в окружении сервера jetty.
 

Links

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии