Почему Unicorn необходимо развернуть вместе с Nginx?

Я хотел бы знать разницу между Nginx и Unicorn. Насколько я понимаю, Nginx-это веб-сервер, а Unicorn-рубиновый HTTP-сервер.

поскольку Nginx и Unicorn могут обрабатывать HTTP-запросы, зачем использовать комбинацию Nginx и Unicorn для приложений RoR?

4 ответов


nginx и
enter image description here
Единорог
enter image description here
См.единорог на github для получения дополнительной информации.


Nginx-это чистый веб-сервер, предназначенный для обслуживания статического контента и / или перенаправления запроса в другой сокет для обработки запроса.

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

большинство установок RoR используют комбинацию как традиционных веб-серверов, так и стоечных серверов для используйте все свои возможности. Nginx невероятно быстр при перенаправлении запросов через балансировку прокси и обслуживание статического контента. Unicorn вполне способен обрабатывать HTTP-заголовки и балансировать входящие запросы на Ruby для обработки.


этот ответ дополняет другие и объясняет почему Единорог нуждается в nginx перед ним.

TL; DR причина, по которой Unicorn обычно развертывается вместе с обратным прокси-сервером, таким как nginx, заключается в том, что его создатели намеренно разработали его так, делая компромисс для простоты.

прежде всего, ничто не мешает вам развернуть Unicorn без обратный прокси-сервер. Однако это было бы не очень хорошо. идея; давайте посмотрим, почему.

Unicorn следует философии Unix, которая заключается в сделайте одну вещь и сделайте ее хорошо, и это служить быстрые клиенты с низкой задержкой (мы увидим, что это значит, позже). Тот факт, что Unicorn предназначен для быстрые клиенты с низкой задержкой подразумевает, что это не очень хорошо с медленные клиенты с высокой задержкой, что действительно верно. Это одна из слабых сторон Unicorn, и именно здесь вступает обратный прокси-сервер играть: он сидит перед единорогом и заботится о тех медленных клиентов (мы увидим как позже).

к счастью, такой обратный прокси-сервер уже существует и называется nginx и.

решение обрабатывать только быстрые клиенты, значительно упрощает дизайн Unicorn и позволяет значительно упростить и уменьшить кодовую базу, за счет некоторой дополнительной сложности на отделе развертывания (т. е. вы также должны развернуть nginx в дополнение к Единорог.)

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

вместо его создатели приняли решение использовать существующее программное обеспечение, проверенные и очень хорошо разработан и, чтобы не тратить время и энергию на проблемы уже решена другим программным обеспечением.

но давайте перейдем к техническим вопросам и ответим на ваш вопрос:

почему Unicorn необходимо развернуть вместе с nginx?

вот некоторые из основных причин:

Unicorn использует блокировку ввода-вывода для клиентов

полагаться на обратный прокси означает, что Unicorn не нужно для использования неблокирующего ввода-вывода вместо этого он может использовать блокирующий ввод-вывод, который по своей сути проще и проще для программист следовать.

и как конструкция документ гласит:

[использование блокирующего ввода-вывода] позволяет использовать более простой путь кода в интерпретаторе Ruby и меньше syscalls.

однако, это также имеет некоторые последствия:

ключевой момент #1: Unicorn не эффективен с медленными клиентами

(для простоты мы предполагаем установку с 1 единорогом рабочий)

поскольку используется блокировка ввода-вывода,Единорог работник может обслуживать только одного клиента за раз, поэтому медленный клиент (т. е. один с медленным соединением) будет эффективно держать работника занятым в течение более длительного времени (чем быстрый клиент). Тем временем другие клиенты будут просто ждать, пока работник снова не освободится (т. е. запросы будут накапливаться в очереди).

чтобы обойти эту проблему, развернут обратный прокси-сервер перед Unicorn, который полностью буферы входящих запросов и ответы приложения, а затем отправляет каждому из них сразу (Он же ложка-кормит их) единорогу и клиентам соответственно. В связи с этим можно сказать, что обратный прокси-сервер "экранирует" Unicorn от медленных сетевых клиентов.

к счастью, Nginx является отличным кандидатом на эту роль, поскольку он предназначен для эффективной работы с тысячами сотен параллельных клиентов.

это решающее важно, чтобы обратный прокси-сервер находился в той же локальной сети, что и Unicorn (обычно на той же физической машине, связывающейся с Unicorn через сокет домена Unix), так что задержка сети сведена к минимуму.

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

ключевой момент #2: Unicorn не поддерживает HTTP / 1.1 keep-alive

поскольку Unicorn использует блокировку ввода-вывода, это также означает, что он не может поддерживать функцию HTTP/1.1 keep-alive, поскольку постоянные соединения медленных клиентов быстро занимают все доступные работники Unicorn.

поэтому, чтобы использовать HTTP keep-alive, угадайте, что: обратный прокси используемый.

nginx, с другой стороны, может обрабатывать тысячи параллельных соединений, используя всего несколько потоков. Поэтому он не имеет ограничений параллелизма, которые имеет сервер, такой как Unicorn (который по существу ограничен количеством рабочих процессов), что означает, что он может обрабатывать постоянные соединения просто отлично. Подробнее о том, как это на самом деле работает, можно найти здесь.

вот почему nginx принимает соединения keep-alive от клиентов и прокси-серверов к Unicorn над простыми соединениями через типично сокет Unix.

пункт #3: Unicorn не очень хорош в обслуживании статических файлов

опять же, обслуживание статических файлов-это то, что Unicorn can сделать, но не эффективно.

С другой стороны, обратные прокси, такие как nginx, хотя намного лучше в этом (т. е. sendfile(2) & кэширование).

больше

есть другие точки, которые изложены в философия документ (см. "Улучшена Производительность За Счет Обратного Проксирования").

см. Также основные характеристики nginx.

мы видим это, используя существующее программное обеспечение(т. е. nginx) и следуя философии Unix "делать одну вещь и делать это хорошо", Unicorn может следовать более простому дизайну и реализации, сохраняя при этом эффективность при обслуживании приложений стойки (например. ваше приложение Rails).

дополнительные информацию см. В разделе философия и конструкция документы, которые более подробно объясняют выбор дизайна Unicorn и почему nginx считается хорошим обратным прокси для Unicorn.


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

см.http://unicorn.bogomips.org/