Что я должен сделать, чтобы масштабировать сайт с большим трафиком?

Какие передовые практики следует предпринять для веб-сайта, который необходимо «масштабировать» для управления пропускной способностью? Это особенно актуально сейчас, когда люди рассматривают облако, но могут упустить основные принципы.

Мне интересно услышать обо всем, что вы считаете лучшей практикой, от задач уровня разработки до инфраструктуры и управления.

Дизайн для параллелизма

То есть, когда вы пишете код, планируйте создание нескольких потоков. Планируйте общее состояние (часто только БД). Планируйте несколько процессов. План физического распределения.

Это позволяет распределить систему по нескольким компьютерам и нескольким процессам с балансировкой нагрузки. Это позволяет вам запускать избыточные процессы в случае сбоя, и в случае, если вам нужно изменить систему на месте, вам не нужно убивать все службы, чтобы сделать это.

Несколько вещей, которые вы могли бы рассмотреть:

• Разделение сторон чтения и записи в вашем хранилище данных.
  
  • CQRS / Event Sourcing
  • ОКК
  • Передачи сообщений / Актёры
• Как избежать общего процесса и состояния потока
  • Следовательно, избегая блокировки
  • Этого можно избежать с помощью системы типов, создавая неизменяемые классы, структуры и другие типы данных, то есть неизменяемые после построения. Специально для сложных абстрактных типов данных он работает на удивление хорошо (например, реализация jQuery)
• Не блокирует потоки веб-сервера на IO. Если вы используете ASP.Net, используйте асинхронные страницы / действия с шаблоном APM / библиотекой параллельных задач (TPL)
• Не сохранять нагрузки состояния в пользовательском словаре сессии
  • Это должно быть перемещено между потоками, когда миграции потоков происходят в IIS.
  • Имея интеллектуальную маршрутизацию, такую, что незащищенные / статические ресурсы не обслуживаются той же самой прикладной средой (например, ASP.Net), которая добавляет издержки. Посмотрите, например, на наличие разных веб-серверов.
• Написание кода прохождения продолжения с асинхронным шаблоном рабочего процесса (например, bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Используйте теорию очередей, чтобы рассчитать, где могут возникнуть ваши узкие места
• Используйте push-, а не pull-based обновления для моделей чтения и других состояний приложения. Например, через RabbitMQ / nServiceBus
• Используйте наименьший функционал «обработчик http»
• Для статических файлов используйте электронные теги и политики истечения срока действия кэша, чтобы веб-инфраструктура работала должным образом (например, с прокси-сервером squid).
• (Наймите меня, чтобы решить ваши проблемы масштабирования и получить учебные материалы на месте;))

Ничего не делись архитектурой.

Имея это в виду и вопреки тому, что вы можете подумать, не сразу переходите к масштабному решению. Служебная нагрузка вне системы и внутрисистемный вызов не должны быть недостаточно взвешенными. Например, требуется гораздо больше времени для установления соединения с БД через любой сетевой интерфейс, чем для локального вызова. Бюджет, сколько времени на управление, питание и настройку требуется для масштабирования по сравнению с дополнительными $ для действительно большой системы.

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

Распараллелить запросы по нескольким именам хостов

Частью стандарта HTTP является раздел, в котором говорится, что веб-клиенты будут запрашивать максимум 2 сеанса на хост DNS. Вот решение, при котором вы и ваш псевдоним www.domain.com получаете более высокий уровень параллелизма запросов, что ускоряет загрузку вашей страницы:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

По сути, это требует редактирования вашего ASP.NET HTTP Handler, чтобы чередовать целевые хосты, на которые вы отправляете клиентов, где каждый хост - это CNAME с «www».

Безопасный, быстрый, надежный DNS

Я нашел несколько веб-сайтов с высокой пропускной способностью, использующих DNS-сервер регистратора, который не имел SLA для обеспечения работоспособности или производительности. Кроме того, их серверы были расположены в Индии, и одна только латентность увеличивает вероятность того, что спуфер DNS может отравить кеш вашего клиента или промежуточный кеш провайдера. Это может привести к тому, что даже ваш трафик, защищенный SSL, будет перенаправлен без ведома.

Скорость DNS также влияет на начальное время загрузки вашего сервера до кэширования записей.

Я использую DynDNS или Neustar для большинства своих клиентов, поскольку у них довольно солидная DNS-инфраструктура (хотя это дорого, и у меня нет другой принадлежности к этим компаниям).

Я думаю, что ключ будет прост:

Есть простой код. Это означает то, что вы смотрите и понимаете. Когда вы расширяете и меняете серверы, вам нужно знать, что происходит. Вам также может понадобиться добавить кодеров, которые должны быстро понять. Хуки и XML-файлы, которые вызывают случайный код, который неочевиден, очень плохи.

Тогда вы можете проверить и найти проблемы.

Смотрите здесь: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

Мы в stellarbuild стараемся, чтобы наши сайты масштабировались без простоев. Это означает, что вам нужно знать, что делает ваш код и где он это делает. Даже если вы тестируете другую машину, вам не потребуется слишком много времени для масштабирования. К сожалению, большинство людей начинают только тогда, когда уже слишком поздно. Вы можете оптимизировать только тогда, когда вы делаете это, по моему мнению.