Vi publiserer igjen transkripsjonen av foredraget fra konferansen HighLoad++ 2016, som fant sted i Skolkovo utenfor Moskva 7-8. november i fjor. Vladimir Protasov snakker om hvordan man kan utvide funksjonaliteten til NGINX ved hjelp av OpenResty og Lua.

Hei alle sammen, jeg heter Vladimir Protasov, og jeg jobber i Parallels. Jeg vil fortelle litt om meg selv. I tre fjerdedeler av livet mitt har jeg drevet med koding. Jeg ble programmerer til beinet, i ordets rette forstand: noen ganger drømmer jeg om kode. Den siste fjerdedelen av livet er industriell utvikling, skriving av kode som går direkte i produksjon. Koden som noen av dere bruker, men som dere ikke er klar over.

For å gi dere et inntrykk av hvor dårlig det var. Da jeg var en ung junior, kom jeg inn i selskapet, og de ga meg sånne to terabyte databaser. Det er nå alle her har highload. Jeg var på konferanser, spurte: «Hei, fortell meg, har dere big data, er det kult? Hvor mye har dere i databasene?» De svarte: «Vi har 100 gigabyte!» Jeg sa: «Kult, 100 gigabyte!» Men tenkte for meg selv, hvordan jeg skulle beholde pokerfjeset. Du tenker, ja, disse folkene er kule, og så går du tilbake og sysler med disse multi-terabyte databasene. Og dette varer — det er å være junior. Kan dere forestille dere hvilket slag det er?

Jeg kan mer enn 20 programmeringsspråk. Det er noe jeg måtte lære meg underveis i jobben. Du får kode i Erlang, C, C++, Lua, Python, Ruby, og noe annet, og så må du bare jobbe med det. Det var nødvendig. Det eksakte antallet ble jeg ikke i stand til å telle, men jeg mistet tellingen etter 20.

Siden alle tilstedeværende vet hva Parallels er, og hva vi gjør, skal jeg ikke gå inn på hvor kule vi er eller hva vi gjør. Jeg vil bare si at vi har 13 kontorer over hele verden, mer enn 300 ansatte, utvikling i Moskva, Tallinn, og på Malta. Hvis ønskelig kan du faktisk flytte til Malta hvis det er kaldt om vinteren og du trenger å varme ryggen.

Vår avdeling skriver konkret i Python 2. Vi driver med virksomhet, og vi har ikke tid til å implementere trendy teknologier, så vi lider. Vi bruker Django fordi den har alt, og vi kastet det unødvendige. Også MySQL, Redis, og NGINX. I tillegg har vi mange andre kule ting. Vi har MongoDB, vi har kaniner som løper rundt, vi har så mye rart — men det er ikke mitt ansvar, og jeg driver ikke med det.

OpenResty

Jeg har snakket om meg selv. La oss finne ut hva jeg skal snakke om i dag:

Hva er OpenResty og hva kan man bruke det til?
Hvorfor oppfinne et nytt hjul når vi allerede har Python, NodeJS, PHP, Go og andre kule ting som alle er fornøyde med?
Og noen eksempler fra virkeligheten. Jeg måtte kutte kraftig ned på presentasjonen min fordi den ble på 3,5 timer, så derfor vil det bli få eksempler.

OpenResty er NGINX. Takket være det har vi en fullt fungerende webserver som er godt skrevet og fungerer raskt. Jeg tror de fleste av oss bruker NGINX i produksjon. Alle vet at den er rask og fantastisk. Den har en imponerende synkron inn/-utdata, så vi trenger ikke å finne opp kruttet på nytt som i Python med gevent. Gevent er fantastisk, men hvis du skriver C-kode, og noe går galt, kan du bli gal av å debugge det med gevent. Jeg har erfaring: det tok meg hele to dager å finne ut hva som gikk galt. Hvis noen ikke hadde gravd i det i flere uker, ikke funnet problemet, ikke skrevet om det på nettet, og Google ikke hadde funnet det, hadde vi blitt sprø.

I NGINX er caching og statisk innhold allerede implementert. Du trenger ikke å bekymre deg for hvordan du kan gjøre dette på en ordentlig måte, slik at det ikke henger seg opp noe sted, eller at du mister filbeskrivere. NGINX er veldig lett å deployere, du trenger ikke å tenke på hva du skal bruke – WSGI, PHP-FPM, Gunicorn, Unicorn. Du installerer NGINX, gir det til administratorene, de vet hvordan de skal håndtere det. NGINX behandler forespørslene strukturert. Jeg skal si litt mer om dette senere. Kort sagt, den har en fase der den nettopp har mottatt forespørselen, en fase der den har behandlet den, og en fase der den leverer innholdet til brukeren.

