Инфраструктура веб-приложений - PullRequest
4 голосов
/ 27 октября 2008

Я специально закодировал несколько корпоративных приложений для средних и крупных организаций для внутреннего использования (некоторые с минимальным внешним воздействием). Теперь у меня есть планы для веб-проекта, который (надеюсь) может увидеть большую базу пользователей с большим ежедневным трафиком, чем мои предыдущие проекты. Очевидно, я хочу, чтобы мой дизайн был масштабируемым и обслуживаемым. Проблема в том, что с точки зрения физического расположения (серверы / виртуальные машины) я не знаю, чего ожидать.

Вопрос: какие есть хорошие ресурсы для этого? Книги? Веб-сайты? Я нашел много о масштабируемом дизайне приложений, но ничего о масштабируемом физическом дизайне.

Ответы [ 2 ]

3 голосов
/ 27 октября 2008

Трудно дать точный ответ, не зная, какие технологии вы планируете использовать. Подход к приложению не может полностью не знать о планируемой физической инфраструктуре, если масштабирование является основным фактором.

Кэширование должно быть большой проблемой. Также способы расширения аппаратного обеспечения, где живут ваши данные.

Очень интересное и поучительное чтение - это реальная биография живого журнала, история масштабирования и то, как они увеличили свое физическое присутствие с огромным ростом своего веб-сайта. Одним из главных результатов их работы стала новая технология кэширования memcached, которая теперь используется FaceBook среди других. Это удивительно честно.

2 голосов
/ 27 октября 2008

Блог High Scalability хорош. Вы можете посмотреть на некоторые из их примеров, которые касаются физических частей больших сайтов. Я бы сказал, что обычной техникой физического масштабирования первого уровня будет балансировка нагрузки. Это довольно легко, но в самом простом случае у вас все еще есть база данных, которая является потенциальным узким местом. Большинство физических частей масштабирования требуют, чтобы вы просто добавили больше, и возникают реальные проблемы, когда вы вынуждены использовать только одно из чего-либо.

...