RoadRunner: PHP ei ole loodud surema, või Golang prõksib appi

Tere, Habr! Me Badoo-s töötame aktiivselt PHP jõudluse kallal, kuna meil on piisavalt suur süsteem sellel keelel ja jõudluse küsimus on rahaküsimus. Üle kümne aasta tagasi lõime selle jaoks PHP-FPM, mis algselt oli PHP jaoks patšide kogum ja hiljem sai ametlikuks osaks.

Viimastel aastatel on PHP oluliselt edasi arenenud: prügikorjaja on paranenud, stabiilsus on kasvanud - täna on PHP-s võimalik probleemideta kirjutada deemonid ja pikaealisi skripte. See võimaldas Spiral Scoutil minna kaugemale: RoadRunner ei puhasta, erinevalt PHP-FPM-ist, mälu päringute vahel, mis annab lisavõidu jõudluses (kuigi see lähenemine muudab arendamise protsessi keerulisemaks). Praegu katsetame seda tööriista, kuid meil pole veel tulemusi, millega jagada. Et oodata oleks lõbusam, publitseerime Spiral Scouti RoadRunneri teadet tõlke.

Artiklis esitatud lähenemine on meile tuttav: oma probleemide lahendamisel kasutame ka enamasti PHP ja Go kombinatsiooni, saades kasu mõlema keele eeliste kasutamisest ja loobumata ühest teise kasuks.

Naudi!

Viimase kümne aasta jooksul oleme loonud rakendusi nii ettevõtetele, kes kuuluvad nimekirja Fortune 500, kui ka äridele, millel on maksimaalselt 500 kasutajat. Kogu selle aja jooksul on meie insenerid arendanud peamiselt PHP-l baseeruvat taustsüsteemi. Ent kaks aastat tagasi mõjutas üks asi põhjalikult mitte ainult meie toodete sooritust, vaid ka nende skaleeritavust — lisasime oma tehnoloogiahunnikusse Golangi (Go).

Peaaegu kohe avastasime, et Go võimaldab meil luua suuremaid rakendusi, saavutades kuni 40-kordse tootlikkuse kasvu. Selle abil suutsime laiendada olemasolevaid PHP-s kirjutatud tooteid, parandades neid, kasutades kahe keele eeliste kombinatsiooni.

Räägime, kuidas Go ja PHP kombinatsioon aitab lahendada reaalmaailma arendusprobleeme ning kuidas see on muutunud meie jaoks tööriistaks, mis suudab lahendada osa probleemidest, millega seostatakse PHP 'suremise' mudelit.

Teie igapäevane PHP arenduskeskkond

Enne kui räägime, kuidas Go abil PHP 'suremise' mudelit ellu äratada, vaatame teie tavalist PHP arenduskeskkonda.

Enamikul juhtudel käitate rakendust koos veebiserveri nginx ja PHP-FPM serveriga. Esimene teenindab staatilisi faile ja suunab PHP-FPM-i spetsiifilised päringud, samas kui PHP-FPM täidab PHP-koodi. Võib-olla kasutate vähem populaarset kombinatsiooni Apache ja mod_php. Kuid kuigi selle toimimine on veidi erinev, on põhimõtted samad.

Uurime, kuidas PHP-FPM rakenduskoodi täidab. Kui päring saabub, alustab PHP-FPM alamsüsteemi PHP-protsessi ning edastab päringu üksikasjad osana selle olekust (_GET, _POST, _SERVER jne).

Olek ei saa PHP-skripti täitmise ajal muutuda, seega saab uue sisendi ainult ühe viisiga: protsessi mälu puhastades ja selle uuesti initsialiseerides.

Sellise täitmismudelil on palju eeliseid. Te ei pea muretsema mälutarbimise pärast, kõik protsessid on täielikult isoleeritud ja kui üks neist 'sureb', siis luuakse see automaatselt uuesti ning see ei mõjuta teisi protsesse. Kuid sellel lähenemisel on ka puudusi, mis ilmnevad rakenduse skaleerimise katsetel.

Tavalise PHP-keskkonna puudused ja tõhususe puudumine

Kui te tegelete professionaalse PHP arendamisega, siis teate, et uue projekti alustamine algab raamistikku valimisest. See koosneb teekidest sõltuvuste süstimiseks, ORM-idest, tõlgetest ja mallidest. Muidugi saab kõik sisendid mugavalt paigutada ühe objekti sisse (Symfony/HttpFoundation või PSR-7). Raamistiku kasutamine on äge!

Kuid kõigel on oma hind. Igasse ettevõtte taseme raamistikku lihtsa kasutaja päringu või andmebaasi päringu töötlemiseks tuleb laadida vähemalt kümneid faile, luua mitmeid klasse ja analüüsida mitmeid konfiguratsioone. Veelgi halvem on see, et iga ülesande täitmise järel tuleb kõik taastada ja alustada nullist: kogu just käivitatud kood muutub kasutuks, te ei saa sellega enam ühtki päringut töödelda. Rääkige sellest igale programmeerijale, kes kirjutab mõnes teises keeles, ja näete hämmeldust tema näol.

