RoadRunner: PHP är inte skapat för att dö, eller Golang kommer till hjälp

Hej, Habr! Vi på Badoo arbetar aktivt med prestandan av PHP, eftersom vi har ett ganska stort system på detta språk och prestandafrågan handlar om kostnadsbesparingar. För mer än tio år sedan skapade vi PHP-FPM för detta, vilket först var en uppsättning patchar för PHP, och senare blev en del av den officiella distributionen.

Under de senaste åren har PHP gjort stort framsteg: skräpsamlaren har förbättrats, stabiliteten har ökat – idag går det utan större problem att skriva demoner och långlivade skript i PHP. Detta har lett Spiral Scout till att ta ytterligare steg: RoadRunner, till skillnad från PHP-FPM, frigör inte minnet mellan förfrågningar, vilket ger en ytterligare prestandaökning (även om detta tillvägagångssätt komplicerar utvecklingsprocessen). Vi experimenterar för närvarande med detta verktyg, men vi har ännu inga resultat att dela med oss av. För att göra väntan mer underhållande, publicerar vi en översättning av RoadRunner-meddelandet från Spiral Scout.

Tillvägagångssättet i artikeln ligger oss nära: när vi löser våra problem använder vi också oftast kombinationen av PHP och Go, där vi drar nytta av fördelarna med båda språken utan att avstå från det ena till förmån för det andra.

Njut!

Under de senaste tio åren har vi skapat applikationer både för företag på listan Fortune 500, såväl som för verksamheter med en publik på högst 500 användare. Under hela denna tid har våra ingenjörer huvudsakligen utvecklat backend i PHP. Men för två år sedan påverkade något starkt inte bara prestandan hos våra produkter, utan även deras skalbarhet – vi införde Golang (Go) i vår teknologistack.

Nästan omedelbart upptäckte vi att Go låter oss skapa större applikationer med en prestandaförbättring på upp till 40 gånger. Med hjälp av det kunde vi utöka befintliga produkter skrivna i PHP, vilket förbättrade dem genom att kombinera fördelarna med båda språken.

Vi kommer att berätta hur kombinationen av Go och PHP hjälper till att lösa verkliga utvecklingsproblem och hur den har blivit ett verktyg som kan frigöra oss från vissa problem relaterade till PHP:s "döende"-modell.

Din dagliga PHP-utvecklingsmiljö

Innan vi berättar hur Go kan återuppliva PHP:s "döende"-modell, låt oss titta på din standard PHP-utvecklingsmiljö.

I de flesta fall startar du applikationen med en kombination av webbservern nginx och PHP-FPM-servern. Den första hanterar statiska filer och vidarebefordrar specifika förfrågningar till PHP-FPM, som i sin tur utför PHP-koden. Kanske använder du en mindre populär kombination av Apache och mod_php. Men även om den fungerar lite annorlunda, är principerna desamma.

Låt oss titta på hur PHP-FPM utför applikationskoden. När en förfrågan kommer, initialiserar PHP-FPM en underordnad PHP-process och överför förfrågningens detaljer som en del av dess tillstånd (_GET, _POST, _SERVER osv.).

Tillståndet kan inte ändras under körningen av PHP-skriptet, så för att få en ny uppsättning ingångsdata finns det bara ett sätt: att rengöra processens minne och initialisera den på nytt.

Denna exekveringsmodell har många fördelar. Du behöver inte oroa dig mycket för minnesanvändning, alla processer är helt isolerade, och om en av dem "dör", kommer den automatiskt att återskapas utan att påverka de andra processerna. Men denna metod har också nackdelar som visar sig när man försöker skala applikationen.

Nackdelar och ineffektivitet med en vanlig PHP-miljö

Om du arbetar med professionell PHP-utveckling vet du att du ska börja ett nytt projekt med att välja ett ramverk. Det består av bibliotek för beroendeinjektion, ORM:er, översättningar och mallar. Och självklart kan alla användardata enkelt samlas i ett objekt (Symfony/HttpFoundation eller PSR-7). Ramverk är fantastiska!

Men allt har sitt pris. I vilket företagsramverk som helst måste du ladda minst tiotals filer, skapa många klasser och analysera flera konfigurationer för att hantera en enkel användarförfrågan eller databasanslutning. Men det värsta är att efter att varje uppgift har utförts måste allt rensas och börja om: all kod du just har initierat blir värdelös, och med den kan du inte bearbeta ytterligare en förfrågan. Berätta detta för en programmerare som skriver i ett annat språk, så kommer du se förundran i deras ansikte.

