Me taas avaldame konverentsi ettekande transkriptsiooni HighLoad++ 2016. aastal, mis toimus Moskva lähistel Skolkovo 7–8. novembril möödunud aastal. Vladimir Protasov räägib, kuidas laiendada NGINX-i funktsionaalsust OpenResty ja Lua abil.

Tere kõigile, minu nimi on Vladimir Protasov, ma töötan Parallelsis. Räägin veidi endast. Kolm neljandikku oma elust olen ma kirja pannud koodi. Olen tõeline programmeerija: mõnikord näen ma unes koodi. Üks neljandik elust — tööstuslik arendus, koodi kirjutamine, mis läheb otse tootmisse. Kood, millega mõned teist kasutavad, aga ei pruugi sellest teadlikud olla.

Et te mõistaksite, kui halb see kõik oli. Kui olin noor algaja, tulin kohale ja mulle anti kahesaja terabaidi andmebaasid. Nüüd on kõigil siin highload. Käisin konverentsidel ja küsisin: «Kuidas, räägi, teil on big data, kõik on lahe? Kui suur on teie andmebaas?» Nad vastasid: «Meil on 100 gigabaiti!» Ma ütlesin: «Lahe, 100 gigabaiti!» Samas mõtlesin, kuidas säilitada rahulik nägu. Mõtled, et jah, need tüübid on ägedad, ja siis tuled tagasi ja tegeled nende mitme terabaidi andmebaasidega. Ja see kõik — olles algaja. Kas te oskate ette kujutada, kui suur see löök oli?

Ma tunnen üle 20 programmeerimiskeele. See on see, millega pidin töö käigus kokku puutuma. Sulle antakse koodi Erlangis, C-s, C++-s, Luas, Pythonis, Ruby's jne, ja sa pead sellega hakkama saama. Ühesõnaga, pidin. Täpset arvu kokku lugeda ei õnnestunud, aga kuskil 20 on kaotsi läinud.

Kuna kõik kohalolijad teavad, mis on Parallels ja millega me tegeleme, ei hakka ma rääkima, kui ägedad me oleme ja mida teeme. Räägin ainult, et meil on 13 kontorit üle maailma, rohkem kui 300 töötajat, arendus Tallinnas, Moskvas ja Maltal. Soovi korral saab Maltale kolida, kui talvel on külm ja tahad end soojendada.

Meie osakond kirjutab Python 2-s. Me tegeleme ärihuvidega ja meil pole aega modernsete tehnoloogiate juurutamiseks, seetõttu kannatame. Meil on Django, sest seal on kõik olemas, ja üleliigse viskame minema. Samuti MySQL, Redis ja NGINX. Meil on ka palju muid lahedaid asju. Meil on MongoDB, meie vahel jooksevad küülikud, meil on kõike — aga see ei ole minu osa ja sellega ma ei tegele.

OpenResty

Oma kohta rääkisin. Olgem nüüd selged, millest ma täna räägin:

Mis on OpenResty ja millega seda süüakse?
Miks välja mõtlema veel ühte jalgratast, kui meil on olemas Python, NodeJS, PHP, Go ja muud ägedad asjad, millega kõik on rahul?
Veidi elulisi näiteid. Mul tuli esitluse mahtu märgatavalt vähendada, kuna see venis koguni 3,5 tunni pikkuseks, seega näiteid jääb vähemaks.

OpenResty on NGINX. Tänu sellele on meil täieõiguslik veebiserver, mis on kenasti kirjutatud ja töötab kiiresti. Ma arvan, et enamik meist kasutab NGINX-i tootmises. Te kõik teate, et see on kiire ja äge. Sellel on suurepärane sünkrone sisend/väljund, seega ei pea me mitut jalgratast leiutama nagu Pythonis, kus gevent on leiutatud. Gevent on äge, aga kui kirjutate C-keelt ja midagi läheb valesti, siis geventi tõrgete leidmine ajab teid hulluks. Mul oli kogemus, kus kulus lausa kaks päeva, et mõista, mis valesti läks. Kui keegi poleks eelnevalt nädalaid kaevanud, probleemi leidnud, sellest Internetis kirjutanud ja Google seda leidnud, siis oleksime täiesti hullu läinud.

NGINX-is on juba olemas vahemälu ja staatiline sisu. Te ei pea muretsema selle üle, kuidas seda korralikult teha, et kuskil ei tekiks takistusi ja et te ei kaotaks kirjeldusi. Nginx-i on väga mugav kasutada, teil ei pea olema peamurdmist selle üle, mida valida - WSGI, PHP-FPM, Gunicorn, Unicorn. Paigaldage Nginx, andke adminstratsioonile, nad teavad, kuidas sellega töötada. Nginx töötleb päringud struktureeritult. Räägin sellest veidi hiljem. Lühidalt on sellel faas, kui see vastuvõtt, teine faas, kui see töötleb, ja kolmas, kui see edastab sisu kasutajale.

