Почему Unicorn должен быть развернут вместе с Nginx?

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

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

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

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

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

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

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

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

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

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

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

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

почему Unicorn должен быть развернут вместе с nginx?

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

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

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

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

[использование блокировки ввода / вывода] позволяет использовать более простой путь кода в интерпретаторе Ruby и меньше системных вызовов.

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

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

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

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

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

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

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

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

ключевой момент #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 можете сделать, но не эффективно.

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

больше

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

см. Также основные функции nginx.

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

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

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

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