NGINX er flott, men det er ett problem: den er ikke fleksibel nok, selv med alle de kule funksjonene som folk har puttet inn i konfigurasjonen, til tross for at den kan konfigureres. Denne kraften er ikke tilstrekkelig. Derfor bygde folk fra Taobao for mange år siden, omtrent åtte år siden, Lua inn i den. Hva gir det?

Størrelse. Den er liten. LuaJIT gir omtrent 100-200 kilobyte overhead i minne og minimal overhead i ytelse.
Hastighet. LuaJIT-tolkeren er i mange situasjoner nært C, i noen situasjoner taper den mot Java, og i andre overgår den den. En stund ble den ansett som state of the art, den mest imponerende JIT-kompilatoren. Nå finnes det mer imponerende, men de er veldig tunge, som for eksempel V8. Noen JavaScript-tolker og Java HotSpot kan være raskere i enkelte tilfeller, men i andre tilfeller taper de fortsatt.
Enkel å lære. Hvis du har et kodebase i Perl, og du ikke er Booking, vil du ikke finne Perl-programmerere. Fordi de ikke finnes; de har blitt alle tatt, og det tar lang tid å lære dem. Hvis du vil ha programmerere på noe annet, må du kanskje også lære dem på nytt eller finne dem. Når det gjelder Lua, er det enkelt. Enhver nybegynner kan lære Lua på tre dager. Jeg brukte omtrent to timer på å forstå det. Etter to timer skrev jeg allerede kode i produksjon. Omtrent en uke senere var det allerede i produksjon.

Som et resultat ser det slik ut:

Det er mye her. I OpenResty har de samlet en haug med moduler, både Lua-baserte og engine-moduler. Og alt er klart — jeg har deployert det, og det fungerer.

Eksempler

Nok med lyrikk, la oss gå til koden. Her er en liten Hello World:

Hva er her? Dette er en engine-lokasjon. Vi bryr oss ikke, vi skriver ikke vår egen routing, vi tar ikke noe klart — vi har allerede det i NGINX, vi lever godt og lat.

content_by_lua_block – dette er en blokk som sier at vi leverer innhold ved hjelp av et Lua-skript. Vi tar engine-variabelen remote_addr og setter den inn i string.format. Det er det samme som sprintf, bare på Lua, bare riktig. Og vi gir det til klienten.

Som et resultat vil det se slik ut:

Men la oss gå tilbake til den virkelige verden. I produksjon deployerer ingen Hello World. Vanligvis går applikasjonen vår til en database eller et annet sted, og store deler av tiden venter vi på respons.

Den sitter bare og venter. Dette er ikke så bra. Når 100.000 brukere kommer inn, er det veldig tungt for oss. Så la oss for eksempelets del lage en enkel applikasjon for å søke etter bilder, for eksempel katter. Men vi skal ikke bare søke som det; vi vil utvide nøkkelordene, og hvis brukeren har søkt etter «kattunger», skal vi finne katter, fluffy osv. For å begynne med, må vi hente forespørseldataene på backend. Slik ser det ut:

To linjer lar deg hente GET-parametere, ingen problemer. Deretter får vi informasjonen fra databasen med en tabell for nøkkelord og utvidelser via en vanlig SQL-forespørsel. Alt er enkelt. Slik ser det ut:

Vi kobler til biblioteket resty.mysql, som vi allerede har i pakken. Vi trenger ikke å installere noe; alt er klart. Vi spesifiserer hvordan vi skal koble til og lager SQL-forespørselen:

Det er litt skummelt her, men alt fungerer. Her er 10 - det er grensen. Vi henter 10 oppføringer, vi er late og ønsker ikke å vise mer. Jeg glemte å nevne grensen i SQL.

Videre finner vi bilder basert på alle forespørslene. Vi samler en bunke forespørsel og fyller en Lua-tabell som heter reqs, og gjør ngx.location.capture_multi.

Alle disse forespørslene går parallelt, og vi får svar tilbake. Behandlingstiden er lik tiden til det langsomste svaret. Hvis vi får alle svarene innen 50 millisekunder, og vi sendte ut hundre forespørsel, da kommer svaret vårt etter 50 millisekunder.

