Vi publicerar återigen en transkription av föredraget från konferensen HighLoad++ 2016, som hölls i Skolkovo i Moskva-regionen den 7–8 november förra året. Vladimir Protasov berättar hur man utökar funktionaliteten av NGINX med OpenResty och Lua.

Hej alla, jag heter Vladimir Protasov, jag arbetar på Parallels. Jag ska berätta lite om mig själv. I tre fjärdedelar av mitt liv har jag ägnat mig åt att skriva kod. Jag blev programmerare ända in i själen, bokstavligen: ibland drömmer jag om kod. En fjärdedel av livet handlar om industriell utveckling, att skriva kod som går direkt till produktion. Koden som vissa av er använder, men inte misstänker.

För att ni ska förstå hur illa det var. När jag var en liten junior kom jag in och fick sådana tvåterabyte databaser. Nu har alla highload här. Jag gick på konferenser och frågade: "Tja, berätta, har ni big data, är allt coolt? Hur stora databaser har ni?" De svarade: "Vi har 100 gigabyte!" Jag sa: "Coolt, 100 gigabyte!" Men tänkte för mig själv, hur jag skulle hålla en pokerface. Du tänker, ja, de är coola, och sen kommer du tillbaka och gräver med dessa multiterabyte databaser. Och detta - när jag var junior. Kan ni föreställa er hur hårt det var?

Jag kan mer än 20 programmeringsspråk. Det är något jag har fått lära mig under arbetets gång. Du får kod på Erlang, C, C++, Lua, Python, Ruby och något annat, och du måste arbeta med allt det. Så det blev så. Jag har inte lyckats räkna det exakta antalet, men det förlorade jag mig någonstans kring 20.

Eftersom alla närvarande vet vad Parallels är och vad vi gör, kommer jag inte att prata om hur coola vi är och vad vi gör. Jag berättar bara att vi har 13 kontor runt om i världen, över 300 anställda, utveckling i Moskva, Tallinn och Malta. Om så önskas kan man faktiskt flytta till Malta om det är kallt på vintern och man behöver värma ryggen.

Specifikt vår avdelning skriver i Python 2. Vi sysslar med affärer och har inte tid att införa trendiga teknologier, så vi lider. Vi har Django, för i den finns allt, och det överflödiga har vi tagit bort. Dessutom MySQL, Redis och NGINX. Vi har också många andra coola saker. Vi har MongoDB, våra kaniner springer omkring, vi har så mycket olika grejer - men det är inte mitt område, och jag sysslar inte med det.

OpenResty

Jag har berättat om mig själv. Låt oss ta reda på vad jag ska prata om idag:

Vad är OpenResty och hur används det?
Varför uppfinna ännu en cykel när vi har Python, NodeJS, PHP, Go och andra fantastiska saker som alla är nöjda med?
Och lite exempel från verkligheten. Jag var tvungen att kraftigt korta ned min presentation eftersom den blev 3,5 timmar lång, så det blir få exempel.

OpenResty är NGINX. Tack vare det har vi en fullt fungerande webbserver som är välskriven och snabb. Jag tror att de flesta av oss använder NGINX i produktion. Alla vet att den är snabb och bra. Den har en fantastisk synkron in-/utmatning, så vi behöver inte hitta på något nytt som vi gjorde i Python med gevent. Gevent är fantastiskt, men om du skriver C-kod och något går fel, kommer du att bli galen av att debugga det med gevent. Jag hade den erfarenheten: det tog mig två hela dagar att förstå vad som gått fel. Om ingen hade grävt i det i flera veckor, hittat problemet, skrivit om det på internet, och Google inte hade funnit det, skulle vi ha blivit helt galna.

I NGINX finns redan caching och statiskt innehåll. Du behöver inte oroa dig för hur man gör det på ett korrekt sätt så att det inte saktar ner någonstans, eller att du tappar några deskriptorer. NGINX är väldigt enkelt att distribuera, du behöver inte tänka på vad du ska välja – WSGI, PHP-FPM, Gunicorn, Unicorn. NGINX installeras, adminerna tar hand om det, och de vet hur man arbetar med det. NGINX strukturerat hanterar förfrågningar. Jag kommer att berätta lite mer om det senare. Kort sagt, det finns en fas när den just har tagit emot förfrågan, när den har behandlat den och när den har returnerat innehållet till användaren.

