Статьи

Node.js — новый черный

Если вы обращали внимание на новости о веб-технологиях в прошлом году, вы, скорее всего, слышали имя node.js, упомянутое хотя бы один или два раза. То, что произошло потом, вероятно, произошло так: вы спросили «Что это?», И кто-то (или Google) сказал вам, что это был способ написания веб-серверов с использованием JavaScript. Если это вас не пугает, вы могли бы тогда спросить: «Зачем вам его использовать?», И ответ мог бы быть таким: использовать неблокирующую управляемую событиями IO для обеспечения высокого уровня. параллелизм в длинных опросах или кометных приложениях.

В этот момент вы перестали задавать вопросы. Я не виню тебя. Чтобы помочь разрушить эту стену жаргона, вот моя попытка объяснить, что такое node.js и почему вы должны обращать на это внимание.

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

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

Но теперь подумайте о том, как вы будете создавать такой сервис, как FriendFeed , где каждый пользователь обновляется в режиме реального времени. Единственный способ, который возможен, — это если каждый пользователь постоянно имеет активное соединение с сервером. Самый простой способ сделать это в настоящее время — это длинный опрос.

При длительном опросе HTTP действует как постоянное соединение: как только страница загружается , он запускает Ajax-запрос к серверу, даже если страница не хочет ничего конкретного . Но, в отличие от обычного Ajax-запроса, сервер не отвечает сразу. Он просто ждет и отправляет ответ только тогда, когда у него есть что-то новое, которое он хочет отобразить в браузере. Например, как только один из ваших друзей добавит новое сообщение, сервер вернет ответ, сообщающий браузеру обновить его отображение. Как только браузер получает ответ, он запускает другой запрос. Таким образом, браузер всегда ожидает нового события на стороне сервера.

Теперь подумайте, что это значит для традиционного веб-сервера, такого как Apache. Для каждого пользователя, подключенного к сайту, ваш сервер должен держать соединение открытым. Каждое соединение требует процесса, и каждый из этих процессов будет проводить большую часть своего времени либо в режиме ожидания (потребляя память), либо в ожидании завершения запроса к базе данных. Это означает, что трудно масштабировать до большого количества соединений, не останавливаясь и не затрачивая все свои ресурсы.

Так в чем же решение? Вот где в игру вступает часть этого жаргона: специально не блокирующая и управляемая событиями . Что означают эти термины в этом контексте, менее сложно, чем вы могли бы опасаться. Думайте о неблокирующем сервере как о цикле: он просто продолжает вращаться. Приходит запрос, цикл захватывает его, передает его другому процессу (например, запросу к базе данных), устанавливает обратный вызов и продолжает работать, готовясь к следующему запросу. Он не просто сидит в ожидании возвращения базы данных с запрошенной информацией.

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

Для этого FriendFeed использует неблокирующую инфраструктуру, написанную на Python, которая называется Tornado . Веб-сервер nginx также ведет себя таким образом. Но у Node.js есть туз в рукаве: поскольку он использует JavaScript — работает на безумно быстром движке V8 от Google — ему не нужно беспокоиться о том, может ли запрос, который он делает к другому коду, вызвать блокировку цикла , Причина в том, что JavaScript по своей сути управляется событиями. Подумайте об этом: когда вы пишете JavaScript для браузера, вы просто присоединяете обработчики событий и обратные вызовы. Вот так был разработан язык.

Node.js все еще находится в зачаточном состоянии, поэтому, если вы хотите написать приложение на его основе, вам нужно выполнить довольно низкоуровневое кодирование. Но с надвигающимся появлением WebSockets в браузерах следующего поколения (что устраняет необходимость в длительных опросах вообще), этот тип технологии станет только более важным в Интернете. Я надеюсь, что я дал вам стимул начать возиться и разбираться в этих концепциях.