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 инженерите са търсили начини да разрешат този проблем от години, използвайки хитри техники за отложено зареждане, микрорамки, оптимизирани библиотеки, кеш и т.н. Но в крайна сметка все пак трябва да нулирате цялото приложение и да започнете отначало, отново и отново . (Бележка на преводача: този проблем ще бъде частично решен с появата на натоварването в PHP 7.4)

Може ли PHP с Go да преживее повече от една заявка?

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

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

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

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

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

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

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

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

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

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

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

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

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

Струваше ни се, че един протокол не е достатъчен - и добавихме възможност за повикване net/rpc go услуги директно от PHP. По-късно това ни помогна много в разработката, тъй като можехме лесно да интегрираме Go библиотеки в PHP приложения. Резултатът от тази работа може да се види например в другия ни продукт с отворен код Горидж.

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

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

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

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

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

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

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

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

За да заменим това решение, внедрихме първия си PHP/Go сървър за приложения в началото на 2018 г. И веднага получи невероятен ефект! Не само, че се отървахме напълно от грешката 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 и съавтора на оригиналната статия - Lachesis

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