Siden vi er late og ikke ønsker å skrive HTTP-behandling og caching, lar vi NGINX gjøre alt dette for oss. Som du så, var det en forespørsel til url/fetch, her er den:

Vi gjør en enkel proxy_pass, angir hvor vi skal cache, hvordan vi skal gjøre det, og da fungerer alt.

Men dette er ikke nok, vi må også gi data til brukeren. Den enkleste ideen er å serialisere alt i JSON, enkelt, på to linjer. Vi sender Content-Type og sender JSON.

Men det er en komplikasjon: brukeren ønsker ikke å lese JSON. Vi må tilkalle frontend-utviklere. Av og til vil vi ikke gjøre dette i starten. Og SEO-ekspertene vil si at hvis vi leter etter bilder, er det dem uansett. Men hvis vi gir dem noe innhold, vil de si at søkemotorene ikke indekserer noe.

Hva skal vi gjøre med dette? Selvfølgelig vil vi gi brukeren HTML. Å generere det manuelt er ikke bra, så vi vil bruke maler. For dette har vi biblioteket lua-resty-template.

Du så kanskje de tre skumle bokstavene OPM. OpenResty kommer med sin egen pakkebehandler, gjennom hvilken du kan installere en rekke forskjellige moduler, spesielt lua-resty-template. Dette er en enkel malmotor, nært relatert til Django-maler. Der kan du skrive kode og gjøre variabel-substitusjon.

Som et resultat vil alt se omtrent slik ut:

Vi hentet data og rendrete malen i to linjer. Brukeren er glad, han fikk katter. Siden vi utvidet forespørselen, fikk han også en sjøløve i tillegg til kattungene. Kanskje han egentlig lette etter den, men kunne ikke formulere forespørselen sin riktig.

Alt er flott, men vi er jo i utviklingen, og ønsker ikke å vise dette til brukerne ennå. La oss sette opp autentisering. For å gjøre dette, la oss se hvordan NGINX behandler forespørselen i forhold til OpenResty:

Den første fasen - access, når brukeren nettopp har kommet, og vi ser på ham gjennom overskriftene, IP-adressen, og annen informasjon. Vi kan umiddelbart kutte ham av hvis vi ikke liker ham. Dette kan brukes til autentisering, eller hvis vi får for mange forespørsel, kan vi enkelt kutte dem i denne fasen.
gjen skrive. Vi gjen skriver noen forespørsel data.
content. Vi gir innholdet til brukeren.
overskrifter filter. Vi kan endre overskriftene i svaret. Hvis vi har brukt proxy_pass, kan vi omskrive noen overskrifter før vi gir dem til brukeren.
kropp filter. Vi kan endre kroppen.
log — logging. Vi kan skrive logger til elasticsearch uten et ekstra lag.

Vår autentisering vil se omtrent slik ut:

Vi legger dette til den plassering, som vi beskrev tidligere, og putter inn følgende kode:

Vi sjekker om vi har en cookie token. Hvis ikke, sender vi til autentisering. Brukerne er smarte og kan gjette at de må sette en cookie token. Derfor legger vi den også i Redis:

Koden for å arbeide med Redis er veldig enkel og skiller seg ikke fra andre språk. I tillegg er all input/output der, som her, ikke blokkering. Hvis du skriver synkron kode, fungerer det asynkront. Omtrent som med gevent, men det er gjort bedre.

La oss lage selve autentiseringen:

Vi sier at vi trenger å lese kroppen i forespørselen. Vi får POST-argumentene, sjekker om brukernavnet og passordet er riktige. Hvis de ikke er riktige, sender vi til autentisering. Og hvis de er riktige, registrerer vi token i Redis:

Ikke glem å sette cookie, dette gjøres også i to linjer:

Et enkelt, hypotetisk eksempel. Vi kommer selvfølgelig ikke til å lage en tjeneste som viser folk katter. Men hvem vet. Så la oss se på hva vi kan gjøre i produksjon.

