Аппаратное масштабирование сайта
https://stackoverflow.com/questions/36534
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Поэтому я слушал последний подкаст Stackoverflow ( эпизод 19 ), а также Джефф и Джоэл немного рассказал о масштабировании серверного оборудования по мере роста веб-сайта. Из того, что говорил Джоэл, первые несколько шагов довольно стандартны:
<Ол>Они мало говорили о том, что будет дальше. Вы добавляете больше веб-серверов? Еще один сервер базы данных? Скопировать этот кластер из трех машин в другой центр обработки данных для обеспечения избыточности? Куда идет веб-стартап в отделе оборудования?
Решение
Разумная настройка, поддерживающая «среднее» веб-приложение может развиваться следующим образом:
<Ол>На этом этапе оценка текущего положения дел поможет определить лучший путь масштабирования. Например, если нагрузка чтения высока, а содержимое не меняется слишком часто, возможно, было бы лучше подчеркнуть кэширование и ввести выделенные внешние кэши, например, Squid , чтобы избежать ненужных чтений из базы данных, хотя вам нужно будет подумать, как поддерживать когерентность кэша , обычно в приложении.
С другой стороны, если содержание меняется достаточно часто, вы, вероятно, предпочтете более распространенное решение; представить еще несколько серверов приложений и ведомых баз данных, чтобы помочь смягчить эффекты, и использовать кэширование объектов, например memcached чтобы избежать попадания в базу данных для менее изменчивого контента.
Для большинства сайтов этого, вероятно, достаточно, хотя, если вы станете глобальным явлением, вам, вероятно, захочется начать рассматривать вопрос об оборудовании в региональных центрах обработки данных и использовать приемы, такие как балансировка географической нагрузки, для направления посетителей на ближайший «кластер». К этому моменту вы, вероятно, сможете нанимать инженеров, которые действительно могут точно настроить вещи.
Вероятно, самый ценный совет по масштабированию, который я могу придумать, состоит в том, чтобы не беспокоиться об этом слишком рано; сконцентрируйтесь на разработке сервиса, который люди захотят использовать, и сделав приложение достаточно устойчивым. Некоторые простые ранние оптимизации состоят в том, чтобы убедиться, что дизайн вашей базы данных достаточно надежный, и что индексы настроены так, что вы не делаете ничего болезненно безумного; также убедитесь, что приложение генерирует заголовки управления кэшем, которые указывают браузерам, как кэшировать данные. Выполнение такого рода работы на ранних этапах проектирования может принести преимущества позже, особенно если вам не нужно переделывать всю эту работу, чтобы справиться с проблемами когерентности кэша.
Второй самый ценный совет, который я хочу дать, заключается в том, что вы не должны предполагать, что подойдет для другого веб-сайта; проверьте свои журналы, проведите некоторый анализ своего трафика и профилируйте свое приложение - посмотрите, где находятся ваши узкие места, и устраните их.
Другие советы
некоторые интересные видео:
Джоэл упомянул добавление второго центра обработки данных с такой же настройкой, а затем случайное назначение каждого пользователя. Изменения в данных регистрируются и отправляются из одного местоположения в другое, так что оба местоположения содержат все данные.
Общедоступные масштабируемые веб-архитектуры. Подходы Кэла Хендерсона (Yahoo) на Web 2.0 Expo были довольно интересными. Я думал, что есть видео, но я не смог его найти. Но вот слайды:
http://www.slideshare.net / techdude / масштабируемых веб-архитектуры-общие-шаблоны-и-подходы
Определенным следующим шагом будет кластер веб-серверов (веб-ферма) и кластерная система серверов баз данных (репликация или Oracle RAC и т. д. и т. д.)
Если вы заинтересованы в кэшировании и использовании .Net, загляните в кэширование приложений. блок в корпоративной библиотеке (конечно, используйте это вместе с другими пунктами выше).
