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-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) или с помощта на С-разширение (Swoole). И въпреки че всеки от тези методи има своите предимства, нито един от тях не ни удовлетворяваше — искахме нещо повече. Нуждаехме се не просто от уеб сървър — искахме решение, способно да ни избави от проблемите, свързани с "тежкия старт" в PHP, което може да бъде лесно адаптирано и разширено спрямо конкретни приложения. Тоест, нуждаехме се от приложение-сървър.

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

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

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

Например, с помощта на прекрасната библиотека на Алекс Палестрaс, можеше да се реализира споделянето на паметта между процесите 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