NGINX är bra, men det finns ett problem: det är inte tillräckligt flexibelt, även med alla de fantastiska funktionerna som utvecklarna har lagt in i konfigurationen. Denna kraft räcker inte till. Därför integrerade teamet från Taobao för länge sedan, verkar det vara för åtta år sedan, Lua i det. Vad ger det?

Dimensions. Det är litet. LuaJIT ger ungefär 100-200 kilobyte overhead i minnet och minimal overhead i prestanda.
Hastighet. LuaJIT-tolkaren är i många situationer nära C, i vissa situationer slår det Java, i andra är det snabbare än den. Under en tid ansågs det vara den mest avancerade JIT-kompilatorn. Numera finns det mer avancerade, men de är mycket tyngre, som till exempel V8. Vissa JS-tolkare och Java HotSpot är snabbare i vissa aspekter, men i andra områden förlorar de fortfarande.
Användarvänlighet. Om du till exempel har en kodbas i Perl, och du inte är Booking, kommer du inte att hitta Perl-programmerare. För de finns inte, de har alla blivit upptagna, och att lära dem tar tid och är svårt. Om du vill ha programmerare i något annat språk, kanske du också behöver omskola dem, eller så får du leta. För Lua är det enkelt. Lua kan läras av vilken junior som helst på tre dagar. Jag behövde ungefär två timmar för att förstå det. Efter två timmar skrev jag redan kod i produktionen. Ungefär en vecka senare var den direkt i produktionen.

Resultatet ser ut så här:

Det finns mycket här. I OpenResty har de samlat en massa moduler, både Lua och NGINX-specifika. Och allt är klart – bara dyk in och det fungerar.

Exempel

Nog med poesi, let's gå till koden. Här är en liten Hello World:

Vad finns här? Det är en NGINX-location. Vi grämer oss inte, vi skriver ingen egen routing, vi tar ingen färdig – vi har redan det i NGINX, vi lever bra och lat.

content_by_lua_block – det är en block som säger att vi skickar innehåll med hjälp av ett Lua-skript. Vi tar NGINX-variabeln remote_addr och stoppar den i string.format. Det är samma sak som sprintf, bara på Lua, bara korrekt. Och vi skickar det till kunden.

Resultatet ser ut så här:

Men låt oss återvända till verkligheten. Ingen deployar Hello World i produktion. Vår applikation gör vanligtvis anrop till databasen eller någon annanstans och större delen av tiden väntar på svar.

Den sitter bara och väntar. Det är inte så bra. När 100 000 användare strömmar in, blir det mycket tufft för oss. Så låt oss ta fram ett enkelt exempel på en applikation. Vi ska leta efter bilder, till exempel katter. Men vi ska inte bara leta, vi kommer att bredda sökord och om en användare söker på "kattungar", så ska vi hitta katter, fluffiga, och så vidare. Först måste vi få sökdata på backend. Det ser ut så här:

Två rader tillåter dig att hämta GET-parametrar, inget krångel. Därefter får vi informationen från databasen med en table på sökordet och filendelse med en vanlig SQL-fråga. Det är enkelt. Det ser ut så här:

Vi kopplar in biblioteket resty.mysql, som vi redan har i paketet. Vi behöver inget installera, allt är klart. Vi anger hur vi ansluter och gör en SQL-fråga:

Det är lite läskigt här, men allt fungerar. Här är 10 – det är gränsen. Vi hämtar 10 poster, vi är lata och vill inte visa fler. Jag glömde att nämna gränsen i SQL.

Sedan hittar vi bilder för alla förfrågningar. Vi samlar en hög av förfrågningar och fyller en Lua-tabell som kallas reqs, och gör ngx.location.capture_multi.

Alla dessa förfrågningar går parallellt, och vi får tillbaka svar. Tiden för arbetet är lika med tiden för svaret från den långsammaste. Om alla svarar på 50 millisekunder och vi skickade hundra förfrågningar, kommer svaret att komma tillbaka på 50 millisekunder.