PHP-ingenjörer har i åratal letat efter sätt att lösa detta problem, använt genomtänkta metoder för "lazy" inläsning, mikroramverk, optimerade bibliotek, cache, osv. Men i slutändan måste man ändå återställa hela applikationen och börja om, gång på gång. (Översättarens anmärkning: delvis kommer detta problem att lösas med införandet av preload PHP 7.4)

Kan PHP med hjälp av Go hantera mer än en begäran?

Det går att skriva PHP-skript som lever längre än några minuter (upp till timmar eller dagar): exempelvis cron-jobb, CSV-parsare, köhanterare. Alla arbetar enligt samma schema: de plockar upp en uppgift, utför den, väntar på nästa. Koden finns ständigt i minnet, vilket sparar dyrbar millisekund, eftersom det krävs många ytterligare åtgärder för att ladda ramverket och applikationen.

Men att utveckla långlivade skript är inte så enkelt. Ett enda fel kan helt döda processen, att diagnostisera minnesläckor är frustrerande, och det går inte längre att använda F5 för felsökning.

Situationen har förbättrats med PHP 7: en pålitlig skräpsamlar installerades, det blev lättare att hantera fel, och kärntillägg är nu skyddade mot läckor. Visst måste ingenjörerna fortfarande hantera minnet varsamt och tänka på kodens tillståndsproblem (finns det något språk där man kan bortse från sådana saker?). Trots det finns det färre oväntade överraskningar med PHP 7.

Kan man ta modellen för arbete med långlivade PHP-skript, anpassa den för mer triviala uppgifter som att hantera HTTP-begärningar, och på så sätt undkomma behovet att ladda allt från början vid varje begäran?

För att lösa detta problem behövde man först implementera en serverapplikation som kunde ta emot HTTP-begärningar och dirigera dem en i taget till en PHP-arbetare, utan att döda den varje gång.

Vi visste att vi skulle kunna skriva en webbserver i ren PHP (PHP-PM) eller med hjälp av C-tillägg (Swoole). Och även om varje metod har sina fördelar, var ingen av dem tillräcklig för oss – vi ville ha något mer. Vi behövde inte bara en webbserver – vi förväntade oss en lösning som skulle befria oss från problemen med "tung start" i PHP, och som dessutom skulle kunna anpassas och utökas lätt för specifika applikationer. Det vill säga, vi behövde en applikationsserver.

Kan Go hjälpa till med detta? Vi visste att den kunde, eftersom språket kompilerar applikationer till enstaka binärfiler; det är plattformsoberoende; det använder en egen, mycket elegant modell för samtidighet (concurrency) och ett bibliotek för att hantera HTTP; och slutligen skulle vi få tillgång till tusentals open-source-bibliotek och integrationer.

Svårigheterna med att sammanföra två programmeringsspråk

Först och främst var det nödvändigt att definiera hur två eller flera applikationer skulle kommunicera med varandra.

Till exempel genom det fantastiska biblioteket av Alex Palastras, som kunde göra det möjligt för PHP- och Go-processer att dela minne (på liknande sätt som mod_php i Apache). Men detta bibliotek har funktioner som begränsar dess tillämpning för att lösa vårt problem.

Vi beslöt att använda en annan, mer utbredd metod: att bygga interaktionen mellan processerna genom sockets/pipelines. Denna metod har under de senaste decennierna visat sig vara pålitlig och har optimerats väl på operativsystemsnivå.

Till att börja med skapade vi ett enkelt binärt protokoll för datakommunikation mellan processer och hantering av överföringsfel. I sin enklaste form påminner ett protokoll av denna typ om netstring med med fast storlek på paketets header (i vårt fall 17 byte), vilket innehåller information om paketets typ, dess storlek och en binär mask för att kontrollera integriteten i data.

På PHP-sidan använde vi funktionen pack, medan vi på Go-sidan använde biblioteket encoding/binary.

Det verkade som om vi behövde mer än ett protokoll – så vi lade till möjligheten att anropa Go-tjänster net/rpc direkt från PHP. Senare hjälpte detta oss mycket i utvecklingen, eftersom vi enkelt kunde integrera Go-bibliotek i PHP-applikationer. Resultatet av detta arbete kan ses, till exempel, i vår andra open-source-produkt Goridge.

Uppdelning av uppgifter mellan flera PHP-arbetare

