VolSu
26 Июня 2021
Я слышал, что PHP не масштабируется, но как Facebook на самом деле масштабирует свое приложение? Я слышал некоторые ответы, в которых говорится, что Facebook использует HHVM. Но как HHVM помогает Facebook масштабировать свое приложение?
Чтобы немного отойти от вопроса, скажу, что речь идет не только о PHP.
Существуют гораздо более быстрые и эффективные веб-серверы, чем традиционный Apache, например nginx. Веб-сервер значительно увеличивает время отклика.
Кроме того, установка Facebook широко распространена, где доступ пользователей распределен по множеству серверов. Якобы их сотни тысяч.
Кроме того, Facebook не использует только PHP.
Кроме того, большая часть тяжелой работы, связанной с пользовательским интерфейсом, выполняется на стороне клиента, в браузере ПК или мобильном приложении.
Любой, кто говорит вам, что PHP не масштабируется, несут чушь, и вам, вероятно, следует относиться к другим их техническим мнениям с большой долей скептицизма.
Не обращайте внимания на Facebook: Wordpress (крупнейшая в мире платформа для ведения блогов) написан на PHP. Википедия (один из десяти самых популярных веб-сайтов в мире) написана на PHP. Ни Wordpress, ни Википедия не нуждались в HHVM для достижения массового масштаба. В этом отношении Facebook тоже; еще до того, как HHVM существовал, это был один из лучших веб-сайтов в мире.
HHVM — это в основном экономия средств. В масштабе Facebook даже 10% -ное сокращение потребления ЦП означает экономию инфраструктуры в миллионы долларов в год, а 10% -ное сокращение потребления ЦП также, вероятно, означает более быструю загрузку страниц. Так что легко стоит потратить время Facebook на написание собственной среды выполнения PHP. И тот факт, что они могут добавлять языковые функции (код Facebook «PHP» больше не похож на обычный PHP), также увеличивает эффективность их разработчиков.
Но способность Facebook масштабироваться до миллиарда пользователей не благодаря HHVM, а благодаря тому, что в их архитектуре приложений очень мало узких мест, и, добавив больше серверов, они могут обрабатывать больше пользователей. Такая архитектура хорошо масштабируется на любом языке.
В общем, архитектура приложения определяет форму кривой, которая связывает стоимость с использованием. Чем более «масштабируемым» является приложение, тем ближе эта кривая к прямой диагональной линии. В архитектуре с узкими местами кривая резко переходит в вертикальное положение на некотором уровне использования, выше которого вы не можете увеличить емкость ни за какие деньги. (В любой архитектуре всегда есть узкое место; хитрость заключается в том, чтобы убедиться, что вы не столкнетесь с ним при использовании, которое вы действительно собираетесь получить.)
Выбор конкретного языка, базы данных или компилятора может сделать особенно нелинейную кривую немного более плоской с левой стороны, но в какой-то момент кривая все равно будет быстро расти, потому что это основной недостаток дизайна, а не деталь реализации.
Еще одна вещь, которую следует знать, заключается в том, что архитектура Facebook не возникла полностью в мозгу Марка Цукерберга. Это непрерывный эволюционный процесс, представляющий собой усилия на протяжении многих столетий, предпринятые лучшими инженерами отрасли. Выбор языка не является абсолютно несущественной частью этих усилий, но можете быть уверены, что это не то, что мешает инженерам инфраструктуры Facebook спать по ночам.