PHP-arendajad on aastaid otsinud viise selle probleemi lahendamiseks, kasutades hoolikalt välja töötatud „laiskade” laadimise meetodeid, mikroraamistikke, optimeeritud raamatukogusid, vahemälu jne. Lõpuks peab aga ikkagi kogu rakenduse nullima ja alustama uuesti, ja uuesti. (Tõlkija märkus: osaliselt lahendab seda probleemi preload PHP 7.4 tulek)

Kas PHP suudab Go abil taluda rohkem kui ühte päringut?

On võimalik kirjutada PHP-skripte, mis kestavad kauem kui paar minutit (kuni tundide või päevadeni): näiteks cron-ülesanded, CSV-parsirid, järjekorraanalüsaatorid. Kõik need töötavad ühes stsenaariumis: nad võtavad ülesande, täidavad selle, ootavad järgmist. Kood on pidevalt mälus, säästes hinnalisi millisekundeid, kuna raamistikku ja rakendust laadides tuleb teha mitmeid täiendavaid toiminguid.

Kuid pikaajaliste skriptide arendamine ei ole nii lihtne. Iga viga tapab protsessi täielikult, mälulekete tõrkeotsing ajab hulluks ja F5 abil silumise kasutamine ei ole enam võimalik.

PHP 7 väljumisega on olukord paranenud: ilmus usaldusväärne prügikorjaja, vigade töötlemine on lihtsam ja tuumapikendused on nüüd lekete eest kaitstud. Siiski peavad insenerid endiselt olema ettevaatlikud mäluga ja meeles pidama koodi seisundi probleeme (kas on olemas keel, kus nendele asjadele ei pea tähelepanu pöörama?). Siiski on PHP 7-s meid vähem üllatusi ootamas.

Kas on võimalik võtta pikaajaliste PHP-skriptide töömudel, kohandada seda lihtsate HTTP-päringute töötlemiseks ja seeläbi vabaneda vajadusest iga päringu puhul kõik uuesti laadida?

Selle ülesande lahendamiseks oli esmalt vaja rakendada serveri rakendus, mis suudaks vastu võtta HTTP-päringuid ja suunata need järjestikku PHP-töörakendusele, tappa seda igal korral mitte.

Me teadsime, et suudame kirjutada veebiserveri puhta PHP (PHP-PM) või C-laienduse (Swoole) abil. Kuigi mõlemal meetodil on oma eelised, ei rahuldanud need meid – otsisime midagi enamat. Me vajasime mitte lihtsalt veebiserverit, vaid lahendust, mis suudaks meid vabastada PHP „raske käivitamise” probleemidest ja mille saaks hõlpsasti kohandada ja laiendada konkreetsete rakenduste jaoks. See tähendab, et vajasime rakendusserverit.

Kas Go saab meid aidata? Me teadisime, et saab, sest see keel kompileerib rakendused üksikutesse binaarfailidesse; see on platvormideülene; kasutab oma väga elegantset, paralleelse töötlemise (concurrency) mudelit ja HTTP-töötlusraamatukogusid; ja lõpuks on meil ligipääs tuhandetele avatud lähtekoodiga raamatukogudele ja integratsioonidele.

Kaks programmeerimiskeelt ühendamise raskused

Esiteks pidi määrama, kuidas kaks või enam rakendust omavahel suhtlevad.

