Создание масштабируемых веб-сервисов

Question

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

Я думал о том, чтобы объединить все в отдельные сервисы со своими собственными интерфейсами. Так, например, обмен сообщениями будет иметь интерфейс обмена сообщениями, который может иметь методы send и getMessages (), а затем веб-приложение PHP будет просто запрашивать этот интерфейс через мыло или curl или что-то в этом роде. Приложение для обмена сообщениями может быть приложением любого типа, например, приложением Java, Python или любым другим, подходящим для этой конкретной функции с собственным отдельным осколком базы данных.

Это хороший подход?

Answer 1

Modularise

Моя мысль состояла в том, чтобы объединить все в отдельные сервисы с их собственными интерфейсами.Так, например, обмен сообщениями будет иметь интерфейс обмена сообщениями, который может иметь send и getMessages () в качестве методов, а затем веб-приложение PHP будет просто запрашивать этот интерфейс через мыло или curl или что-то в этом роде

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

Несколько быстрых советов:

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

• Как и другие намекали, я бы посоветовал вам посмотреть Блог о высокой масштабируемости .
• Первый фокус на переднейпрекратите использовать YSlow / google скорость страницы . Эта оптимизация проста в реализации и может значительно повысить ее эффективность. Цитата с веб-страницы Yslow:

80% времени отклика конечного пользователя тратится на интерфейс. Большая часть этого времени связана с загрузкой всех компонентов на странице: изображений, таблиц стилей, сценариев, Flash и т. Д. Сокращение количества компонентовв свою очередь уменьшает количествоHTTP-запросов, необходимых для отображения страницы.Это ключ к более быстрым страницам.

• Я бы также посоветовал вам взглянуть на HipHop для php, который преобразует ваш php-код в C-код, который былОгромный импульс для Facebook.Цитата из статьи:

С HipHop мы сократили использование ЦП на наших веб-серверах в среднем примерно на пятьдесят процентов, в зависимости от страницы.Меньшая загрузка ЦП означает меньшее количество серверов, что означает меньшую нагрузку

• Полагаю, еще одно большое / простое улучшение, если его еще нет, - использование APC (кэш кода операции) для кэширования скомпилированного кода.Это даст вам огромный импульс (не обязательно для частей, преобразованных в HipHop).

• Если вы хотите, чтобы ваши сайты масштабировались, вы должны следовать мантре:

  RAM - новый диск

  ! Кэш, кэш, кэш! с, например, APC, memcached , redis .

• Сначала профилируйте ваш PHP-код, а затем оптимизируйте низко висящие фрукты.Я нашел этот аудио файл от Расмуса Лердорфа действительно полезным.При чтении поста в блоге вы найдете много полезных советов по повышению производительности.
• Также я хотел бы отойти от базы данных отношений в пользу, например, Cassandra .Это ход, который, как я вижу, в последнее время делают многие крупные игроки (например, Twitter, Digg, Facebook, Reddit).Вы должны будете придерживаться совершенно другого подхода, но моя ставка на то, что это будет стоить усилий.
• Поставьте все в очередь и радуйте каждого , например, beanstalkd, gearman или taskqueue .

движка приложения Google.

Answer 2

Звучит разумно в качестве первого шага, просто имейте в виду, что трафик между уровнем PHP и уровнем обмена сообщениями добавит немного задержки. Вы также можете рассмотреть:

• Кэширование данных на уровне PHP с использованием (например) memcached . Вы также можете рассмотреть возможность использования кэша веб-прокси, такого как squid

• Масштабирование вашего веб-сервера более чем на одну машину, например, путем сохранения данных сеанса в базе данных. Как только вы сможете поддерживать наличие двух веб-серверов, добавление третьего (четвертого, пятого и т. Д.) Должно быть простым. Имейте в виду, что в конечном итоге вам, возможно, придется масштабировать уровень обмена сообщениями на несколько машин.

• Использование таких инструментов, как PHP e-Accelerator, для кэширования скомпилированных скриптов; должно помочь повысить производительность веб-слоя

Есть также несколько замечательных статей по High Scalability , которые могут оказаться полезными.

И, наконец, имейте в виду, что решение легко перегрузить. Лучше всего постоянно измерять нагрузку, производительность, использование ресурсов и т. Д., А затем использовать эти данные для внесения необходимых корректировок.

Answer 3

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

Answer 4

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

веб-приложение PHP будет просто запрашивать этот интерфейс через мыло или curl

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

Конечно, если вам приходится иметь дело с несколькими языками разработки, использование интерфейса, работающего по протоколу HTTP, является очень прагматичным решением - но если вы разрабатываете интерфейс на PHP, то программируете на абстрактный API PHP (который может Мыло, Корба или другие вещи), у вас все еще есть возможность переопределить серверную часть позже.

Я не уверен, что вы подразумеваете под сообщениями. Если вы говорите об асинхронной обработке запросов, то вам нужно подумать о том, как реализовать подписчика в PHP. Это полная червя - я не видел хорошей системы обработки сообщений, написанной на PHP, - но я также не видел хорошего масштабируемого решения, написанного на Java, - и это включает в себя продукты, созданные некоторыми крупными игроками высокого класса. системы. Возможно, однажды я напишу один;) тем временем вы действительно хотите, чтобы ваша сложная (и потенциально менее надежная) бизнес-логика работала в отдельном потоке от любого вида демона подписчика - так что очевидный способ сделать это - представить цель как веб-страницу, а подписчик - как демон, который просто получает сообщения и вызывает веб-интерфейсы API.

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

НТН

С