Как сделать Dynamic Website High Scalable? - PullRequest
3 голосов
/ 05 августа 2010

Как мы можем сделать динамический веб-сайт или веб-сайт, который разработан на PHP и бэкэнд как MySQL, сайтом социальных сетей с высоким уровнем масштабирования?

Ответы [ 8 ]

12 голосов
/ 05 августа 2010

Посмотрите на инфраструктуру сайтов, таких как Facebook, Twitter и YouTube на Высокая масштабируемость .Они дают вам действительно хороший обзор инструментов, которые существуют (большинство из них с открытым исходным кодом и бесплатно).

Вы, вероятно, должны изучить:

  • Обратный прокси / Балансировка нагрузки(кальмар или лак)
  • Кэширование данных (memcache и memcached)
  • Возможный бэкенд в c ++
  • NoSQL (Cassandra, CouchDB, MemcacheDB)

Я написал пост на эту тему пару недель назад, если вам интересно, зацените его здесь .

7 голосов
/ 05 августа 2010

В соответствии с хорошими практиками проектирования и программирования, такими как слабая связь. Попробуйте найти лучшее решение для вашего сайта (шаблоны проектирования, оптимальные методы ОО) с учетом масштабируемости.

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

Избыточность также очень важна, как говорят до сих пор.

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

3 голосов
/ 05 августа 2010

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

Существует два типа масштабирования: вертикальное и горизонтальное. Вертикальное масштабирование - это старый подход «больше оборудования», то есть обновление сервера и / или памяти. Горизонтальное масштабирование - это правильный способ масштабирования путем добавления избыточности и охвата ресурсов на нескольких серверах. Обычно, когда люди говорят о масштабировании, они имеют в виду горизонтальное масштабирование.

Типичная веб-архитектура для масштабирования требует как минимум одного балансировщика нагрузки, двух или более веб-серверов и одного или нескольких серверов баз данных. Каждый слой масштабируется независимо и должен обрабатываться по-разному. Например, вы можете добавить дополнительные балансировщики нагрузки, чтобы сделать сайт более доступным (поэтому, если один балансировщик выйдет из строя, другие не пострадают); этот уровень не должен требовать изменений в вашем приложении, но потребует других изменений в программном обеспечении вашего DNS и веб-сервера. И наоборот, добавление серверов баз данных может повысить доступность, увеличить время отклика или и то, и другое. Изменения на уровне базы данных, вероятно, потребуют изменений в приложении, чтобы оно могло разделять операции чтения и записи на нескольких серверах.

Конечно, есть много других инструментов, которые могут использоваться для масштабирования и / или высокой доступности. Примеры включают кэширование на уровне приложений (memcached), ускорители HTTP (в основном кэширование на уровне HTTP) и альтернативные методы хранения данных.

Лучше всего помнить об этом при планировании и создании основы приложения. Нужно ли будет читать и писать с разных серверов баз данных? Как сеансы хранятся в локальной файловой системе (не масштабируемой) или в центральном кэше (масштабируемой)? Можно ли кэшировать эти объекты данных и, если да, то как долго они будут слишком устаревшими? Если вы обратите внимание на эти основные вещи, большую часть времени ваше приложение сможет масштабироваться без особой дополнительной работы с базой кода.

3 голосов
/ 05 августа 2010

Это все равно что спрашивать, как построить небоскреб, ответ сложен и зависит от многих вещей.

Но эти вопросы и предложения должны очень помочь.

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

Узнайте о MemCached!

Поставьте SQL Caching перед вашими SQL-запросами.

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

3 голосов
/ 05 августа 2010

Беспокойтесь о масштабировании, когда вам нужно беспокоиться о масштабировании, а не раньше.В этот момент вы должны знать ответ или иметь возможность нанять кого-то, кто знает.

Позвольте мне попытаться немного уточнить этот ответ.

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

Использование аппаратного обеспечения в программном обеспечении в основном позволит вам масштабировать что-либо до определенной точки.

В тот момент (когда вам нужно использовать больше оборудованияна проблему) у вас, скорее всего, достаточно базы пользователей, на которой вы либо зарабатываете деньги со своего веб-сайта / услуги, либо в случае продукта с открытым исходным кодом вы, вероятно, будете иметь следующее.Эти ресурсы предоставят вам доступ к компьютерным учёным / инженерам более высокого уровня, которые могут помочь с масштабированием.

Масштабирование на уровне снижения нагрузки на аппаратное обеспечение становится очень анти-«лучшей практикой».Вы начинаете писать код для быстрого выполнения очень специфических задач.Возьмем, к примеру, твиттер: они в основном переписали твиттер, чтобы больше не использовать ruby ​​на рельсах , а вместо этого использовать scala и разработанные твиттеры, уже успешно работающие с характеристиками производительность только ,Facebook, с другой стороны, написал собственные пакеты PHP для компиляции PHP .

1 голос
/ 14 сентября 2011

Избегайте паттерна «Front Controller».

Каждый запрос должен обрабатываться отдельно, поэтому вы можете масштабировать каждую часть индивидуально.Попытка сделать это с помощью шаблона «Front Controller» невозможна, поскольку вместо использования браузера, который на самом деле является «Front Controller», вы поместите его на свой сервер, что слишком поздно и означает, что вы не можете направить запрос науникальный ресурс.

1 голос
/ 05 августа 2010
1 голос
/ 05 августа 2010

Прежде чем вы сделаете его масштабируемым, убедитесь, что он очень доступен.Избыточность во всем - это ключ.Несколько серверов, несколько сайтов, несколько всего!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...