RoadRunner: PHP не е направен да умира, или Golang бърза на помощ

Здравей, Хабр! Ние в Badoo активно работим за производителността на PHP, тъй като имаме доста голяма система на този език и въпросът за производителността е въпрос на спестяване на пари. Повече от десет години назад създадохме за това PHP-FPM, който първоначално представляваше набор от пачове за PHP, а по-късно беше включен в официалната версия.

През последните години PHP направи значителен напредък: подобри се събирачът на боклук, повиши се стабилността — днес на PHP могат без проблеми да се пишат демони и дългоживеещи скриптове. Това позволи на Spiral Scout да се развие: RoadRunner, за разлика от PHP-FPM, не почиства паметта между заявките, което дава допълнителна производителност (въпреки че този подход усложнява процеса на разработка). В момента експериментираме с този инструмент, но засега нямаме резултати, които да споделим. За да бъде чакането по-забавно, публикуваме превод на анонса на RoadRunner от Spiral Scout.

Подходът в статията ни е близък: при решаването на нашите задачи ние също най-често използваме комбинация от PHP и Go, получавайки предимства от двата езика и не отказвайки се от един в полза на друг.

Приятно гледане!

През последните десет години създавахме приложения както за компании от списъка Fortune 500, така и за бизнес с аудитория до 500 потребители. През всичкото това време нашите инженери разработваха бекенд основно на PHP. Но преди две години нещо значително се отрази не само на производителността на нашите продукти, но и на тяхната мащабируемост — въведохме Golang (Go) в нашия технологичен стек.

Почти веднага открихме, че Go ни позволява да създаваме по-големи приложения с увеличаване на производителността до 40 пъти. С него успяхме да разширим съществуващите продукти, написани на PHP, подобрявайки ги чрез комбинация от предимствата на двата езика.

Ще разкажем как комбинацията Go и PHP помага за решаването на реални проблеми в разработката и как тя се е превърнала в инструмент, който може да реши част от проблемите, свързани с модела «умиране» на PHP.

Вашата ежедневна среда за PHP разработка

Преди да разкажем как с Go можем да оживим модела «умиране» на PHP, нека разгледаме вашата стандартна среда за PHP разработка.

В повечето случаи стартирате приложение с комбинация от уеб сървър nginx и PHP-FPM сървър. Първият обслужва статични файлове и пренасочва специфични заявки към PHP-FPM, който изпълнява PHP код. Може би използвате по-малко популярната комбинация от Apache и mod_php. Но въпреки че работи малко по-различно, принципите са същите.

Нека разгледаме как PHP-FPM изпълнява кода на приложението. Когато постъпи заявка, PHP-FPM инициализира дъщерен PHP процес и предава детайлите на заявката като част от неговото състояние (_GET, _POST, _SERVER и т.н.).

Състоянието не може да се променя по време на изпълнението на PHP скрипта, затова нов набор от входни данни може да се получи само по един начин: като се изчисти паметта на процеса и се инициализира отново.

Тази модел на изпълнение има много предимства. Не е нужно да се тревожите прекалено за консумацията на памет, всички процеси са напълно изолирани и ако един от тях "умре", той ще бъде автоматично възстановен и това няма да засегне останалите процеси. Но има и недостатъци, които се проявяват при опит за скалиране на приложението.

Недостатъци и неефективност на обикновената PHP среда

Ако сте професионален разработчик на PHP, знаете откъде да започнете нов проект — с избора на фрейм워크. Той представлява библиотеки за внедряване на зависимости, ORM-и, преводи и шаблони. И, разбира се, можете удобно да поставите всички входни данни на потребителя в един обект (Symfony/HttpFoundation или PSR-7). Фреймворците са страхотни!

Но всичко има своята цена. Във всеки фреймворк от корпоративен клас за обработка на проста потребителска заявка или запитване към БД ще трябва да заредите поне десетки файлове, да създадете многобройни класове и да парсите няколко конфигурации. Но най-лошото е, че след изпълнението на всяка задача е нужно всичко да бъде нулирано и да се започне отначало: целият код, който току-що сте инициализирали, става безполезен, защото вече не можете да обработите още една заявка с него. Кажете това на всеки програмист, който пише на друг език — и ще видите недоумение на лицето му.

