Цикл событий Node.js - nginx/apache

Question

Оба nginx и Node.js имеют циклы событий для обработки запросов. Я поставил Nginx перед Node.js, как было рекомендовано здесь

Using Node.js only vs. using Node.js with Apache/Nginx

с установкой показано здесь

Node.js + Nginx - What now?

1. Как два цикла событий играть вместе? Есть ли риск конфликтов между ними? Интересно, потому что Nginx не может обрабатывать столько событий в секунду, как Node.js или наоборот. Например, если Nginx может обрабатывать 1000 событий в секунду, а node.js только 500, не вызовет ли это проблем? (Я не знаю, если 1000 500 разумных порядков, вы можете исправить меня по этому поводу.)

2. Как насчет того, чтобы Apache перед Node.js? У Apache нет цикла событий. Просто потоки. Так не помешает ли Apache перед Node.js победить цель?

3. В this 2010 talk, у создателя Node.js у Райана Даля было видение, чтобы избавиться от nginx/apache/что угодно, и заставить узел говорить напрямую в Интернете. Когда вы думаете, что это будет реальностью?

Answer 1

1. Оба Nginx и узел используют асинхронный и подход управляемых событий.Связь между ними будет идти более или менее, как это:

   • Nginx получает запрос
   • Nginx направляет запрос к процессу узла и сразу же возвращается ждать больше запросов
   • узел получает запрос от nginx
   • Узел обрабатывает запрос с минимальным использованием ЦП, пока в какой-то момент он не должен выдавать один или несколько запросов ввода-вывода (считывание из базы данных, запись ответа и т. д.). На этом этапе он запускает все эти запросы ввода-вывода и возвращается к ожиданию большего количества запросов.
   • Вышеуказанное может повторяться много раз. Вы можете иметь сотни тысяч запросов в неблокируемом состоянии ожидания, где nginx ожидает, что Node и Node ожидают ввода-вывода. И хотя это происходит, как nginx, так и Node готовы принять еще больше запросов!
   • В конечном итоге будет запущен асинхронный ввод-вывод, запущенный процессом Node, и будет вызвана функция обратного вызова.
   • Если есть еще запросы ввода-вывода, которые не были выполнены для этого запроса, то узел снова возвращается к своему циклу. Также может случиться так, что как только операция ввода-вывода завершится, эти данные будут потребляться обратным вызовом Node, а затем возникнут новые операции ввода-вывода, поэтому Node сможет запускать больше запросов асинхронного ввода-вывода перед возвратом в цикл.
   • В конце концов все операции ввода-вывода, запущенные узлом для конкретного запроса, будут завершены, в том числе те, которые записывают ответ обратно в nginx. Таким образом, Node завершает этот запрос, а затем, как всегда, возвращается к своему циклу.
   • nginx получает событие, указывающее, что данные ответа пришли для запроса, поэтому он берет эти данные и записывает их обратно клиенту, еще раз неблокирующим способом. Когда ответ был отправлен клиенту, и событие запустится, и nginx завершит запрос.

   Вы спрашиваете, что произойдет, если nginx и Node смогут обрабатывать различные количества максимальных соединений. У них действительно нет максимума, максимум в общем случае происходит из конфигурации операционной системы, например, из максимального количества открытых дескрипторов, которые система может иметь за один раз или пропускной способности ЦП. Поэтому ваш вопрос действительно не применим. Если система настроена правильно, и все процессы связаны с I/O, ни nginx, ни Node никогда не блокируются.

2. Помещение Apache перед узлом будет работать только в том случае, если вы можете гарантировать, что ваш Apache никогда не блокирует (т. Е. Он никогда не достигает максимального предела соединения). Это трудно/невозможно достичь для большого количества подключений, потому что Apache использует отдельный процесс или поток для каждого соединения. nginx и Node очень хорошо, Apache этого не делает.

3. Запуск узла без другого сервера впереди работает нормально, и это должно быть хорошо для сайтов с малой и средней нагрузкой. Причиной размещения веб-сервера перед ним является то, что веб-серверы, такие как nginx, обладают функциями, которые у Node нет, и вам нужно будет реализовать себя. Такие вещи, как кэширование, балансировка нагрузки, запуск нескольких приложений с одного сервера и т.д.

Answer 2

1. Событие петли являются независимыми. Контуры событий реализуются на уровне приложений, поэтому ни одна из них не заботится о том, какую архитектуру использует другая.

2. NodeJS хорош во многих вещах, но есть места, где он все еще колеблется. Как только пример служит для статических файлов. На данный момент nodejs работает довольно плохо в этом тесте, поэтому наличие выделенного веб-сервера для ваших статических файлов значительно улучшает время отклика. Кроме того, nodejs все еще находится в зачаточном состоянии и не был «проверен и ожесточен» в вопросах безопасности, таких как Apache на nginX.

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

Answer 3

1. Обе петли события не связаны между собой. Они не играют вместе.
2. Да, это довольно бесполезно. Apache не является балансировщиком нагрузки.
3. Что сказал Райан Дал уже применимо. Предел одновременных пользователей определенно выше, чем у Apache. До того, как веб-сайты node.js со значительным количеством одновременных пользователей должны были использовать nginx для балансировки нагрузки. Для предприятий малого и среднего бизнеса это можно сделать только с помощью node.js. Но выведение nginx полностью потребует времени. Пусть node.js будет стабильным, прежде чем он сможет следовать этому амбициозному сне.

Answer 4

Я думаю, что ваши вопросы были в значительной степени охвачены некоторые другие ответы, но есть несколько штук отсутствует, а некоторые Я не согласен с этим, так что вот мои:

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

2. Как вы указываете, если вы используете Apache, вы сбрасываете выгоду из использования Node.js, то есть массивного параллелизма и веб-узлов. Я бы не рекомендовал это делать.

3. Люди уже используют Node.js в передней части их стека. Поиск тестов возвращает reasonable-looking results в пользу Node, поэтому производительность, на мой взгляд, не является проблемой. Тем не менее, есть еще причины поставить Nginx перед узлом.

   1. Security - Node было уделено более пристальное внимание, но это все еще молодой. У вас могут не быть проблем здесь, но осторожность часто бывает вашим другом.

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

   3. Рабочая гибкость - Если вы достигнете масштаба, вы можете разделить порцию статического контента, чтобы уменьшить нагрузку на серверы приложений. Возможно, вы захотите разделить контент между разными доменами и управлять им по отдельности или использовать разные методы SSL или прокси для разных доменов или шаблонов URL. Это то, что легко для парней Ops настраивать в Nginx, но вам придется вводить код вручную в приложении Node.