Nginx on äge, kuid on üks probleem: see ei ole piisavalt paindlik isegi kõikide nende ägedate funktsioonide puhul, mida arendajad on seadistusse lisanud. Seda võimu on liiga vähe. Seetõttu integreerisid Taobao arendajad sinna kunagi ammu, umbes kaheksa aastat tagasi, Lua. Mida see annab?

Suurus. See on väike. LuaJIT annab umbes 100-200 kilobaiti mälu ülekaalu ja minimaalset jõudluse ülekaalu.
Kiirus. LuaJIT tõlkija on paljudes olukordades C lähedane, mõnedes olukordades jääb see Java-le alla ja mõnedes olukordades ületab selle. Teatud aja jooksul peeti seda parimaks, ägedaimaks JIT-kompilaatoriks. Praegu on olemas veelgi ägedamaid, kuid need on väga rasked, näiteks sama V8. Mõned JS tõlkijad ja Java HotSpot on mõnes punktis kiiremad, kuid teistes kohtades jäävad endiselt alla.
Lihtsus omandamisel. Kui teie koodibaas on näiteks Perl, ja te ei ole Booking, siis te ei leia Perl programmeerijaid. Sest neid ei ole, kõik on nad ära viidud ja nende õpetamine on pikaldane ja keeruline. Kui soovite programmeerijaid millegi muu jaoks, siis võib-olla tuleb ka neid ümber koolitada või leida. Lua puhul on kõik lihtne. Lua õpib ükskõik milline algaja kolme päevaga. Mul kulus umbes kaks tundi, et selgeks saada. Kaks tundi hiljem kirjutasin ma juba tootmises koodi.

Tulemus välja näeb nii:

Siin on palju asju. OpenResty's on kogutud hulk mooduleid, nii Luaga kui ka NGINXiga. Ja teil on kõik valmis - sõlmitud ja töötab.

Näited

Lõpetame luule, liikuge koodi juurde. Siin on väike Hello World:

Mida siin on? See on NGINXi location. Me ei vaeva end, me ei kirjuta oma suunamist ega kasuta mingit valmis - meil on juba NGINXis olemas, elame hästi ja laiskade elu.

content_by_lua_block – see on plokk, mis ütleb, et anname conteneti edasi Lua skripti abil. Võtame NGINXi muutuja remote_addr ja paneme selle sisse string.format. See on sama, mis sprintf, ainult et Lua-s, ainult õige. Ja anname selle kliendile.

Tulemus näeb välja nii:

Aga naaseme reaalsesse maailma. Tootmises ei saa keegi Hello World'i. Meie rakendus käib enamasti andmebaasi või mujale ja suure osa ajast ootab vastust.

Lihtsalt istub ja ootab. See ei ole väga hea. Kui tuleb 100 000 kasutajat, siis on meil väga raske. Seetõttu looge näiteks lihtne rakendus. Otsime pilte, näiteks kasse. Ainult et me ei otsi lihtsalt, vaid laiendame märksõnu ja kui kasutaja otsib 'kutsikaid', siis leiame me kassid, karvased ja muud. Esiteks peame saama taotluse andmed tagaküljel. See näeb välja nii:

Kaks rida võimaldavad teil GET-parameetreid kätte saada, ei mingeid raskusi. Edasi saame näiteks andmebaasist märksõna ja laienduse tabelist selle teabe tavalise SQL-päringuga. Kõik on lihtne. See näeb välja nii:

Ühendame raamatukogu resty.mysql, mis on meil juba komplektis. Me ei pea midagi installima, kõik on valmis. Näitame, kuidas ühenduda ja teeme SQL-päringu:

Siin on natuke hirmutav, aga kõik toimib. Siin on 10 — see on limiit. Me võtame välja 10 kirjeid, me oleme laiskad, ei taha rohkem näidata. SQLis unustasin ma limiidi.

Edasi otsime pilte kõikide päringute põhjal. Kogume hunniku päringuid ja täidame Lua-tabeli, mis on nimetatud reqs, ja teeme ngx.location.capture_multi.

Kõik need päringud lähevad paralleelselt ja me saame vastused tagasi. Tööaeg on võrdsustatud kõige aeglasema vastuse ajaga. Kui kõik meie päringud tuleb tagasi 50 millisekundi pärast ja me saatsime sada päringut, siis saame vastuse 50 millisekundi pärast.

