Существуют ли передовые методы масштабирования специально для сайтов с большой аудиторией?

Question

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

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

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

Однако при поиске целевой аудитории гораздо более широкой аудитории, например, (надеюсь) миллионов пользователей:

• Существуют ли какие-либо передовые практики, о которых больше не нужно беспокоиться (т. Е. Стать больше незначительным больше аудитория)?
• Существуют ли какие-либо практики, которые следует придерживаться еще более строго?
• Кроме того, существуют ли какие-либо практики, которые действительно вступают в игру, когда ваша аудитория достигает некоторой критической массы [и какой будет эта критическая масса]? то есть применение искусственных ограничений, которые не будут беспокоить вас в частной сети

Примеры, с которыми я сталкивался до сих пор:

• Размещайте базы кодов, такие как jQuery в Google, так как они доставляются из CDN Google и могут обслуживаться намного быстрее, чем с ваших собственных серверов. Это также поможет снизить затраты на пропускную способность для доставки вашего сайта.
• Размещение изображений в CDN по той же причине, что и размещение вашего кода JavaScript в другом месте.

Answer 1

Я думаю, здесь нужно помнить о трех важных вещах:

а) Вы не собираетесь писать следующий твиттер / youtube / facebook / ebay / amazon / что угодно. Это не случается слишком часто, поэтому это большой случай ЯГНИ.

б) Если вам действительно удастся написать один из них, скорее всего, у вас будет возможность переписать приложение несколько раз.

c) Единственный объектный урок любого из типов архитектуры, который публично говорил об этих приложениях, заключается в том, что горизонтальное масштабирование - это путь. Вертикальные максимумы очень, очень быстро.

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

Answer 2

Полагаю, это зависит от того, к чему стремятся «треугольники» давлений: CAP (согласованность, доступность и допуск к разделу). Например. "C" может иметь только столько, когда сталкивается с перебоями в сети, которые влекут за собой "P".

В настоящее время может показаться, что акцент делается больше на предоставлении «хорошего пользовательского опыта», который, кажется, зависит от «времени на результат» (например, наличие полной веб-страницы на рабочем столе пользователя): это переводит на инвестиции (среди другие вещи) больше со стороны "A" и "P", чем со стороны "C".

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

Конечно, я только царапаю поверхность проблемы.

Answer 3

Я бы проверил YSlow и следовал бы их рекомендациям относительно улучшения производительности.

Answer 4

@ jldupont - Только что посмотрел презентацию, на которую вы ссылались. Одна вещь, которую я не понял, это то, что «распределенные базы данных» - это пример сценария, когда вы теряете доступность, чтобы получить согласованность и разбиение на разделы. Я думаю, что для распределенных баз данных вы теряете согласованность.