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

Question

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

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

1. Единая точка входа, страницы данных в базе данных, запряженных связывая переменную GET с записью базы данных (? PageId = безотносительно)

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

3. MVC (Хорошо, ребята, я все для этого, но не могу понять концепцию, кроме проверки всех учебников и фреймворков там, они хранят «вид» «В базе данных? Мне кажется, из примеров, что если у вас 1000 страниц такого же типа, они могут быть сформированы 1 моделью, но Мне все равно нужно иметь 1000 файлов «просмотров»?)

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

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

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

7. Что-то не упоминается ...

Спасибо ,

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

Единая точка входа, страницы данные в базе данных , запряженные ассоциирования GET переменных с записью базы данных (? PageId = безотносительно)

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

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

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

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

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

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

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

http://codeigniter.com/tutorials/

Наслаждайтесь.