Создание хорошо масштабируемых веб-сервисов
Моя команда и я посреди разработки приложения, которое должно смочь обработать довольно интенсивное движение. Не уровень Facebook, но в будущем я хотел бы смочь масштабироваться к этому без крупного кода, переписывает.
Моя мысль состояла в том, чтобы построить из модулей все на отдельные службы с их собственными интерфейсами. Таким образом, например, обмен сообщениями имел бы интерфейс обмена сообщениями, который мог бы иметь, отправляют и getMessages () как методы, и затем веб-приложение PHP просто запросило бы этот интерфейс через мыло или завихрение или что-то как этот. Коммуникационное приложение могло затем быть любым видом приложения так JAVA-приложение или Python или независимо от того, что подходило для той особой функциональности с ее собственным отдельным черепком базы данных.
Действительно ли это - хороший подход?
4 ответа
Модульность
Моя мысль заключалась в том, чтобы разделить все на отдельные службы с собственными интерфейсами. Так, например, для обмена сообщениями будет интерфейс обмена сообщениями , который может иметь методы send и getMessages () в качестве методов, а затем веб-приложение PHP просто запросит это { {1}} через мыло или завиток или что-то в этом роде
Мне нравится идея разделения всех служебных модулей (хороший принцип кодирования). Мне не нравится то, что касается SOAP :(. Я думаю, что это слишком сложно. Я бы выбрал что-то вроде JSON-RPC или что-то в этом роде.
Несколько советов:
Моя команда и я занимаюсь разработкой приложения, которому требуется для обработки довольно большого трафика. Не на уровне Facebook, но в будущем я бы хотелось бы иметь возможность масштабироваться до этого без массивного кода перезаписи.
- Как и другие намеки, я бы посоветовал вам заглянуть в блог о высокой масштабируемости .
- Сначала сосредоточьтесь на интерфейсе с использованием YSlow / google скорости страницы . Эту оптимизацию легко реализовать, и она может дать вам значительный прирост. Цитата с веб-страницы Yslow:
80% времени ответа конечного пользователя тратится на интерфейс. Большая часть этого времени уходит на загрузку всех компонентов на странице: изображения, таблицы стилей, скрипты, Flash и т. д. Уменьшение количества компонентов в свою очередь уменьшает число количество HTTP-запросов , необходимых для отображения страницы. Это ключ к более быстрым страницам.
- Я бы также посоветовал вам взглянуть на HipHop для php, который преобразует ваш php-код в C-код, что стало огромным стимулом для facebook.Цитата из статьи:
С помощью HipHop мы снизили использование ЦП на наших веб-серверах в среднем на примерно на пятьдесят процентов, в зависимости от страницы . Меньше ЦП означает меньше серверов, что означает меньше накладных расходов
- . Я полагаю, что еще одно большое / простое улучшение, если оно еще не настроено, - это использование APC (кеш кода операции) для кеширования вашего скомпилированного кода. Это даст вам огромный импульс (не обязательно для частей, преобразованных в HipHop).
Если вы хотите, чтобы ваши веб-сайты масштабировались, вы должны следовать мантре:
- Сначала профилируйте свой PHP-код, а затем оптимизируйте низко висящие плоды. Я нашел этот аудио файл от Расмуса Лердорфа действительно полезным. Читая сообщение в блоге, вы найдете много хороших советов по повышению производительности.
- Также я бы подумал о том, чтобы отказаться от базы данных отношений в пользу, например, Cassandra . Это шаг, который, как я вижу, в последнее время делают многие крупные игроки (например, twitter, digg, facebook, reddit). Таким образом вам придется придерживаться совершенно другого мышления, но я уверен, что это того стоит.
- Ставьте все в очередь и радуйте всех , например, beanstalkd , gearman или очередь задач движка приложений Google .
Это звучит разумно в качестве первого шага, просто имейте в виду, что трафик между уровнем PHP и уровнем обмена сообщениями немного увеличивает задержку. Вы также можете рассмотреть:
Кэширование данных на уровне PHP с использованием (например) memcached . Вы также можете рассмотреть возможность использования кэша веб-прокси, такого как squid
, масштабирование вашего веб-сервера на несколько машин, например, путем сохранения данных сеанса в базе данных. Как только вы сможете поддерживать 2 веб-сервера, добавление третьего (четвертого, пятого и т. Д.) Должно быть простым. Имейте в виду, что в конечном итоге вам может потребоваться масштабирование уровня обмена сообщениями на несколько машин.
Использование таких инструментов, как PHP e-Accelerator, для кэширования скомпилированных скриптов; должно помочь повысить производительность на веб-уровне
Есть несколько отличных статей о High Scalability , которые могут оказаться вам полезными.
Наконец, имейте в виду, что решение легко перестроить. Лучше всего постоянно измерять нагрузку, производительность, использование ресурсов и т. Д. По пути, а затем использовать эти данные для внесения необходимых корректировок.
Основание дизайна высокого уровня на наборе модулей - хороший способ управлять сложностью и развитием структуры (даже более того, на микроуровне), однако
веб-приложение PHP просто запрашивает этот интерфейс через soap или curl
. Это приводит к большой задержке в приложении. Я бы предложил определить API, но для любого синхронно обрабатываемого запроса запускайте как можно больше кода в одном потоке.
Конечно, если вам приходится иметь дело с несколькими языками разработки, использование интерфейса, работающего через HTTP, является очень прагматичным решением, но если вы разрабатываете интерфейс на PHP, то путем программирования на абстрактный PHP API (который может вызывать Soap, Corba или что-то еще), у вас все еще есть возможность переопределить серверную часть по-другому позже.
Я не совсем понимаю, что вы имеете в виду под сообщениями. Если вы говорите об асинхронной обработке запросов, то вам нужно подумать о том, как реализовать подписчика на PHP. Это полная банка червей - я не видел хорошей системы обработки сообщений, написанной на PHP, но я также не видел хорошего масштабируемого решения, написанного на Java, - и это включает в себя продукты, продвинутые некоторыми крупными игроками на высоком уровне. системы.Может быть, однажды я напишу такой;) А пока вы действительно хотите, чтобы ваша сложная (и потенциально менее надежная) бизнес-логика работала в отдельном потоке от любого демона подписчика, поэтому очевидный способ сделать это - выставить цель как веб-страницу, а подписчик будет работать как демон, который просто принимает сообщения и вызывает веб-интерфейсы API.
Вы действительно не хотите строить синхронную систему на основе обмена сообщениями, если вас вообще беспокоит производительность / надежность / масштабируемость.
HTH
C.
Кэш, кэш и еще раз кэш. Кэширование SQL-запросов, кэширование опкодов, избегайте многократных запросов на одно и то же. Затем используйте профилировщик в процессе работы, чтобы отслеживать, где у вас медленные точки.