Этот ответ дополняет остальные и объясняет , почему Unicorn нужен nginx перед ним .
TL; DR Причина, по которой Unicorn обычно разворачивается вместе с обратным прокси-сервером, таким как nginx, заключается в том, что его создатели специально разработали его, сделав компромисс для простоты.
Прежде всего, ничто не мешает вам развернуть Unicorn без обратного прокси. Однако это не очень хорошая идея; посмотрим почему.
Unicorn следует философии Unix, которая заключается в том, чтобы делать одну вещь и делать это хорошо , то есть обслуживать быстрых клиентов с низкой задержкой (посмотрим, что это значит позже). Тот факт, что Unicorn предназначен для быстрых клиентов с низкой задержкой , также означает, что он не очень хорош с медленными клиентами с высокой задержкой , что действительно так. Это одно из слабых мест Unicorn, и именно здесь вступает в игру обратный прокси-сервер: он находится перед Unicorn и заботится о тех медленных клиентах (позже мы увидим как ).
К счастью, такой обратный прокси уже существует и называется nginx .
Решение работать только с быстрыми клиентами, значительно упрощает проектирование Unicorn и позволяет использовать намного более простую и меньшую кодовую базу за счет некоторой дополнительной сложности в отделе развертывания (т. Е. Вам нужно также развернуть nginx в дополнение к Unicorn ).
Альтернативным решением может быть разработка Unicorn таким образом, чтобы ему не требовался обратный прокси-сервер. Однако это означает, что ему придется реализовать дополнительную функциональность, чтобы делать все то, что сейчас делает nginx, что приводит к более сложной кодовой базе и большему количеству инженерных усилий.
Вместо этого его создатели приняли решение использовать существующее программное обеспечение, проверенное в бою и очень хорошо спроектированное, чтобы не тратить время и энергию на проблемы, уже решаемые другим программным обеспечением.
Но давайте разберемся с техническим вопросом и ответим на ваш вопрос:
Почему Unicorn нужно развертывать вместе с nginx?
Вот некоторые из основных причин:
Unicorn использует блокировку ввода / вывода для клиентов
Использование обратного прокси означает, что Unicorn не требуется для использования неблокирующего ввода / вывода. Вместо этого он может использовать блокировку ввода-вывода, которая по своей природе проще и понятнее для программиста.
Также как документ DESIGN гласит:
[Использование блокирующего ввода-вывода] позволяет использовать более простой путь кода в интерпретаторе Ruby и сократить количество системных вызовов.
Однако это также имеет некоторые последствия:
Ключевой момент № 1: Unicorn не работает с медленными клиентами
(для простоты мы предполагаем установку с 1 рабочим-единорогом)
Поскольку используется блокирующий ввод / вывод, работник Unicorn может обслуживать только одного клиента за раз , поэтому медленный клиент (т. Е. Один с медленным соединением) будет эффективно держать работника занятым для более длительное время (чем мог бы сделать быстрый клиент). В то же время другие клиенты будут просто ждать, пока работник снова освободится (т.е. запросы будут накапливаться в очереди).
Чтобы обойти эту проблему, перед Unicorn развернут обратный прокси-сервер, который полностью буферизует входящих запросов и ответов приложения, а затем отправляет каждый из них сразу (он же кормит их ложкой) для Unicorn и клиентов соответственно. В связи с этим можно сказать, что обратный прокси-сервер «защищает» Unicorn от медленных сетевых клиентов.
К счастью, Nginx - отличный кандидат на эту роль, поскольку он предназначен для эффективной обработки тысяч сотен одновременно работающих клиентов.
Крайне важно, чтобы обратный прокси-сервер находился в той же локальной сети, что и Unicorn (обычно на той же физической машине, которая связывается с Unicorn через доменный сокет Unix), чтобы задержка в сети была минимальной.
Таким образом, такой прокси эффективно играет роль быстрого клиента , который Unicorn предназначен для обслуживания в первую очередь, поскольку он передает запросы Unicorn fast и удерживает рабочихзанят в течение кратчайшего возможного промежутка времени (по сравнению с тем, сколько времени будет делать клиент с медленным соединением).
Ключевой момент # 2: Unicorn не поддерживает HTTP / 1.1 keep-alive
Поскольку Unicorn использует блокирующий ввод / вывод, это также означает, что он не может поддерживать функцию поддержания активности HTTP / 1.1, поскольку постоянные соединения медленных клиентов быстро займут все доступные рабочие Unicorn.
Поэтому, чтобы использовать поддержку HTTP, угадайте, что: используется обратный прокси.
nginx с другой стороныd, может обрабатывать тысячи одновременных соединений, используя всего несколько потоков.Следовательно, он не имеет ограничений параллелизма на сервере, как у Unicorn (который по существу ограничен количеством рабочих процессов), что означает, что он может нормально обрабатывать постоянные соединения.Подробнее о том, как это работает на самом деле, можно узнать здесь .
Именно поэтому nginx принимает поддерживающие соединения от клиентов и передает их Unicorn через обычные соединения через обычно Unix-сокет.
Пункт № 3: Unicorn не очень хорош в обслуживании статических файлов
Опять же, обработка статических файлов - это то, что Unicorn может делать, но не предназначен для эффективной работы.
С другой стороны, обратные прокси, такие как nginx, хотя и гораздо лучше (т.е. sendfile(2) и кэширование).
Больше
Тамдругие пункты, описанные в документе PHILOSOPHY (см. «Повышенная производительность за счет обратного прокси» ).
См. также некоторые основные функции nginx .
Мы видим, что, используя существующее программное обеспечение (например, nginx) и следуя философии Unix «делать одно и делать хорошо», Unicorn может следовать более простому дизайну и реализации, поддерживаябыть эффективным в обслуживании приложений Rack (например,ваше приложение Rails).
Для получения дополнительной информации обратитесь к документам Unicorn философия и design , которые более подробно объясняют выбор, лежащий в основе дизайна Unicorn и почему nginx считается хорошимобратный прокси для Unicorn.