Eftersom vi är lata och inte vill skriva HTTP-hantering och caching, kommer vi att få NGINX att göra allt åt oss. Som ni såg, där var en förfrågan till url/fetch, här är den:

Vi gör en enkel proxy_pass, anger vart vi ska cacha, hur vi ska göra det, och allt fungerar.

Men det är inte tillräckligt, vi behöver också ge data till användaren. Den enklaste idén är att serialisera allt till JSON, lätt, på två rader. Vi ger Content-Type, vi ger JSON.

Men det finns en svårighet: användaren vill inte läsa JSON. Vi måste locka frontend-utvecklare. Ibland vill vi inte göra det från början. SEO-experter kan säga att om vi letar efter bilder är det ointressant för dem. Men om vi ger dem något innehåll, kommer de att säga att våra sökmotorer inte indexerar något.

Vad ska vi göra åt det? Självklart kommer vi att ge HTML till användaren. Att generera det manuellt är inte bra, så vi vill använda mallar. För detta finns det ett bibliotek lua-resty-template.

Ni har kanske sett de tre skrämmande bokstäverna OPM. OpenResty kommer med sin egen pakethanterare, genom vilken man kan installera en massa olika moduler, bland annat lua-resty-template. Det är en enkel mallmotor, nära Django-mallar. Där kan man skriva kod och göra variabelsubstitution.

Resultatet kommer att se ungefär ut så här:

Vi tog data och renderade mallen igen i två rader. Användaren är glad, han fick kattbilder. Eftersom vi utvidgade förfrågan fick han också en sjölejon. Vem vet, kanske han letade just efter det men inte kunde formulera sin förfrågan korrekt.

Det är fantastiskt, men vi är i utvecklingsskedet, och vi vill inte visa det för användarna än. Låt oss göra autentisering. För att göra det, låt oss se hur NGINX hanterar en förfrågan i termer av OpenResty:

Den första fasen – access, när användaren just har kommit in, och vi har tittat på honom utifrån rubriker, IP-adress och annan information. Vi kan omedelbart stänga av honom om vi inte gillar det. Detta kan användas för autentisering, eller om vi får väldigt många förfrågningar kan vi enkelt stänga av dem i detta skede.
rewrite. Vi skriver om viss förfrågningsdata.
innehåll. Vi ger innehållet till användaren.
rubriksfilter. Vi kan modifiera svarsrubriker. Om vi har använt proxy_pass, kan vi skriva om vissa rubriker innan vi ger dem till användaren.
kroppsförfilter. Vi kan modifiera kroppen.
log — loggning. Vi kan skriva loggar i elasticsearch utan ett extra lager.

Vår autentisering kommer att se ut ungefär så här:

Vi lägger till detta i den plats, som vi beskrev tidigare, och sätter in följande kod:

Vi kollar om vi har en cookie-token. Om inte, omdirigerar vi till autentisering. Användarna är kloka och kan lista ut att de behöver sätta en cookie-token. Därför lägger vi även in den i Redis:

Koden för att arbeta med Redis är väldigt enkel och skiljer sig inte från andra språk. All input/output där och här är icke-blockerande. Om du skriver synkron kod fungerar det asynkront. Ungefär som med gevent, fast gjort bra.

Låt oss göra själva autentiseringen:

Vi säger att vi behöver läsa kroppsinnehållet för förfrågan. Vi får POST-argument, kontrollerar att användarnamn och lösenord är korrekta. Om de är felaktiga, omdirigerar vi till autentisering. Men om de är korrekta, sparar vi token i Redis:

Glöm inte att sätta cookie, det görs också på två rader:

Ett enkelt, hypotetiskt exempel. Vi kommer självklart inte att göra en tjänst som visar katter för människor. Men vem vet. Låt oss därför titta på vad som kan göras i produktion.

