Я видел, как люди рекомендуют комбинировать все это в потоке, но, похоже, у них много перекрывающихся функций, поэтому я хотел бы углубиться в то, почему вы можете захотеть пройти через 3 разные программы, прежде чем попасть на свой фактический веб-сервер.
nginx:
лак:
haproxy:
Является ли намерение объединить все это в цепочку перед вашими основными веб-серверами только для того, чтобы получить некоторые из их основных преимуществ?
Кажется довольно хрупким, когда так много демонов объединяются, выполняя похожие дела.
Каковы ваши предпочтения по развертыванию и заказу и почему?
Проще говоря..
HaProxy лучший балансировщик нагрузки с открытым исходным кодом на рынке.
Лак лучший статический файловый кэшер с открытым исходным кодом на рынке.
Nginx лучший веб-сервер с открытым исходным кодом на рынке.
(конечно, это мое и многих других мнение)
Но обычно не все запросы проходят через весь стек.
Все проходит через haproxy и nginx / несколько nginx.
Разница только в том, что для статических запросов вы "болтаете" лаком.
В целом, эта модель соответствует масштабируемой и растущей архитектуре (исключите haproxy, если у вас нет нескольких серверов).
Надеюсь, это поможет: D
Примечание: На самом деле я также представлю Pound для запросов SSL: D
У вас может быть сервер, выделенный для расшифровки SSL-запросов и передачи стандартных запросов в бэкэнд-стек: D (это делает работу всего стека быстрее и проще)
Обновление в 2016 году. Вещи развиваются, все серверы становятся лучше, все они поддерживают SSL, и Интернет стал еще лучше, чем когда-либо.
Если не указано иное, нижеследующее предназначено для профессионалов в бизнесе и стартапов, поддерживая от тысяч до миллионов пользователей.
Эти инструменты и архитектуры требуют большого количества пользователей / оборудования / денег. Вы можете попробовать это в домашней лаборатории или вести блог, но это не имеет особого смысла.
Как правило, помните, что вы хотите будь проще. Каждое добавляемое промежуточное ПО является еще одним важным элементом промежуточного программного обеспечения, которое необходимо поддерживать. Совершенство достигается не тогда, когда нечего добавить, а когда уже нечего убирать.
Веб-сервер - это 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 на основе URI запроса (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
Веб-серверы не поддерживают 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
Основные особенности:
Похожие альтернативы: 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 в качестве общедоступных точек входа в ваш центр обработки данных и настроить дополнительные параметры для справедливой балансировки между хостами и минимизации отклонений.
Личное мнение: Небольшой, автономный проект с открытым исходным кодом, полностью посвященный ОДНОЙ ИСТИННОЙ ЦЕЛИ. Среди самых простых конфигураций (ОДИН файл) самое полезное и самое надежное программное обеспечение с открытым исходным кодом, которое я встречал в своей жизни.
Основные особенности:
Похожие альтернативы: 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)
Для чего нужен лак и когда его НЕОБХОДИМО использовать?
Кеширует, только кеширует. Обычно это не стоит усилий и пустая трата времени. Вместо этого попробуйте CDN. Помните, что кеширование - это последнее, о чем вам следует заботиться при запуске веб-сайта.
Кроме когда вы запускаете веб-сайт исключительно с изображениями или видео, вам следует внимательно изучить CDN и серьезно подумать о кешировании.
Кроме когда вы вынуждены использовать собственное оборудование в собственном центре обработки данных (CDN не вариант) и ваши веб-серверы плохо справляются с доставкой статических файлов (добавление дополнительных веб-серверов не помогает), тогда Varnish - последнее средство.
Кроме когда у вас есть сайт с в основном статическим, но сложным, динамически генерируемым контентом (см. следующие параграфы), Varnish может сэкономить много вычислительной мощности на ваших веб-серверах.
Кэширование почти не требует конфигурации, денег и времени. Просто подпишитесь на 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). Может, мне стоит завести блог или книгу об этом. Интересный факт: кажется, нет ограничений на длину ответа.
Это правда, что у трех инструментов есть общие черты. Большинство настроек подходят для любой комбинации двух из трех. Это зависит от их основной цели. Принято соглашаться пожертвовать некоторым кешированием, если вы знаете, что ваш сервер приложений работает со статикой (например, nginx). Обычно жертвуют некоторыми функциями балансировки нагрузки, если вы собираетесь установить десятки или сотни серверов и не заботитесь ни об их использовании, ни об устранении неполадок. Обычно жертвуют некоторыми функциями веб-сервера, если вы собираетесь запускать распределенное приложение с множеством компонентов повсюду. И все же некоторые люди со всеми строят интересные фермы.
Помните, что вы говорите о трех твердых продуктах. Как правило, вам не нужно балансировать их нагрузку. Если вам нужен передний SSL, тогда подойдет nginx в качестве обратного прокси. Если вам это не нужно, тогда подойдет лак на лицевой стороне. Затем вы можете установить haproxy для балансировки нагрузки ваших приложений. Иногда вам также может понадобиться переключиться на разные фермы серверов на самом haproxy, в зависимости от типов файлов или путей.
Иногда вам придется защищаться от тяжелых DDoS-атак, и haproxy впереди будет более подходящим, чем другие.
В общем, вам не следует беспокоиться о компромиссе между вашими вариантами. Вы должны выбрать, как их собрать, чтобы получить максимальную гибкость для ваших нужд сейчас и в будущем. Даже если вы складываете несколько из них несколько раз, иногда это может быть правильным в зависимости от ваших потребностей.
Надеюсь, это поможет!
Все остальные ответы относятся к версии до 2010 г., поэтому добавлено обновленное сравнение.
Nginx
Лак
Haproxy
Таким образом, лучший метод, кажется, реализовывать их все в соответствующем порядке.
Однако для общего назначения, лучше всего подходит Nginx поскольку вы получаете производительность выше среднего для всех: Кеширование, обратное проксирование, балансировка нагрузки, с очень небольшими накладными расходами на использование ресурсов. И тогда у вас есть SSL и все функции веб-сервера.
Varnish поддерживает балансировку нагрузки: http://www.varnish-cache.org/trac/wiki/LoadBalancing
Nginx поддерживает балансировку нагрузки: http://wiki.nginx.org/NginxHttpUpstreamModule
Я бы просто настроил это лаком + станнель. Если бы мне понадобился nginx по какой-то другой причине, я бы просто использовал nginx + varnish. Вы можете заставить nginx принимать SSL-соединения и проксировать их для varnish, а затем общаться с nginx через http.
Некоторые люди могут добавить в смесь nginx (или Apache), потому что это несколько более универсальные инструменты, чем Varnish. Например, если вы хотите преобразовать контент (например, с помощью XDV, фильтров apache и т. Д.) На уровне прокси, вам понадобится один из них, потому что Varnish не может этого сделать сам. Некоторые люди могут быть просто более знакомы с конфигурацией этих инструментов, поэтому проще использовать Varnish в качестве простого кеша и выполнять балансировку нагрузки на другом уровне, потому что они уже знакомы с Apache / nginx / haproxy в качестве балансировщика нагрузки.