Мне интересно узнать об инфраструктуре веб-приложения ... это сеть клонированных серверов с таким же точным приложением / исходным кодом, сеть клонированных серверов баз данных и сеть серверов мультимедиа / ресурсов, находящихся за сетью серверы балансировки нагрузки? Если да, требуется ли веб-приложению какие-либо функции, чтобы облегчить это?
Вау, это очень широкий вопрос :) Это не по теме serverfault, так что, вероятно, через некоторое время он будет закрыт. Но поскольку сегодня субботний день, я настроен рассказывать истории, поэтому вот ответ, примерно основанный на упрощенной версии того, как мы развивали компанию, в которой я сейчас работаю.
Я предпочитаю сокращенный ответ: это зависит от обстоятельств. Не существует рецепта «вот как вы создаете веб-приложение», хотя есть несколько общих шаблонов.
В вашем вопросе предполагается, что веб-приложение работает на нескольких серверах, хотя это не обязательно так. Любой веб-сайт можно рассматривать как веб-приложение. Что-то столь же простое, как блог, - это веб-приложение с базой данных, кодом и статическими активами в одном блоке без какой-либо высокой доступности. Так запускается большинство запускаемых веб-приложений. Что будет, если они вырастут?
В какой-то момент они перерастают один сервер, поэтому они масштабируются: разделяют базу данных и сервер приложений (который также выполняет все статические ресурсы). А любой неживой код, например cronjobs, можно перенести на другой сервер. Бизнес сохранен .... пока.
Потому что здоровый бизнес тоже перерастет это. Серверы приложений, как правило, легко масштабируются, поэтому вы часто увидите, что люди используют набор серверов приложений за парой балансировщиков нагрузки. Правильно настроенные среды используют что-то вроде puppet или func, чтобы поддерживать их синхронизацию, и использовать метод развертывания для своего кода, который будет выполнять развертывание / откат без видимых пользователем простоев, играя с балансировщиком нагрузки. Подобная настройка позволяет масштабировать серверы приложений по горизонтали до довольно большого размера.
Но затем, конечно, база данных становится загруженной, поэтому база данных будет увеличивать набор ведомых устройств, чтобы разгрузить операции чтения. И, возможно, будет построен слой кеширования, чтобы полностью избежать чтения из баз данных. Затем, когда мастер становится слишком занятым, чтобы обрабатывать все записи, данные разделяются на несколько цепочек репликации. Если ваши данные легко сегментировать и реплицировать, это также дает вам большой запас для масштабирования.
В то же время ваш бизнес вырос настолько, что пропускная способность и объем статического контента также становятся проблемой, поэтому статические ресурсы больше не обслуживаются серверами приложений, а только выделенным набором серверов. Возможно, с CDN впереди, чтобы помочь справиться с входящей полосой пропускания.
Сделав все простые вещи, теперь становится интересно. К тому времени, как вы достигнете этой шкалы, вы, вероятно, захотите избежать простоев. Итак, вы смотрите на более высокие варианты доступности для оставшихся единичных точек отказа (например, мастеров баз данных). Вы смотрите на аварийное восстановление, если ваш основной центр обработки данных выйдет из строя. И вы также станете мишенью для различных злоумышленников в Интернете. DDOS-атаки и попытки взлома периметра вашей безопасности - это постоянная угроза, с которой вам нужно бороться.
И нужна ли серверу приложений какая-то функция, чтобы справиться со всем этим? Нет, но ваша среда делает. Лучше всего, чтобы серверы, ориентированные на клиентов, были простыми и быстрыми, и иметь интеллектуальные механизмы управления для развертывания, проверки согласованности, мониторинга и обработки атак. Это позволяет серверам приложений сосредоточиться на обслуживании клиента, что и приносит прибыль.
Приложение может находиться на одном или нескольких серверах. Обычно несколько серверов будут почти идентичными и будут использовать одну и ту же кодовую базу. Количество веб-серверов и серверов баз данных будет зависеть от ваших требуемых ресурсов и должно иметь возможность увеличивать и уменьшать масштаб по мере необходимости.
Балансировка нагрузки должна быть невидимой как для конечного пользователя, так и для самого приложения. Хотя некоторым приложениям, возможно, потребуется учитывать балансировку нагрузки, большинство веб-приложений, по моему опыту, будут работать нормально в темноте.