Kuna me oleme laiskad ja ei taha kirjutada HTTP töötlemist ja vahemälu, siis paneme NGINX'i kõike meie eest tegema. Nagu te nägite, oli seal päring url/fetch, see ongi:

Teeme lihtsa proxy_pass, näitame, kuhu vahemällu salvestada, kuidas seda teha, ja meil kõik töötab.

Aga sellest ei piisa, me peame ka andmed kasutajale andma. Kõige lihtsam mõte on see kõik JSON'i seriaalida, lihtsalt, kahel reabil. Anname Content-Type, anname JSON'i.

Aga on üks raskus: kasutaja ei taha lugeda JSON'i. Peame kaasama frontend arendajad. Mõnikord ei taha me seda alguses teha. Ja SEO spetsialistid ütlevad, et kui me otsime pilte, siis neil pole vahet. Aga kui me anname mingit sisu, siis nad ütlevad, et meie otsingumootorid ei indekseeri midagi.

Mida sellega teha? Loomulikult anname kasutajale HTML'i. Käsi-käes genereerimine ei ole cool, seega tahame kasutada malle. Selleks on olemas raamatukogu lua-resty-template.

Te olete ilmselt näinud kolme hirmutavat tähte OPM. OpenResty tuleb oma pakihalduriga, mille kaudu saab paigaldada veel palju erinevaid mooduleid, sealhulgas lua-resty-template. See on lihtne malle engine, mis on sarnane Django mallidele. Seal saab kirjutada koodi ja teha muutujate asendusi.

Tulemuseks on, et kõik näeb välja umbes nii:

Me võtsime andmed ja renderdasime malli taas kahe reaga. Kasutaja on õnnelik, sai kassipojad. Kuna me laiendasime päringut, sai ta kassipoja koos merikassiga. Kes teab, võib-olla otsis ta just teda, aga ei osanud oma päringut õigesti formuleerida.

Kõik on hästi, aga me oleme arenduses ja ei taha veel kasutajatele näidata. Tehkem autentimine. Selleks vaatame, kuidas NGINX töötleb päringut OpenResty mõistes:

Esimene faas — access, kui kasutaja alles liitus ja me vaatame teda pealkirjade, IP-aadressi ja muude andmete kaudu. Saame ta kohe välja lülitada, kui ta meile ei meeldi. Seda saab kasutada autoriseerimiseks või kui saame liiga palju päringuid, saame neid hõlpsasti sellel etapil katkestada.
rewrite. Kirjutame mõned päringu andmed ümber.
content. Anname sisu kasutajale.
pealkirjade filter. Muudame vastuse pealkirju. Kui oleme kasutanud proxy_pass, võime kirjutada mõned pealkirjad ümber enne, kui anname need kasutajale.
sisu filter. Saame keha muuta.
log — logimine. Saame kirjutada logisid elasticsearchi ilma lisa kihita.

Meie autoriseerimine näeb välja umbes nii:

Lisame selle sinna asukoht, mille me varem kirjeldasime, ja paneme sinna sellise koodi:

Kontrollime, kas meil on küpsise token. Kui ei, siis suuname autoriseerimise peale. Kasutajad on nutikad ja võivad arvata, et tuleb küpsise token paigaldada. Seetõttu paneme selle ka Redis'sse:

Kood Redisega töötamiseks on väga lihtne ja ei erine teiste keeltest. Samuti on kogu sisend/väljund seal ja siin mitteblokeeriv. Kui kirjutate sünkrontkoodi, töötab see asünkroonselt. Umbes nagu gevent, ainult hästi tehtud.

Teeme autoriseerimise:

Ütleme, et peame lugema päringu keha. Saame POST-argumendid, kontrollime, kas kasutajanimi ja parool on õiged. Kui ei, siis suuname autoriseerimise peale. Ja kui on õiged, siis salvestame tokeni Redis'sse:

Ärge unustage seada küpsist, see tehakse ka kahe reaga:

Lihtne, teoreetiline näide. Me kindlasti ei tee teenust, mis näitab inimestele kiisusid. Kuigi kes teab. Seetõttu käime läbi, mida saab teha tootmisprotsessis.