Minimalistisk backend. Ibland behöver vi leverera en mycket liten mängd data till backend: ibland behöver vi sätta in ett datum, ibland visa en lista, berätta hur många användare som för närvarande är på webbplatsen, koppla in en räknare eller statistik. Något litet. Minimala bitar kan göras väldigt lätt. Det kommer att bli snabbt, enkelt och bra.
Förbehandling av data. Ibland vill vi integrera annonser på vår sida, och vi hämtar dessa annonser via API-förfrågningar. Det är väldigt enkelt att göra just här. Vi belastar inte vår backend, som redan arbetar hårt. Vi kan samla detta här. Vi kan skapa lite JS eller, tvärtom, dela upp det, processa något innan vi ger det till användaren.
Facad för mikrotjänst. Detta är också ett mycket bra fall, jag har implementerat det. Tidigare arbetade jag på företaget Tenzor, som sysslar med elektronisk rapportering och tillhandahåller rapportering för ungefär hälften av företagen i landet. Vi gjorde en tjänst där med hjälp av samma mekanism är många saker gjorda: ruttdelning, autentisering och annat.
OpenResty kan användas som lim för dina mikrotjänster, vilket ger en enhetlig åtkomst till allt och ett enhetligt gränssnitt. Eftersom mikrotjänster kan skrivas så här, så har du Node.js här, PHP där, Python här, någon grej på Erlang, förstår vi att vi inte vill skriva samma kod överallt. Så OpenResty kan sättas på fronten.
Statistik och analys. Vanligtvis står NGINX vid ingången, och alla förfrågningar går genom honom. Just på denna plats är det mycket bekvämt att samla. Man kan räkna något direkt och skicka det någonstans, till exempel till Elasticsearch, Logstash eller helt enkelt logga det och sedan skicka det någonstans.
Flerspelarsystem. Till exempel är det också mycket bra att göra online-spel. Idag i Kapstaden kommer Alexander Gladysh att berätta hur man snabbt prototyperar ett flerspelarspel med hjälp av OpenResty.
Filtrering av förfrågningar (WAF). Nu är det populärt att göra alla möjliga web application firewalls, det finns många tjänster som tillhandahåller dem. Med hjälp av OpenResty kan du skapa en web application firewall som enkelt och smidigt filtrerar förfrågningar enligt dina krav. Om du har Python förstår du att PHP inte kan injiceras, om du inte spawnar det någonstans från konsolen. Du vet att du har MySQL och Python. Kanske kan de försöka göra någon typ av directory traversal och injicera något i databasen. Därför kan man snabbt och billigt filtrera bort misstänkt förfrågningar direkt på fronten.
Gemenskap. Eftersom OpenResty är byggt på NGINX har det en bonus - det är NGINX-gemenskapDet är mycket stort, och en betydande del av de frågor som du kan ha i början har redan lösts av NGINX-communityt.
Lua-utvecklareI går pratade jag med killarna som kom på utbildningsdagen HighLoad++ och hörde att endast Tarantool är skrivet på Lua. Så är det inte, det är mycket som är skrivet i Lua. Exempel: OpenResty, XMPP-servern Prosody, spelmotorn Love2D, Lua scriptas i Warcraft och på andra ställen. Det finns många Lua-utvecklare, och deras community är stort och lyhört. Alla mina frågor om Lua blev lösta inom några timmar. När man skriver till mailinglistan får man bokstavligen svar inom några minuter, de förklarar vad och hur, vad som är vad. Det är riktigt bra. Tyvärr är det inte alltid så här vänligt stämning i andra communitys.
Det finns en GitHub för OpenResty, där kan man skapa en issue om något går sönder. Det finns en mailinglista i Google Groups där man kan diskutera allmänna frågor, och det finns en lista på kinesiska – kanske behärskar du inte engelska, men kan kinesiska.

Sammanfattning

Jag hoppas att jag har kunnat förmedla att OpenResty är ett väldigt bekvämt ramverk anpassat för webben.
Det har en låg inträdeströskel, eftersom koden liknar det vi skriver, språket är ganska enkelt och minimalistiskt.
Det erbjuder asynkron I/O utan callbacks, så vi kommer inte att ha den spagetti-kod som vi ibland kan få i NodeJS.
Det har en enkel distribution, eftersom vi bara behöver NGINX med rätt modul och vår kod, så fungerar allt direkt.
Ett stort och lyhört community.

Jag gick inte in på detaljer om hur routing görs, det skulle ha blivit en mycket lång berättelse.

Tack för uppmärksamheten!