PHP инженерите години наред търсиха начини за решаване на този проблем, използвайки добре обмислени методики за „лениво“ зареждане, микрофреймворкове, оптимизирани библиотеки, кеширане и т.н. Но в крайна сметка отново се налага да се нулира цялото приложение и да се започне отначало, отново и отново. (Бележка на преводача: частично този проблем ще бъде решен с появата на preload в PHP 7.4)

Може ли PHP с помощта на Go да обработва повече от един запит?

Могат да се напишат PHP скриптове, които да живеят повече от няколко минути (до часове или дни): например, cron задачи, CSV парсери, обработвачи на опашки. Всички те работят по един и същи сценарий: извлекат задача, изпълняват я, чакат следващата. Кодът постоянно се намира в паметта, спестявайки ценни милисекунди, тъй като за зареждането на фреймворка и приложението е необходимо да се изпълнят множество допълнителни действия.

Но разработването на дълготрайни скриптове не е толкова просто. Всяка грешка напълно убива процеса, диагностицирането на утечки в паметта е ужасно досадно, а отстраняването на грешки чрез F5 вече не е възможно.

Ситуацията се подобри с излизането на PHP 7: появи се надежден сборщик на отпадъци, стана по-лесно да се обработват грешки, а разширенията на ядрото сега са защитени от утечки. Все пак, инженерите все още трябва да внимават с паметта и да помнят за проблемите с състоянието в кода (има ли език, в който може да се игнорира това?). И все пак в PHP 7 ни дебнат по-малко неочаквани изненади.

Може ли да се вземе моделът на работа с дълготрайни PHP скриптове, да се адаптира към по-тривиални задачи като обработка на HTTP запитвания и по този начин да се избегне нуждата от зареждане на всичко от нула при всяко запитване?

За да се реши този проблем, първо беше необходимо да се реализира сървърно приложение, способно да приема HTTP запитвания и да ги пренасочва едно след друго на PHP работника, без да го убива всеки път.

Знаехме, че можем да напишем уеб сървър на чист PHP (PHP-PM) или с използването на C-разширение (Swoole). И макар и двата метода да имат своите предимства, не бяхме удовлетворени — искахме нещо повече. Нужен ни беше не просто уеб сървър — планирахме да получим решение, което да ни освободи от проблемите, свързани с "тежкия старт" в PHP, и което да може лесно да се адаптира и разширява за специфични приложения. Тоест, необходим ни беше сървър за приложения.

Може ли Go да помогне в това? Знаехме, че може, защото този език компилира приложения в самостоятелни бинарни файлове; той е кросплатформен; използва собствена, много елегантна, модел на паралелна обработка (concurrency) и библиотека за работа с HTTP; и накрая, ще имаме достъп до хиляди open-source библиотеки и интеграции.

Трудности при обединението на два програмни езика

Първо трябваше да определим как две или повече приложения ще комуникират помежду си.

Например, чрез прекрасната библиотека на Алекс Палаестрас, можеше да се реализира споделяне на паметта между процесите PHP и Go (подобно на mod_php в Apache). Но тази библиотека има особености, които ограничават прилагането й за решаване на нашата задача.

Решихме да използваме друг, по-разпространен подход: изграждане на взаимодействие между процесите чрез сокети/конвейери. Този подход е доказал надеждността си през последните десетилетия и е оптимизиран на ниво операционна система.

За начало създадохме прост бинарен протокол за обмен на данни между процесите и обработка на грешки при предаване. В най-простата си форма, подобен протокол изглежда като netstring с с фиксиран размер на заглавката на пакета (в нашия случай 17 байта), който съдържа информация за типа на пакета, неговия размер и двоична маска за проверка на целостта на данните.

От страна на PHP използвахме функция pack, а от страна на Go — библиотека encoding/binary.

Не ни стигна един протокол — добавихме възможността да извикваме Go услуги net/rpc директно от PHP. По-късно това много ни помогна в разработката, тъй като можехме лесно да интегрираме Go библиотеки в PHP приложения. Резултатът от тази работа може да се види, например, в друг наш open-source продукт Goridge.

Разпределение задачи между няколко PHP работника

