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


139

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

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


3
Хороший вопрос ! Я думаю, что заголовок этого вопроса должен быть: «Зачем нам нужна комбинация nginx и unicorn.;) Ответы мне очень помогли.
servatj

1
@servatj Я добавил ответ, который более подробно объясняет, почему Unicorn нужен обратный прокси, такой как Nginx, перед ним. Возможно, вы захотите это проверить;)
Agis

Ответы:


60

Nginx
введите описание изображения здесь
Unicorn
введите описание изображения здесь
Дополнительные сведения см. В разделе unicorn на github .


1
Pratik, Какой у меня вопрос, сервер единорога может обслуживать как статический, так и динамический процесс, тогда почему мы используем NGinx или Apache, которые могут обрабатывать только статическое содержимое, в сочетании с пассажиром, единорогом или mod_php?
loganathan 05

17
@loganathan, и Apache, и Nginx намного быстрее обслуживают статический контент, чем ruby ​​или любой из серверов приложений. Они также знают, как обрабатывать кеширование, и хорошо разрешают одновременную загрузку файлов, продолжая принимать трафик и передавать его на серверы приложений.
Pratik

4
Кроме того, если у вас есть большие объемы поступающих + исходящих данных, nginx будет буферизовать их (и кормить ложкой) от клиента. Без nginx один из ваших единорогов будет связан во время загрузки / выгрузки.
BraveNewCurrency

11
Это не отвечает на вопрос, зачем вообще нужен nginx. Он просто помещает его на оба изображения без каких-либо комментариев. Ответ Ника намного лучше.
gorn

1
Я согласен с @gorn. Например, для меня это ничего не значило.
BalinKingOfMoria Reinstate CMs

94

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

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

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


78

Этот ответ дополняет другие и объясняет, почему Unicorn нужен nginx перед собой .

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

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

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

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

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

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

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

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

Почему Unicorn нужно развертывать вместе с nginx?

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

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

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

Также, как говорится в документе DESIGN :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше

Есть и другие моменты, которые изложены в документе ФИЛОСОФИЯ (см. «Повышение производительности за счет обратного проксирования» ).

См. Также некоторые из основных функций nginx .

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

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


Но почему бы просто не использовать Nginx, я думаю, он спрашивал, а не «почему единорогу требуется nginx». Что, например, Unicorn предоставляет такого, чего нет в Nginx?
omikes 06

3
@oMiKeY Если это так, я считаю, что другие ответы отвечают на этот вопрос довольно хорошо. Я все еще думаю, что мой ответ предоставляет полезную информацию для всех, кто пытается понять комбинацию nginx и единорога.
Agis

2
Это чистое золото. Спасибо!
Magne

14

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

См. Http://unicorn.bogomips.org/

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.