Назад | Перейти на главную страницу

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

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

Мой опыт - я разработчик, который в основном работал над пользовательскими интерфейсами и работал с Flash и PHP над разработкой функциональности приложения, которое позволяет пользователям загружать изображения и видео для публикации в Интернете.

Архитектура системы следующая -

  1. единый веб-сервер, который также действует как сервер базы данных (MySQL). Этот сервер находится в пакете управляемого хостинга от проверенной и надежной хостинговой компании. Веб-сервер обслуживает страницы PHP и Flash SWF, которые являются основными компонентами пользовательского интерфейса.
  2. Корзины Amazon S3 для хранения изображений, видео и аудио файлов пользователей.
  3. Компоненты пользовательского интерфейса - это либо страницы PHP, либо файлы Flash SWF, например, изображения и видео просматриваются через файлы SWF Flash, которые запрашивают базу данных через службу AMFPHP, чтобы получить URL-адреса изображений и видеофайлов для загрузки. Затем они поступают из корзин Amazon S3. Другой FLash SWF обрабатывает загрузку и отправку файлов в сценарий PHP, работающий в экземпляре EC2 в Amazon Cloud.
  4. Сервер загрузки для управления загрузкой изображений, видео и аудио. Это инстанс Amazon EC2, работающий за Elastic Load Balancer, настроенным для добавления дополнительных инстансов, когда мощность ЦП достигает 80%.
  5. Мы также используем сторонний сервис, который также работает на Amazon EC2 для перекодирования видеофайлов.

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

Аппаратное / архитектурное масштабирование -

Насколько я понимаю, первыми шагами здесь будут разделение веб-сервера и базы данных и создание отдельного сервера базы данных, размещение веб-сервера за балансировщиком нагрузки и, в конечном итоге, получение конфигурации главный / подчиненный для серверов баз данных. Что я должен попросить сделать свою хостинговую компанию? Какие проблемы связаны с этим и каковы последствия для таких вещей, как мои службы AMFPHP, различные типы запросов - запись и чтение? У меня есть отдельный сценарий, содержащий сведения о подключении к базе данных, который включается в сценарий globals.php, поэтому я могу легко обновить сведения о подключении за один шаг. Я прав, что в конфигурации главный / подчиненный все записи обычно идут на главный сервер, а чтения - с подчиненного? Означает ли это, что мне нужно будет просмотреть все мои запросы к базе данных и убедиться, что если это запрос «ОБНОВЛЕНИЕ» или «УДАЛЕНИЕ», он отправляется на главный сервер базы данных? В моем коде PHP запросы к базе данных распределены по сценариям и вызываются из функций по мере необходимости. Я немного прочитал об абстракции базы данных, но не до конца понимаю значение этого подхода.

Оптимизация кода для масштабирования -

Что мне нужно подумать об изменении кода, чтобы сделать его более масштабируемым? На какие общие вещи в PHP влияет масштабирование?

Безопасность -

Какие общие вещи, относящиеся к безопасности, мне нужно знать, когда я думаю о работе с большими объемами.

Оптимизация базы данных, процедуры резервного копирования и восстановления -

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

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

Все советы / впечатления / предложения получены с благодарностью

ура!

Просто несколько указателей, которые будут полезны после моего закрытия. Считайте чтение:

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

Этот вопрос слишком общий, чтобы здесь отвечать - предлагаю прочитать highscalability.com