Näiteks kauni raamatukogu kaudu ilusa raamatukoguga Aleksa Palaestrasa võimaldas PHP ja Go protsesside vahel jagada mälu (sarnaselt mod_php-ga Apache'is). Kuid sellel teegil on omad eripärad, mis piiravad selle rakendamist meie ülesande lahendamiseks.

Otsustasime kasutada teistsugust, laialdasemalt levinud lähenemist: ehitada protsesside vaheline suhtlus socket'ite/põhjal. See lähenemine on viimase paarikümne aasta jooksul tõestanud oma usaldusväärsust ning on operatsioonisüsteemi tasandil hästi optimeeritud.

Alguses loodi lihtne binaarprotokoll andmete vahetamiseks protsesside vahel ja edastuse tõrke käsitlemiseks. Selle lihtsaimas vormis on selline protokoll sarnane netstring koos fikseeritud suurusega päisega (meie juhul 17 baiti), mis sisaldab teavet paketi tüübi, suuruse ja andmete terviklikkuse kontrollimiseks mõeldud binaarsemaskide kohta.

PHP poolel kasutasime funktsiooni pack, ning Go poolel - raamatukogu encoding/binary.

Üks protokoll ei olnud piisav - ja lisasime võimaluse kutsuda Go teenuseid net/rpc otse PHP-st. Hiljem aitas see meid arenduses väga, kuna saime hõlpsasti integreerida Go teeke PHP rakendustesse. Selle töö tulemust saab näha näiteks meie teises open-source tootmis. Goridge.

Ülesannete jaotamine mitmete PHP töötajate vahel

Pärast suhtlemismehhanismi rakendamist hakkasime mõtlema, kuidas kõige tõhusamalt edastada ülesandeid PHP protsessidele. Kui ülesanne saabub, peab rakendusserver valima selle täitmiseks vaba töötaja. Kui töötaja/protsess lõpetab töö vea tõttu või «sureb», then eemaldame selle ja loome asemele uue. Kui töötaja/protsess töötab edukalt, tagastame selle ülesannete täitmiseks kergesti kätte saadavate töötajate hulka.

Aktiveeritud töötajate kihi salvestamiseks kasutasime buffeeritud kanali, et ootamatult «surnud» töötajad eemaldada, lisasime töötajate vigade ja seisundite jälgimise mehhanismi.

Tulemuseks saime töötava PHP serveri, mis suudab käsitleda kõiki binaarses vormingus esitatud päringuid.

Kuna meie rakendus peab töötama veebiserverina, pidime valima usaldusväärse PHP-standardi, et esindada kõiki sissetulevaid HTTP-päringuid. Meie puhul me lihtsalt muudame net/http-päringu Go-s formaati PSR-7, et see oleks ühilduv enamikuga tänapäeval saadaval olevatest PHP-raamistikkudest.

Kuna PSR-7 on muudetav (mõned ütlevad, et tehniliselt see nii ei ole), peavad arendajad kirjutama rakendusi, mis ei käsitle päringut globaalse olendina. See sobib suurepäraselt püsivate PHP-protsesside kontseptsiooniga. Meie lõplik teostus, millele pole veel nime antud, nägi välja selline:

Tutvustame RoadRunnerit — kõrge jõudlusega PHP-rakenduste server

Meie esimene testülesanne oli API tagaplaan, millel esines perioodiliselt ettearvamatu päringute hüppeid (kordades sagedamini kui tavaliselt). Kuigi enamikul juhtudel piisab nginx-i võimekusest, seisame pidevalt silmitsi 502. vea, kuna ei suutnud süsteemi piisavalt kiiresti tasakaalustada oodatava koormuse suurenemise tõttu.

2018. aasta alguses asendasime selle lahenduse, kasutades esmakordselt meie PHP/Go rakenduste serverit. Tulemused olid hämmastavad! Saime mitte ainult 502 tõrkest lahti, vaid vähendasime ka teenuste arvu kahel kolmandikul, säästes sellega palju raha ja vähendades inseneride ja tootejuhtide peavalusid.

Aasta keskpaiku täiustasime meie lahendust, avaldasime selle GitHub'is MIT litsentsi alusel ja kutsusime seda RoadRunner, rõhutades selle uskumatut kiirus ja efektiivsust.

Kuidas RoadRunner võib teie arenduslaari parandada

Kasutamine RoadRunner sai meie võimaluseks kasutada Middleware net/http Go poolel, et teostada JWT-verify enne, kui päring jõuab PHP'ni, samuti WebSocketide töötlemiseks ja globaalseteks olekute kogumiseks Prometheuses.

Sisseehitatud RPC abil on võimalik avada API igasuguste Go raamatukogude jaoks PHP's ilma wrapper-ekstensioonide kirjutamiseta. Veelgi olulisem on see, et RoadRunner'i abil on võimalik juurutada uusi servereid, mis erinevad HTTP-st. Näiteks on võimalik käivitada PHP töötlajaid AWS Lambda, luua usaldusväärseid järjekorra parsereid ja isegi lisada gRPC meie rakendustesse.

PHP ja Go kogukondade toel oleme parandanud lahenduse stabiilsust, suurendanud testides rakenduste jõudlust kuni 40 korda, täiustanud tõrkeotsingu tööriistu, rakendanud integratsiooni Symfony raamistikuga ning lisanud toe HTTPS, HTTP/2, pistikprogrammidele ja PSR-17-le.

Kokkuvõte

Mõned inimesed on endiselt kinni vananenud arusaamades PHP-st kui aeglasest ja mahukast keelest, mida kasutatakse ainult WordPressi pistikpluginate kirjutamiseks. Need inimesed võivad isegi väita, et PHP-l on selline piirang: kui rakendus muutub piisavalt suureks, tuleb valida „küpsem“ keel ja ümber kirjutada aastate jooksul kogunenud koodibaas.

Kõigele sellele tahaks vastata: mõelge veel kord. Me usume, et ainult teie ise seate PHP-le mingid piirangud. Võite veeta kogu oma elu ühel keelelt teisele siirdumisel, püüdes leida teie vajadustega ideaalset kombinatsiooni, või võite hakata keeli käsitlema kui tööriistu. PHP keele väidetavad puudused võivad tegelikult olla selle edu põhjuseks. Ja kui kombineerida see mõne teise keelega, nagu Go, siis loote palju võimsamaid tooteid, kui kui piirdute ainult ühe keele kasutamisega.

Töötanud Go ja PHP kombinatsiooniga, saame kinnitada, et oleme neist armunud. Me ei plaani ühte teise arvelt ohverdada — vastupidi, otsime viise, kuidas veelgi rohkem kasu saada sellest kahekordsest tehnoloogiast.

UPD: tervitame RoadRunneri loojat ja originaalartikli kaasautorit — Lachezis

Allikas: habr.com