Рекомендуемая структура сайта с высоким трафиком

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

Главный вопрос: Какой подход вы бы предприняли при создании большого веб-сайта, который, как ожидается, будет расти во всех отношениях?

  • Одиночная точка входа, данные страниц в базе данных, вытягиваются путем связывания переменной GET с вводом базы данных (? pageid = whatever)

  • Одиночная точка входа, данные страниц в отдельных файлах, включаемые на основе переменной GET (? pageid = what бы include what.php)

  • MVC (Хорошо, ребята, я все для этого, но не могу понять концепцию, кроме проверки всех учебников и фреймворков там, хранят ли они "представление" в базе данных? Кажется мне из примеров, что если у вас есть 1000 страниц такого же типа, они могут быть сформированы 1 моделью, но мне все еще нужно иметь 1000 файлов "взглядов"?)

  • PAC - это звучит для меня еще более логично, но не нашел много ресурсов - если это хороший способ, можете ли вы порекомендовать любые книги или ссылки?

  • DAL/DAO/DDD - я узнал об этих терминах, тщательно изучая переполнение стека перед отправкой вопроса. Не уверен, что он принадлежит к этому списку

  • Сядьте и создайте мою собственную архитектуру (возможно, если никто меня не просветит здесь:)

  • Что-то не упоминалось...

Спасибо.

Ответы

Ответ 1

Масштабируемость/доступность (с высоким трафиком) для веб-сайтов лучше всего решать ни одним из пунктов, которые вы упомянули. Особенно пункты 1 и 2; сохранение определений страниц в базе данных является абсолютным no-no. MVC и другие аналогичные шаблоны больше для ясности кода и обслуживания, а не для масштабируемости.

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

Есть книги о том, как создавать масштабируемые архитектуры, поэтому сообщение SO не сможет справиться с вопросом, но некоторые концепции высшего уровня, в каком-то конкретном порядке, являются:

  • Масштабируемость лучше всего обрабатывать, глядя на аппаратные решения. Мягкий сервер с массивом SSD-дисков может пройти долгий путь.
  • Сделать статическим все, что может быть статичным. Служите столько, сколько можете, от веб-сервера, а не от БД. Например, многие страницы на сайтах динамически генерируют списки данных из баз данных из хранилищ данных, которые очень редко или никогда не меняются.
  • Выход кэша, который изменяется редко, и настраивает обновление кэша.
  • Создавайте динамические страницы без апатридов или асинхронных. Изучите CQRS и Event Sourcing для шаблонов, которые способствуют/облегчают масштабирование.
  • Настройте свои запросы. БД обычно является большим узким местом, поскольку это общий ресурс. Многие разработчики веб-приложений используют ORM, которые создают плохие запросы.
  • Настройте свой движок базы данных. Резервные копии, репликация, подметание, ведение журнала, все это требует всего лишь немного ресурсов от вашего движка. Настройка его может привести к более быстрой БД, которая покупает вам время с масштабированием.
  • Уменьшить количество HTTP-запросов от клиентов. У каждого HTTP-соединения есть накладные расходы. Проверьте свои страницы и посмотрите, можете ли вы увеличить полезную нагрузку в каждом запросе, чтобы уменьшить общее количество отдельных запросов.

На этом этапе вы оптимизировали поведение на одном сервере, и вам нужно "масштабировать". Теперь все очень быстро усложняется. Сценарии балансировки нагрузки различных типов (ошпаривание, DNS-управление, немой балансировки и т.д.), Разделение данных чтения от данных записи на разных БД, переход к решению для виртуализации, например Google Apps, разгрузка статического контента на большую службу CDN, использование язык, например, Erlang или Scala, и распараллеливать ваше приложение и т.д.

Ответ 2

Одиночная точка входа, данные страниц в базы данных, потянутой путем связывания GET переменная с вводом базы данных (? PageId = то)

Потенциальный кошмар для обслуживания. А также для развития, если у вас есть команда из более чем 2-3 человек. Вам нужно будет создать набор строгих правил для каждого, чтобы придерживаться - усилия, которые были бы намного лучше потрачены при использовании MVC. То же самое касается 2.

MVC (ладно, ребята, я все для этого, но не может понять концепцию, кроме проверка всех учебников и фреймворков там они хранят "вид" в база данных? Кажется мне из примеров что если у вас 1000 страниц того же они могут быть сформированы 1 моделью, но мне все еще нужно иметь 1000 "views" файлы?)

Это зависит от количества макетов страниц. Большинство фреймворков MVC позволяют работать со структурированными представлениями (т.е. Представлениями главной страницы, под-представлениями). Подумайте о виде HTML-шаблона для веб-страницы. Сколько шаблонов и вспомогательных шаблонов вам нужно, именно то, сколько у вас будет просмотра. Я считаю, что большинство веб-сайтов могут уйти с до 50 основных видов и до 100 просмотров, но это очень большие сайты. Посмотрев на некоторые сайты, которые я запускаю, он больше похож на 50 просмотров.

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

Это так. DDD отлично, если вам нужны мета-представления или метамодели. Скажем, если все ваши модели очень похожи по своей структуре, но отличаются только используемыми таблицами базы данных, а ваши представления почти сопоставляют модели 1:1. В этом случае это хорошее время для DDD. Хорошим примером является некоторое программное обеспечение ERP, в котором вам не нужен отдельный дизайн для всех таблиц базы данных, вы можете использовать один и тот же способ выполнения всех операций CRUD. В этом случае вы, вероятно, могли бы уйти с одной моделью и несколькими представлениями - все они генерировались динамически во время выполнения с использованием метамодели, которая сопоставляет столбцы, типы и правила базы данных с логикой языка программирования. Обратите внимание, что для создания качественного DDD-устройства требуется некоторое время и усилия, чтобы ваше приложение не выглядело как взломанная программа MS Access.

Сядьте и создайте свой собственный архитектуры (возможно, если никто просвещает меня здесь:)

Если вы создаете публичный веб-сайт, вы, скорее всего, сделаете это с MVC. Очень хорошая отправная точка - посмотреть видеоуроки CodeIgniter. Это помогло мне понять, что такое MVC и как использовать его лучше, чем любой HOWTO или руководство, которое я прочитал. И они всего лишь 29 минут:

http://codeigniter.com/tutorials/

Enjoy.

Ответ 3

Я поклонник MVC, потому что мне стало легче масштабировать вашу команду, когда все имеет место и красиво и разделено. Это требует некоторого привыкания, но самый простой способ получить ручку - погрузиться.

Это определенно проверяет вашу местную библиотеку, чтобы узнать, есть ли у них книга О'Рейли по масштабированию: http://oreilly.com/catalog/9780596102357, что является хорошим местом для начала.

Ответ 4

Если вы создаете "большой" веб-сайт и не полностью понимаете MVC или веб-фреймворк, тогда CMS может стать лучшим путем, поскольку вы можете расширять его с помощью плагинов по своему усмотрению. С помощью этого маршрута вы можете больше беспокоиться о содержании и структуре страницы, а не о платформе. Пока вы выбираете соответствующую CMS.

Ответ 5

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