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

Nginx:

• ssl: да
• сжать: да
• кеш: да
• бэкэнд-пул: да

лак:

• ssl: нет (stunnel?)
• сжать:?
• кеш: да (основная функция)
• бэкэнд-пул: да

HAProxy:

• ssl: нет (stunnel)
• сжать:?
• кеш: нет
• бэкэнд-пул: да (основная функция)

Намерены ли вы объединить все это перед вашими основными веб-серверами, чтобы получить некоторые из их основных преимуществ?

Кажется довольно хрупким, когда столько демонов стекаются вместе, делая похожие вещи.

Каковы ваши предпочтения при развертывании и заказе и почему?

Проще говоря..

HaProxy - лучший балансировщик нагрузки с открытым исходным кодом на рынке.
Varnish - лучший кешер статических файлов с открытым исходным кодом на рынке.
Nginx - лучший веб-сервер с открытым исходным кодом на рынке.

(конечно, это мое мнение и мнение многих других людей)

Но, как правило, не все запросы проходят через весь стек.

Все проходит через haproxy и nginx / несколько nginx.
Разница лишь в том, что вы «засовываете» лак для статических запросов.

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

В целом, эта модель соответствует масштабируемой и растущей архитектуре (если у вас нет нескольких серверов, используйте haproxy)

Надеюсь, это поможет: D

Примечание: на самом деле я также представлю Pound для запросов SSL: D
У вас может быть сервер, предназначенный для расшифровки запросов SSL и передачи стандартных запросов в стек бэкэнда: D (Это делает весь стек более быстрым и простым)

предисловие

Обновление в 2016 году. Все развивается, все серверы становятся лучше, все они поддерживают SSL, а Интернет стал еще лучше, чем когда-либо.

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

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

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

Некоторые общие и интересные развертывания

HAProxy (балансировка) + nginx (приложение php + кеширование)

Веб-сервер nginx работает под управлением php. Когда nginx уже существует, он может также обрабатывать кэширование и перенаправления.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (балансировка) + Varnish (кеширование) + Tomcat (Java-приложение)

