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 парсери, редици busters. Сите тие работат според истото сценарио: враќаат задача, ја извршуваат и ја чекаат следната. Кодот се наоѓа во меморијата, заштедувајќи драгоцени милисекунди бидејќи се потребни многу дополнителни чекори за да се вчита рамката и апликацијата.

Но, развојот на долговечни скрипти не е толку лесно. Секоја грешка целосно го убива процесот, дијагностицирањето на протекување на меморија ве излудува и повеќе не можете да користите дебагирање на F5.

Ситуацијата е подобрена со објавувањето на PHP 7: се појави сигурен собирач на ѓубре, стана полесно да се справите со грешките, а екстензиите на јадрото сега се заштитени од протекување. Точно, инженерите сè уште треба да бидат внимателни со меморијата и да бидат свесни за состојбите во кодот (дали има јазик каде што не треба да се грижиме за овие работи?). А сепак, во PHP 7 не очекуваат помалку изненадувања.

Дали е можно да се земе моделот на работа со долготрајни PHP скрипти, да се прилагоди на повеќе тривијални задачи како што е обработката на барањата HTTP и со тоа да се елиминира потребата да се вчита сè од нула за секое барање?

За да го решиме овој проблем, најпрво требаше да имплементираме серверска апликација која може да прифаќа HTTP барања и да ги препраќа еден по еден до работникот на PHP без да го убива секој пат.

Знаевме дека можеме да напишеме веб-сервер во чиста PHP (PHP-PM) или со користење на наставката C (Swoole). И иако секој метод има свои заслуги, двете опции не ни одговараа - сакавме нешто повеќе. Ни требаше повеќе од само веб-сервер - се надевавме дека ќе добиеме решение што ќе не спаси од проблемите поврзани со „тешкиот почеток“ во PHP, кој во исто време може лесно да се прилагоди и прошири за одредени апликации. Тоа е, ни требаше сервер за апликации.

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

Тешкотии при комбинирање на два програмски јазици

Првиот чекор беше да се одреди како две или повеќе апликации ќе комуницираат една со друга.

На пример, користејќи прекрасна библиотека Alex Palaestras може да имплементира споделување меморија помеѓу процесите PHP и Go (слично на mod_php во Apache). Но, оваа библиотека има карактеристики што ја ограничуваат нејзината употреба за решавање на нашиот проблем.

Решивме да користиме друг, повообичаен пристап: да изградиме интеракција помеѓу процесите преку приклучоци/цевководи. Овој пристап ја докажа својата сигурност во изминатите децении и беше добро оптимизиран на ниво на оперативен систем.

За почеток, создадовме едноставен бинарен протокол за размена на податоци помеѓу процесите и справување со грешките при преносот. Во својата наједноставна форма, овој тип на протокол е сличен на мрежна низа с Заглавие на пакет со фиксна големина (во нашиот случај 17 бајти), кој содржи информации за типот на пакетот, неговата големина и бинарна маска за проверка на интегритетот на податоците.

На PHP страната што ја користевме функција на пакет, а на страната Go - библиотека кодирање/бинарно.

Ни се чинеше дека еден протокол не е доволен - па додадовме можност за повикување Одете на услуги net/rpc директно од PHP. Ова подоцна ни помогна многу во развојот, бидејќи можевме лесно да ги интегрираме библиотеките Go во PHP апликациите. Резултатот од оваа работа може да се види, на пример, во другиот наш производ со отворен код Гориџ.

Дистрибуција на задачи низ повеќе PHP работници

Откако го имплементиравме механизмот за интеракција, почнавме да размислуваме како најефикасно да ги пренесеме задачите во процесите на PHP. Кога ќе пристигне задача, серверот за апликација мора да избере бесплатен работник за да ја заврши. Ако работникот/процесот заврши со грешка или „умре“, се ослободуваме од него и создаваме нов кој ќе го замени. И ако работникот/процесот е успешно завршен, го враќаме во базенот на работници достапни за извршување на задачите.

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

Како резултат на тоа, добивме работен PHP сервер способен да ги обработува сите барања претставени во бинарна форма.

За да може нашата апликација да функционира како веб-сервер, моравме да избереме доверлив PHP стандард за да ги претстави сите дојдовни HTTP барања. Во нашиот случај ние само трансформираат net/http барање од Go to format PSR-7така што е компатибилен со повеќето PHP рамки достапни денес.

Бидејќи PSR-7 се смета за непроменлив (некои би рекле технички дека не е), програмерите мора да пишуваат апликации кои фундаментално не го третираат барањето како глобален ентитет. Ова убаво се вклопува со концептот на долготрајни PHP процеси. Нашата конечна имплементација, која сè уште не беше именувана, изгледаше вака:

Ви го претставуваме RoadRunner - PHP апликативен сервер со високи перформанси

Нашата прва тест задача беше API backend, кој периодично доживуваше неочекувани изливи на барања (многу почесто од вообичаено). Иако 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 Ламбда, создавајќи сигурни забивачи на редици, па дури и додавање gRPC на нашите апликации.

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

Заклучок

Некои луѓе сè уште се фатени во застарениот поглед на PHP како бавен, тежок јазик само добар за пишување додатоци за WordPress. Овие луѓе би можеле дури да речат дека PHP има ограничување: кога апликацијата ќе стане доволно голема, треба да изберете „позрел“ јазик и да ја преработите базата на код што се акумулирала во текот на многу години.

На сето ова сакам да одговорам: размислете повторно. Ние веруваме дека само вие можете да поставите какви било ограничувања за PHP. Можете да го поминете целиот свој живот скокајќи од еден јазик на друг, обидувајќи се да го пронајдете совршеното совпаѓање за вашите потреби или можете да почнете да размислувате за јазиците како алатки. Воочените недостатоци на јазик како PHP всушност може да бидат причините за неговиот успех. И ако го комбинирате со друг јазик како Go, можете да создадете многу помоќни производи отколку ако сте ограничени на само еден јазик.

Откако работевме со комбинација на Go и PHP, можеме да кажеме дека ги сакаме. Не планираме да го жртвуваме едното за другото, туку бараме начини да извлечеме уште поголема вредност од овој двоен стек.

UPD: Го поздравуваме креаторот на RoadRunner и коавтор на оригиналната статија - Лахезис

Извор: www.habr.com