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