Minimalistlik backend. Mõnikord vajame backend'ist vaid väga vähe andmeid: kuskil tuleb kuupäeva lisada, kuskil tuua välja mingi nimekiri, öelda, kui palju kasutajaid on praegu saidil, lisada loendaja või statistika. Midagi sarnast väikest. Väikesed osad on väga kergesti teostatavad. Sellega saab kiirelt, lihtsalt ja suurepäraselt hakkama.
Andmete eelprotsessimine. Aegiatseme on meil soov sisestada oma lehe reklaami, ja selle saame API-päringutega. Seda saab siit väga lihtsalt teha. Me ei koorma oma tagakülge, mis samuti raskelt töötab. Me saame seda siin koguda. Saame kokku panna mingit JS-i või vastupidi, lahti võtta ja midagi eeltöödelda enne, kui kasutajale välja anname.
Mikroteenuse liides. See on samuti väga hea lahendus, mida ma olen ellu viinud. Enne seda töötasin ettevõttes Tenzor, mis tegeleb elektroonilise aruandlusega ja tagab aruandluse umbes poolele juriidilistele isikutele riigis. Me tegime teenuse, kus paljusid asju on tehtud sama mehhanismi abil: marsruutimine, autoriseerimine ja muud.
OpenResty't saab kasutada teie mikroteenuste liimimiseks, mis tagab ühtse juurdepääsu kõigile ja ühtse liidese. Kuna mikroteenused võivad olla kirjutatud nii, et siin on Node.js, seal on PHP, seal Python ja kuskil on tükk Erlang, mõistame, et me ei soovi sama koodi igale poole uuesti kirjutada. Seetõttu saab OpenResty't paigutada ette.
Statistika ja analüüs. Tavaliselt on NGINX sissepääsus ja kõik päringud lähevad läbi selle. Just siin on väga mugav midagi kokku koguda. Saab kohe midagi välja arvutada ja kuhugi panna, näiteks Elasticsearchisse, Logstashi või lihtsalt logisse kirja panna ja siis kuhugi saata.
Mitme kasutaja süsteemid. Näiteks, online-mänge on samuti väga hästi teha. Täna räägib Kaplinnas Alexander Gladys, kuidas kiiresti prototüüpida mitme mängijaga mängu OpenResty abil.
Päringute filtreerimine (WAF). Praegu on moes teha erinevaid veebi rakenduste tulemüüre, on palju teenuseid, mis neid pakuvad. OpenResty abil saate enda jaoks luua veebi rakenduste tulemüüri, mis lihtsalt ja kergesti filtreerib päringud vastavalt teie nõudmistele. Kui teil on Python, siis mõistate, et PHP't ei saa kindlasti sisse süstida, kui te, muidugi, ei spawnida seda kuskil konsoolist. Teate, et teil on MySQL ja Python. Tõenäoliselt võivad siin proovida teha mingit katalooge läbivat rünnakut ja midagi sisestada andmebaasi. Seetõttu saab kahtlased päringud kiiresti ja odavalt kohe ees filtrida.
Kogukond. Kuna OpenResty on üles ehitatud NGINX-i baasil, on sellel boonus - see NGINXi kogukondSee on väga suur ja enamik alguses tekkida võivaid küsimusi on juba lahendatud NGINX-i kogukonna poolt.
Lua arendajadEile rääkisin poistega, kes tulid HighLoad++ õppepäevale, ja kuulsin, et ainult Tarantool on kirjutatud Luas. See pole tõsi, Luas on kirjutatud palju. Näiteks: OpenResty, XMPP-server Prosody, mängumootor Love2D, Lua skripteeritakse Warcraftis ja mujal. Lua arendajaid on palju ning neil on suur ja vastutulelik kogukond. Kõik minu küsimused Lua kohta lahendati paaritunniga. Kui kirjutad meililistile, saad sisuliselt mõne minuti jooksul hulga vastuseid, kus seletatakse, kuidas ja mis toimub. See on tõeliselt suurepärane. Kahjuks pole igal pool nii lahke ja abivalmis kogukonda.
OpenResty kohta on olemas GitHub, kus saab avada probleemide pilet, kui midagi on katki. On olemas meililist Google Groupsis, kus saab arutada üldisi küsimusi, samuti on olemas hiinakeelne meililist - äkki sul ei ole inglise keeles oskusi, aga hiina keeles on.

Summary

Loodan, et suutsin edastada, et OpenResty on väga mugav raamistik, mis on suunatud veebile dem.
Sellel on madal sisenemiskünnis, kuna kood sarnaneb sellele, millega me kirjutame, keel on üsna lihtne ja minimalistlik.
See pakub asünkroonset I/O ilma callback'ideta, meil ei tule segadust nagu vahel NodeJS-is kirjutades.
Sellel on lihtne kasutusele võtmine, kuna meil on vaja ainult NGINX-i koos vajaliku mooduliga ja meie kood, ja kõik töötab kohe.
Suur ja vastutulelik kogukond.

Ma ei rääkinud üksikasjalikult marsruutimisest, see oleks saanud väga pikk jutustus.

Aitäh tähelepanu eest!