Minimalistisk backend. Av og til trenger vi å gi backend bare litt data: noen ganger må vi sette inn en dato, vise en liste, si hvor mange brukere som er på nettstedet, legge til en teller eller statistikk. Noe lite som det. Minimumsdelene kan lager veldig enkelt. Dette vil gå raskt, lett og bra.
Forbehandling av data. Noen ganger ønsker vi å integrere annonser på siden vår, og vi henter disse annonsene via API-forespørslene. Dette er veldig enkelt å gjøre her. Vi laster ikke ned serveren vår, som allerede jobber hardt. Vi kan ta tak i og samle alt her. Vi kan lage noen JS-moduler eller, omvendt, splitte opp og preprocessere noe før vi leverer det til brukeren.
Grensesnitt for mikrotjenester. Dette er også et veldig godt case, jeg har implementert det. Før dette jobbet jeg i selskapet Tenzor, som driver med elektronisk rapportering og tar seg av rapporteringen for omtrent halvparten av juridiske enheter i landet. Vi lagde en tjeneste hvor mange funksjoner ble realisert med samme mekanisme: ruting, autorisasjon og mer.
OpenResty kan brukes som lim for mikrotjenestene dine, noe som gir enhetlig tilgang til alt og et enhetlig grensesnitt. Siden mikrotjenester kan være skrevet i forskjellige språk som Node.js, PHP, Python, og noe som kjører på Erlang, forstår vi at vi ikke ønsker å skrive den samme koden overalt. Derfor kan OpenResty settes opp på frontenden.
Statistikk og analyse. Vanligvis står NGINX foran, og alle forespørslene går gjennom det. Her er det veldig praktisk å samle data. Man kan umiddelbart utføre beregninger og sende dem et sted, for eksempel til Elasticsearch, Logstash eller bare skrive dem til logg for senere sending.
Flerebrukersystemer. For eksempel er det også veldig bra å lage online-spill. I dag vil Alexander Gladys i Cape Town snakke om hvordan man raskt kan prototype et flerebrukerspill ved hjelp av OpenResty.
Forespørsel filtrering (WAF). Nå er det populært å lage diverse webapplikasjonsbrannmurer, og det finnes mange tjenester som tilbyr dem. Med OpenResty kan man lage sin egen webapplikasjonsbrannmur som enkelt og greit kan filtrere forespørslene etter dine krav. Hvis du jobber med Python, vet du at PHP antageligvis ikke kan injiseres, med mindre du spawner det fra konsollen. Du vet at du har MySQL og Python, så kanskje noen prøver å utføre directory traversal og injisere noe i databasen. Derfor kan man raskt og kostnadseffektivt filtrere uønskede forespørslene på frontenden.
Fellesskapet. Siden OpenResty er bygget på NGINX, har det en bonus - det er NGINX-fellesskapetDet er veldig stort, og en betydelig del av spørsmålene du måtte ha i starten, er allerede løst av NGINX-samfunnet.
Lua-utviklereI går snakket jeg med folk som kom til HighLoad++ læringsdagen og hørte at det kun er Tarantool skrevet i Lua. Det er ikke sant, det er mye skrevet i Lua. Eksempler: OpenResty, XMPP-serveren Prosody, spillmotoren Love2D, Lua skriptes i Warcraft og andre steder. Det er mange Lua-utviklere, og de har et stort og hjelpsomt fellesskap. Alle mine spørsmål om Lua ble løst i løpet av noen timer. Når man skriver til e-postlisten, får man bokstavelig talt en haug med svar innen minutter, de forklarer hva og hvordan, hva som gjelder. Det er veldig flott. Dessverre er ikke alle slike vennlige sjeler.
Det finnes et GitHub for OpenResty, der kan man opprette en issue hvis noe er ødelagt. Det finnes en e-postliste på Google Groups hvor man kan diskutere generelle spørsmål, det er også en mailingliste på kinesisk - man vet aldri, kanskje man ikke behersker engelsk, men kan kinesisk.

Resultater

Jeg håper jeg har klart å formidle at OpenResty er et veldig praktisk rammeverk, skreddersydd for web.
Det har lav terskel for inntreden, siden koden ligner på det vi skriver, språket er ganske enkelt og minimalistisk.
Det tilbyr asynkron I/O uten tilbakemeldinger, vi får ikke spagetti som vi noen ganger kan skrive i NodeJS.
Det har enkel distribusjon, siden vi kun trenger NGINX med det nødvendige modulen og koden vår, så fungerer alt med en gang.
Et stort og responsivt fellesskap.

Jeg forklarte ikke i detalj hvordan ruting gjøres, det ville blitt en veldig lang historie.

Takk for oppmerksomheten!