предисловие
Обновление в 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). Может быть, я должен начать блог или книгу об этом. Забавный факт: длина ответа не ограничена.