Ощутимые преимущества разделения веб-приложений и веб-сервера?
Мы разрабатываем и поддерживаем веб-приложения; и в нашей текущей настройке; мы используем трехуровневую систему сервера баз данных, сервера приложений и веб-сервера.
Все идет нормально.
Проблема, с которой мы сталкиваемся, заключается в том, что, хотя теоретически эта установка предназначена для того, чтобы помочь нам сбалансировать нагрузку между этими машинами и при необходимости вставить новые осколки; на практике нагрузка, которую это создает на нашу закулисную сеть, становится серьезным узким местом.
Существует также вопрос обслуживания статических файлов; из-за нашей нынешней настройки; они должны либо обслуживаться приложением (пожирая наши процессы FastCGI, доступные для обработки входящих запросов), либо использовать веб-сервер в качестве локального прокси-сервера на компьютере, на котором выполняется приложение.
Тогда возникает вопрос:
Было бы просто свалить веб и сервер приложений в один; с упрощением конфигурации это приносит; и прямой доступ (локальные сокеты, а не TCP); а также возросшая способность обслуживать статические файлы через веб-сервер, вероятно, приведет к повышению производительности; или есть факторы, которые я пропустил?
1 ответ
Вообще говоря, я фанат разделенных архитектур: ферма серверов БД, ферма серверов "публичный www" (коммерческий веб-сайт) и ферма серверов приложений - возможно, с другими уровнями промежуточного программного обеспечения по мере необходимости.
Логика этого устарела - в основном, общедоступному www-серверу не нужно иметь доступ к каким-либо конфиденциальным данным, поэтому некоторые любопытные хакеры, взбирающиеся на www.mycompany.com, могут скомпрометировать наш маркетинговый сайт, но они не получили что-нибудь еще.
Вот несколько других общих идей...
Re: нагрузка на подсобную сеть, если мы говорим о нагрузке на трафик от связи с вашими хостами FastCGI, я бы сказал, что установление веб-сервера на этих машинах и предоставление им возможности напрямую общаться с внешним миром может быть хорошей идеей.
Следует помнить о том, что необходимо поддерживать изоляцию / защиту вашей базы данных в случае нарушения безопасности, что может быть аргументом для размещения ваших FastCGI-компонентов на веб-серверах и написания чего-то более легкого для общения с вашей базой данных...
(Если мы говорим о чем-то еще, дайте мне знать, и я сделаю это:-)
Re: проблема статических файлов, есть несколько способов решить эту проблему.
Разместите копию статических данных на каждом сервере, который должен отправить его.
Давайте назовем этот метод "Диск - это дешево" - он не дает вам сбросить огромную нагрузку на один ящик с вашим статическим контентом и устраняет эту единственную точку отказа. Недостатком является то, что вам нужно каким-то образом синхронизировать этот контент (сценарии развертывания, cron'd rsync, cvs / git / svn и т. Д.)Установите инфраструктуру кэширования на ваших интерфейсных серверах
Это похоже на решение "Диск дешев" выше, только у вас есть один фоновый сервер со статическим содержимым, и когда интерфейсные серверы нуждаются в этом, они кэшируют копию для $ LIFETIME, тем самым устраняя необходимость в сценариях синхронизации (инфраструктура кэширования делает это за вас).Разместите свой статический контент в сети доставки контента
Это действительно работает, только если вы не работаете с SSL - коммерческий CDN решает проблему загрузки и дает пользователям географически распределенные точки, из которых они могут получить ваш контент. Недостатком является то, что большинство браузеров подойдут, если вы сделаете это с сайтом, у которого есть SSL, если ваша CDN также не защищена (даже тогда параноидальные браузеры должны справедливо жаловаться).