Efter implementeringen av interaktionsmekanismen började vi tänka på hur vi effektivast kunde överföra uppgifter till PHP-processerna. När en uppgift anländer, måste applikationsservern välja en ledig arbetare för att utföra den. Om arbetaren/processen avslutade arbetet med ett fel eller "dog", tar vi bort den och skapar en ny i dess ställe. Och om arbetaren/processen körs framgångsrikt, återlämnar vi den till poolen av arbetare som är tillgängliga för att utföra uppgifter.

För att lagra poolen av aktiva arbetare använde vi en buffrad kanal, för att ta bort oväntat "döda" arbetare från poolen lade vi till en mekanism för att spåra fel och arbetarnas tillstånd.

Som ett resultat fick vi en fungerande PHP-server som kan hantera alla förfrågningar som presenteras i binärt format.

För att vår applikation skulle börja fungera som en webbserver, var vi tvungna att välja en pålitlig PHP-standard för att representera alla inkommande HTTP-förfrågningar. I vårt fall omvandlar vi net/http-förfrågan från Go till formatet PSR-7, så att den är kompatibel med de flesta tillgängliga PHP-ramverken idag.

Eftersom PSR-7 anses vara oföränderlig (någon skulle säga att det tekniskt sett inte är så), måste utvecklare skriva applikationer som i princip inte hanterar förfrågan som en global entitet. Detta passar perfekt med konceptet av långlivade PHP-processer. Vår slutliga implementering, som ännu inte fått något namn, såg ut så här:

Vi presenterar RoadRunner — en högpresterande server för PHP-applikationer

Vår första testuppgift var en API-backend, där det periodiskt oförutsägbart uppstod toppar av förfrågningar (mycket oftare än vanligt). Även om nginx:s kapacitet i de flesta fall var tillräcklig, stötte vi regelbundet på fel 502, eftersom vi inte kunde balansera systemet tillräckligt snabbt för att möta den förväntade ökningen av belastningen.

För att ersätta denna lösning implementerade vi i början av 2018 vår första PHP/Go-applikationsserver. Och vi fick omedelbart en otrolig effekt! Vi inte bara helt eliminerade fel 502, utan kunde också minska antalet servrar med två tredjedelar, och sparade massor av pengar och huvudvärk för ingenjörer och produktchefer.

I mitten av året förbättrade vi vår lösning, publicerade den på GitHub under MIT-licensen och döpte den till RoadRunner, vilket framhäver dess otroliga hastighet och effektivitet.

Hur RoadRunner kan förbättra din utvecklingsstack

Tillämpning RoadRunner gjorde det möjligt för oss att använda Middleware net/http på Go-sidan för att genomföra JWT-verifiering innan begäran ens når PHP, samt för att hantera WebSockets och globalt aggregera tillstånd i Prometheus.

Tack vare den inbyggda RPC kan man öppna API:er från valfria Go-bibliotek för PHP utan att skriva runtillägg. Vad som är ännu viktigare är att med RoadRunner kan man distribuera nya servrar som skiljer sig från HTTP. Exempelvis kan man köra PHP-hanterare, AWS Lambdaskapa pålitliga köparsers och till och med lägga till gRPC i våra applikationer.

Med hjälp av PHP- och Go-gemenskaperna har vi förbättrat lösningens stabilitet, ökat prestandan i vissa tester upp till 40 gånger, förbättrat debuggningsverktygen, implementerat integration med ramverket Symfony och lagt till stöd för HTTPS, HTTP/2, plugins och PSR-17.

Slutsats

Vissa är fortfarande fast i den föråldrade uppfattningen om PHP som ett långsamt och skrymmande språk, som bara är användbart för att skriva plugins till WordPress. Dessa personer kan till och med hävda att PHP har en sådan begränsning: när en applikation blir tillräckligt stor, måste man välja ett mer "mognat" språk och skriva om den kodbas som byggts upp under många år.

Angående detta vill vi säga: tänk en gång till. Vi tror att det är ni själva som sätter begränsningar för PHP. Ni kan spendera hela livet på att byta mellan språk i jakt på den perfekta lösningen för era behov, eller så kan ni börja se språk som verktyg. Illusionen av språkets brister som PHP kan faktiskt vara anledningen till dess framgång. Och om ni kombinerar det med ett annat språk som Go, kommer ni att skapa betydligt kraftfullare produkter än om ni begränsar er till att använda ett enda språk.

Efter att ha arbetat med kombinationen Go och PHP kan vi säga att vi älskar dem. Vi planerar inte att offra det ena för det andra - tvärtom kommer vi att söka sätt att få ännu mer nytta av denna dubbelstack.

UPD: välkomna skaparen av RoadRunner och medförfattaren till den ursprungliga artikel — Lachezis

Källa: habr.com