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

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

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

Одиночная точка входа, данные страниц в базе данных, вытягиваются путем связывания переменной 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 и быть готовыми легко добавлять новые функции в свою сеть.