Обновить: на основе ответа Джеспера Мортенсена, вот еще немного информации. Приложения основаны на Perl's HTTP :: Демон. Я планирую развернуть их на сервере Linux.
Каждое приложение делает что-то свое. Следовательно, это не совсем балансировка нагрузки, поскольку серверы не взаимозаменяемы. Я лучше знаком с Apache, чем с чем-либо еще, но я никогда не настраивал его для прокси.
Рассмотрим сценарий, в котором несколько веб-приложений прослушивают отдельные порты (скажем, 8080 и 8888). HTML-вывод этих приложений является динамическим и всегда зависит от пользователя, поэтому его не следует кэшировать, но они будут использовать общий набор изображений, файлов CSS и JavaScript.
Возможно ли, чтобы сервер слушал www.example.com:80 перенаправление запросов на localhost:8000 для статического контента, localhost:8080 и localhost:8888соответственно для конкретных запросов приложений? Кроме того, можно ли использовать https для внешнего www.example.com а серверы на портах 8000, 8080 и 8888 использовать http?
Я читал Глава 12 в Практический mod_perl и примеры кальмаров и похоже, что это должно быть возможно, но это мой первый раз, когда я углубляюсь в прокси и обратные прокси, и поэтому я не уверен, как мне следует действовать, и я не уверен в терминологии, поэтому любые указатели / исправления также были бы очень признательны .
Я думаю, вы правы. Я не знаю, как это сделать через perl или squid, но я делаю именно это через apache. Вот мой конфиг:
<VirtualHost *:443>
ProxyPass /doc http://127.0.0.1:81/gdoc
ProxyPassReverse /doc http://127.0.0.1:81/gdoc
ProxyPass /rp01 http://server01.mydomain.local/rp01
ProxyPassReverse /rp01 http://server01.mydomain.local/rp01
ProxyPass /bugzilla http://bugzilla.mydomain.local
ProxyPassReverse /bugzilla http://bugzilla.mydomain.local
</VirtualHost>
Да, возможно, это даже достаточно стандартный функционал. К сожалению, вы не предоставляете подробностей о своей серверной среде ...
Вы можете различать сайты по многим частям запроса; но классика, конечно, отличается Полное доменное имя каждого сайта, то есть sitename1.somedomain.com, sitename2.somedomain.com, sitename3.com и так далее.
С mod_perl и Squid это похоже на Unix. Апачи mod_rewrite это, пожалуй, самый распространенный / самый старый способ добиться этого в Unix. Обратите внимание: освоение mod_rewrite для настройки безопасных прокси требует некоторой работы. (Если вы настроили небезопасный прокси-сервер, он разрешит проксирование запроса на «внешнем» участке прокси, и спамеры могут злоупотреблять этим для отправки форм и т.д. с вашего IP-адреса.)
Другой распространенный подход в Unix - иметь «облегченный» HTTP-сервер / прокси на общедоступном IP-адресе (то есть получать запросы от пользователей), а затем позволить «легковесному» серверу разветвлять запросы на «более тяжелые». Экземпляры Apache / PHP / Perl / Python. Преимущества заключаются в более производительной обработке большого количества открытых соединений и уменьшении использования оперативной памяти на сервере. nginx (EngineX) один из популярных серверов для этого, и он также имеет модуль перезаписи.
Относительно обработки HTTPS / SSL на «первом» веб-сервере; да, это хорошее решение. Вы бы просто настроили SSL как обычно и получили бы запросы прокси веб-сервера для этого имени хоста на бэкэнд-серверы. Редактировать: Обычно интерфейсный «ускоритель HTTPS» добавляет заголовки HTTP (X-Forwarded-Proto) к бэкэнд-запросу, чтобы серверные приложения могли знать, что исходный запрос пришел через зашифрованное соединение.
Здесь вы видите частичный случай балансировки нагрузки HTTP; то есть вы устанавливаете HTTP-прокси на одном компьютере и используете его для разветвления запросов другим HTTP-серверам на том же компьютере. Много хорошие программные балансировщики нагрузки для Unix-систем.
Если вы используете Windows, то новый "Маршрутизация запросов приложений"довольно хорошо. Версия 2 сейчас находится в топе лучших и значительно улучшена по сравнению с версией 1 - ее можно найти на сайте iis.net. Редактировать: Следует сказать, что никогда версии IIS не были достаточно быстрыми и масштабируемыми. Большинство пользователей IIS не утруждают себя настройкой прокси-сервера HTTP для одного сервера IIS, они просто создают виртуальные хосты с соответствующей моделью приложения на самом сервере IIS.