След като реализирахме механизма за взаимодействие, започнахме да мислим как да предаваме задачите на PHP процесите по-ефективно. Когато постъпи задача, приложният сървър трябва да избере свободен работник за нейното изпълнение. Ако работникът/процесът завърши с грешка или "умре", се освобождаваме от него и създаваме нов вместо него. А ако работникът/процесът е завършил успешно, го връщаме в пула работници, налични за изпълнение на задачи.

За съхранение на пула от активни работници използвахме буфериран канал, за да се отстранят неочаквано "умрелите" работници, добавихме механизъм за мониторинг на грешки и състояния на работниците.

В резултат получихме работещ PHP сървър, способен да обработва всякакви заявки, представени в бинарна форма.

За да започне приложението ни да работи като уеб сървър, трябваше да изберем надежден PHP стандарт за представяне на всички входящи HTTP заявки. В нашия случай просто преобразуваме net/http-заявка от Go в формат PSR-7, за да бъде съвместим с повечето налични днес PHP фреймворкове.

Тъй като PSR-7 се счита за неизменяем (някой ще каже, че технически не е), разработчиците трябва да пишат приложения, които по принцип не се отнасят към заявката като към глобален обект. Това прекрасно се съчетава с концепцията за дългоживеещи PHP процеси. Нашата крайна реализация, която все още не е получила име, изглеждаше така:

Представяме RoadRunner — високопроизводителен сървър за PHP приложения

Нашата първа тестова задача беше API бекенд, при който периодично непредсказуемо възникваха избухвания на заявки (много по-често от обикновено). Въпреки че в повечето случаи възможностите на nginx бяха достатъчни, редовно се сблъсквахме с грешка 502, защото не можехме достатъчно бързо да балансираме системата под очакваното увеличение на натоварването.

За замяна на това решение в началото на 2018 година разширихме нашия първи PHP/Go сървър за приложения. И веднага получихме невероятен ефект! Не само че напълно се избавихме от грешка 502, но и успяхме да намалим броя на сървърите с две трети, спестявайки куп средства и хапчета за главоболие за инженерите и продукт мениджърите.

В средата на годината подобрихме нашето решение, публикувахме го в GitHub под лицензия MIT и го нарекохме RoadRunner, подчертавайки по този начин неговата невероятна скорост и ефективност.

Как RoadRunner може да подобри вашия разработващ стек

Приложение RoadRunner ни позволи да използваме Middleware net/http от страна на Go, за да извършваме JWT-верификация още преди заявката да достигне до PHP, а също така да обработваме WebSockets и глобално да агрегатим състояния в Prometheus.

Благодарение на вграденото RPC можем да отворим API на всякакви Go-библиотеки за PHP без написване на разширения-обвивки. По-важното е, че с RoadRunner можем да разгръщаме нови сървъри, различни от HTTP. Примери за това са стартиране на PHP обработчици AWS Lambda, създаване на надеждни парсери на опашки и дори добавяне gRPC в нашите приложения.

С помощта на общностите PHP и Go увеличихме стабилността на решението, в някои тестове увеличихме производителността на приложенията до 40 пъти, подобрихме инструментите за отстраняване на грешки, реализирахме интеграция с фреймворка Symfony и добавихме поддръжка за HTTPS, HTTP/2, плъгини и PSR-17.

Заключение

Някои все още са в плен на остарялото представление за PHP като бавен и обемен език, подходящ само за написване на плъгини за WordPress. Тези хора дори могат да кажат, че PHP има такова ограничение: когато приложението стане достатъчно голямо, се налага да избирате по-„зреен“ език и да пренаписвате натрупаната база код.

На всичко това искате да отговорите: помислете отново. Ние смятаме, че само вие задавате ограничения на PHP. Можете да прекарате целия си живот в преминаване от един език на друг, опитвайки се да намерите перфектната комбинация с вашите нужди, или можете да започнете да възприемате езици като инструменти. Привидните недостатъци на езика като PHP всъщност могат да са причините за неговия успех. А ако го комбинирате с друг език като Go, можете да създадете много по-мощни продукти, отколкото ако се ограничите до използване само на един език.

Работейки със съчетание от Go и PHP, можем да твърдим, че сме ги обикнали. Не планираме да жертваме едното в полза на другото — напротив, ще търсим начини да извлечем още повече полза от този двойния стек.

UPD: приветстваме създателя на RoadRunner и съавтора на оригиналната статия — Lachezis

Източник: habr.com