Що мені робити, щоб розробити веб-сайт із високим трафіком?

Які найкращі практики слід застосовувати для веб-сайту, який потребує "масштабування", щоб обробити потенціал? Це особливо актуально зараз, коли люди розглядають хмару, але, можливо, їх не вистачає.

Мені цікаво почути все, що ви вважаєте найкращою практикою, від завдань на рівні розвитку, до інфраструктури, управління.

Дизайн для Concurrency

Тобто, коли ви кодуєте, намічайте, щоб було кілька потоків. Плануйте загальний стан (часто просто db). План на кілька процесів. План фізичного розподілу.

Це дозволяє розподілити вашу систему на декількох машинах і в декількох процесах з балансуванням навантаження. Це дозволяє вам працювати надлишкові процеси у разі відмови, і якщо вам потрібно змінити систему на місці, вам не доведеться вбивати всі сервіси для цього.

Ви можете розглянути кілька речей:

• Відокремлення сторінок для читання та запису вашого зберігання даних.
  
  • CQRS / Sourcing подій
  • CQS
  • Повідомлення / Актори
• Уникання спільного процесу та стану потоку
  • Отже, уникайте блокування
  • Ви можете уникнути цього за допомогою системи типів, створивши свої класи, структури та інші типи даних, які не змінюються, тобто не змінюються після побудови. Особливо для складних абстрактних типів даних це працює напрочуд добре (наприклад, реалізація jQuery)
• Не блокує потоки веб-сервера на IO. Якщо ви використовуєте ASP.Net, використовуйте асинхронні сторінки / дії з бібліотекою шаблонів APM / паралельних завдань (TPL)
• Не збереження навантажень стану у словнику користувача-сеансу
  • Це потрібно перемістити через нитки, коли в IIS відбувається міграція потоків.
  • Маючи інтелектуальну маршрутизацію, таким чином, що незахищені / статичні ресурси не подаються з тією ж рамкою програми (наприклад, ASP.Net), що додає накладні витрати. Подивіться, наприклад, різні веб-сервери.
• Написання коду передачі продовження з асинхронним шаблоном робочого процесу (наприклад, bind (haskell) /callcc/Tasks.ContinueWith/Fy's async)
• Використовуйте теорію черги, щоб розрахувати, де можуть виникнути ваші вузькі місця
• Для моделей зчитування та іншого стану додатків використовуйте оновлення, а не натягування. Наприклад, через 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 намагаємось переконатися, що наші веб-сайти масштабуються без втрати часу. Це означає, що вам потрібно вміти знати, що робить ваш код і де він це робить. Навіть якщо ви тестуєте іншу машину, ви не можете зайняти занадто багато часу для масштабування. Більшість людей починають лише тоді, коли майже пізно, сумно. Ви можете оптимізувати лише один раз, коли ви це зробите, на мою думку.