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

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

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

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

Надеясь это помогает!

Лак имеет поддержку выравнивания нагрузки: http://www.varnish-cache.org/trac/wiki/LoadBalancing

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

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

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

Все остальные ответы относятся к версии до 2010, поэтому добавлено обновленное сравнение.

Nginx

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

Varnish

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

Haproxy

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

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

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

Предисловие

Обновление в 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 нигде нет в вашем stack (кто-нибудь из магазинов Java?), то в nginx нет смысла. Возможности веб-сервера, вероятно, будут присутствовать на вашем текущем веб-сервере, а другие задачи лучше решить с помощью соответствующего специального инструмента (HAProxy / Varnish / CDN).

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

Varnish: Кэширующий сервер

Основные функции :

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

Аналогичные альтернативы : 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, какой браузер находится посередине.

Соображения производительности

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

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

Кеширование, сложное изменение динамического содержимого

CDN и серверы кеширования обычно игнорируют URL-адреса с такими параметрами, как ? Article = 1843 , они игнорируют любой запрос с сеансовыми cookie-файлами или аутентифицированными пользователями, и они игнорируют большинство типов MIME, включая application / json из / api / article / 1843 / info . Существуют доступные параметры конфигурации, но обычно они не являются мелкозернистыми, скорее "все или ничего".

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

Заключение

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

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