HAProxy может перенаправить на Varnish на основе URI запроса (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (балансировка) + nginx (SSL для хоста и кеширование) + веб-сервер (приложение)

Веб-серверы не говорят на SSL, хотя ВСЕ ДОЛЖНЫ ГОВОРИТЬ SSL ( особенно эта ссылка HAProxy-WebServer с частной информацией пользователя, проходящей через EC2 ). Добавление локального nginx позволяет перенести SSL на хост. Как только nginx появится, он может также выполнить некоторое кеширование и перезапись URL.

Примечание . Перенаправление портов 443: 8080 происходит, но не является частью функций. Перенаправление портов не имеет смысла. Балансировщик нагрузки может напрямую обращаться к веб-серверу: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

Промежуточное

HAProxy: балансировщик нагрузки

Основные характеристики :

• Балансировка нагрузки (TCP, HTTP, HTTPS)
• Несколько алгоритмов (циклический перебор, исходный IP, заголовки)
• Постоянство сессии
• Прекращение SSL

Аналогичные альтернативы : nginx (многоцелевой веб-сервер, настраиваемый в качестве балансировщика нагрузки)
Различные альтернативы : Облако (Amazon ELB, балансировщик нагрузки Google), Аппаратное обеспечение (F5, fortinet, citrix netscaler), Другое и во всем мире (DNS, anycast, CloudFlare)

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

За исключением случаев, когда вы хотите очень дешево ИЛИ быстро и грязно ИЛИ у вас нет доступных навыков, тогда вы можете использовать ELB: D

За исключением случаев, когда вы работаете в банковском / правительственном / аналогичном подразделении, которому требуется использовать собственный центр обработки данных с жесткими требованиями (выделенная инфраструктура, надежное переключение при отказе, 2 уровня брандмауэра, средства аудита, SLA для оплаты x% за минуту простоя, все в одном) Вы можете поместить 2 F5 на верхнюю часть стойки, содержащей ваши 30 серверов приложений.

За исключением случаев, когда вы хотите пройти 100k HTTP (S) [и мульти-сайтов], вы ДОЛЖНЫ иметь несколько HAProxy с уровнем [глобальной] балансировки нагрузки перед ними (cloudflare, DNS, anycast). Теоретически, глобальный балансировщик может напрямую общаться с веб-серверами, позволяя отказаться от HAProxy. Обычно, однако, вы ДОЛЖНЫ оставить HAProxy в качестве общедоступной точки входа в ваш центр обработки данных и настроить расширенные параметры для справедливого баланса между хостами и минимизации дисперсии.

Личное мнение : небольшой, открытый проект с открытым исходным кодом, полностью посвященный ОДНОЙ ИСТИННОЙ ЦЕЛИ. Среди самой простой конфигурации (ОДИН файл), самого полезного и самого надежного программного обеспечения с открытым исходным кодом, с которым я сталкивался в своей жизни.

Nginx: Apache, который не сосет

Основные характеристики :

• WebServer HTTP или HTTPS
• Запускайте приложения в CGI / PHP / некоторых других
• URL перенаправление / переписывание
• Контроль доступа
• Обработка заголовков HTTP
• Кэширование
• Обратный прокси

Подобные альтернативы : Apache, Lighttpd, Tomcat, Gunicorn ...

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

Что делает nginx и когда вы должны его использовать?
Веб-сервер предназначен для запуска приложений. Когда ваше приложение разработано для работы на nginx, у вас уже есть nginx, и вы также можете использовать все его функции.

За исключением случаев, когда ваше приложение не предназначено для работы на nginx и nginx нигде нет в вашем стеке (кто-нибудь покупает Java?), Тогда в nginx нет особого смысла. Функции веб-серверов, скорее всего, существуют в вашем текущем веб-сервере, а другие задачи лучше решать с помощью соответствующего специального инструмента (HAProxy / Varnish / CDN).

За исключением случаев, когда вашему веб-серверу / приложению не хватает функций, их сложно настроить и / или вы предпочитаете умирать, чем смотреть на это (Gunicorn кто-нибудь?), Тогда вы можете поместить nginx вперед (то есть локально на каждом узле) для выполнения URL переписывать, отправлять перенаправления 301, обеспечивать контроль доступа, обеспечивать шифрование SSL и редактировать заголовки HTTP на лету. [Это функции, ожидаемые от веб-сервера]

Лак: Кеширующий сервер

Основные характеристики :

• Кэширование
• Расширенное кэширование
• Мелкозернистое кэширование
• Кэширование

Аналогичные альтернативы : nginx (многоцелевой веб-сервер, настраиваемый в качестве сервера кэширования).
Различные альтернативы : CDN (Akamai, Amazon CloudFront, CloudFlare), аппаратное обеспечение (F5, Fortinet, Citrix Netscaler)

Что делает Varnish и когда вы должны его использовать?
Это делает кеширование, только кеширование. Обычно это не стоит усилий, и это пустая трата времени. Попробуйте вместо CDN. Имейте в виду, что кэширование - это последнее, о чем вы должны заботиться при запуске сайта.

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

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

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

Статическое кеширование переоценено в 2016 году

Кэширование практически не требует настройки, денег и времени. Просто подпишитесь на CloudFlare, или CloudFront, или Akamai, или MaxCDN. Время, необходимое для написания этой строки, больше, чем время для настройки кэширования И пиво, которое я держу в руке, дороже, чем средняя подписка CloudFlare.

Все эти сервисы работают "из коробки" для статических * .css * .js * .png и других. Фактически, они в основном соблюдают Cache-Controlдирективу в заголовке HTTP. Первым шагом кеширования является настройка ваших веб-серверов для отправки правильных директив кеша. Не имеет значения, какой CDN, какой Varnish, какой браузер посередине.

Вопросы производительности

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

Я провел быстрое тестирование производительности для последнего проекта, над которым работал. Один экземпляр tomcat может обслуживать от 21 000 до 33 000 статических файлов в секунду по протоколу HTTP (тестирование файлов от 20 до 12 КБ с различным числом соединений HTTP / клиент). Устойчивый исходящий трафик превышает 2,4 Гбит / с. Производство будет иметь только интерфейсы 1 Гбит / с. Не может быть лучше, чем оборудование, нет смысла даже пытаться Varnish.

Комплекс Кеширования Изменение Динамического Контента

Серверы CDN и кэширования обычно игнорируют URL с такими параметрами, как ?article=1843, они игнорируют любой запрос с использованием cookie-файлов сеансов или аутентифицированных пользователей, а также игнорируют большинство типов MIME, включая application/jsonfrom /api/article/1843/info. Доступны варианты конфигурации, но, как правило, они не детализированы, а «все или ничего».

Varnish может иметь собственные сложные правила (см. VCL) для определения того, что кэшируется, а что нет. Эти правила могут кэшировать конкретное содержимое по URI, заголовкам и текущему куки пользователя, типу MIME и содержимому ВСЕ ВМЕСТЕ. Это может сэкономить много вычислительной мощности на веб-серверах для некоторой очень специфической схемы загрузки. Вот тогда Лак удобен и УДИВИТЕЛЬНЫЙ.

Заключение

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

Это оказывается довольно долго (6 часов, чтобы написать. OMG!: O). Может быть, я должен начать блог или книгу об этом. Забавный факт: длина ответа не ограничена.

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

Вы должны иметь в виду, что вы говорите о трех твердых продуктах. Как правило, вам не нужно балансировать их нагрузку. Если вам нужен передний SSL, тогда nginx в качестве обратного прокси-сервера подойдет. Если вам это не нужно, тогда лак на передней панели вполне подойдет. Затем вы можете поставить haproxy для балансировки нагрузки ваших приложений. Иногда вам также может понадобиться переключиться на разные фермы серверов на самом haproxy, в зависимости от типов файлов или путей.

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

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

Надеюсь, это поможет!

Все остальные ответы до 2010 года, следовательно, добавление обновленного сравнения.

Nginx

• Полный веб-сервер, другие функции также могут быть использованы. Например: HTTP-сжатие
• Поддержка SSL
• Очень легкий вес, так как Nginx был спроектирован так, чтобы быть легким с самого начала.
• Кэширование возле лака
• Близко к производительности балансировки нагрузки HAProxy

лакировка

• лучше всего подходит для сложных сценариев кэширования и интеграции с приложениями.
• лучший статический файловый кешер
• Без поддержки SSL
• Память и процессор

HAproxy

• лучший балансировщик нагрузки, для передовых функций балансировки нагрузки, сравнимый с аппаратными балансировщиками нагрузки
• SSL поддерживается с 1.5.0
• Проще, будучи просто tcp прокси без реализации http, что делает его быстрее и менее подверженным ошибкам.

Таким образом, лучший метод, кажется, реализует их все в соответствующем порядке.

Тем не менее, для общего назначения Nginx лучше всего, так как вы получаете производительность выше среднего для всех: кеширование, обратное проксирование, балансировка нагрузки , с минимальными затратами на использование ресурсов. И тогда у вас есть SSL и полные возможности веб-сервера.

Varnish поддерживает балансировку нагрузки: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx поддерживает балансировку нагрузки: http://wiki.nginx.org/NginxHttpUpstreamModule

Я бы просто настроил это с помощью лака + stunnel. Если бы мне понадобился nginx по какой-то другой причине, я бы просто использовал nginx + лак. Вы можете заставить nginx принимать SSL-соединения и использовать их для прокси, а затем разговаривать о лаке с nginx через http.

Некоторые люди могут добавить nginx (или Apache), потому что это несколько более универсальные инструменты, чем Varnish. Например, если вы хотите преобразовать контент (например, используя XDV, фильтры Apache и т. Д.) На уровне прокси, вам понадобится один из них, потому что Varnish не может сделать это сам по себе. Некоторые люди могут быть просто более знакомы с конфигурацией этих инструментов, поэтому проще использовать Varnish в качестве простого кэша и выполнять балансировку нагрузки на другом уровне, потому что они уже знакомы с Apache / nginx / haproxy в качестве балансировщика нагрузки.