🥇Tarantool hylki: að skera Lua bakenda í þrjár línur

Hjá Mail.ru Group höfum við Tarantool - þetta er forritaþjónn í Lua, sem einnig virkar sem gagnagrunnur (eða öfugt?). Það er fljótlegt og flott, en möguleiki eins netþjóns er samt ekki ótakmarkaður. Lóðrétt mælikvarði er heldur ekki töfralausn, svo Tarantool hefur verkfæri fyrir lárétta mælikvarða - vshard eininguna [1]. Það gerir þér kleift að klippa gögn yfir nokkra netþjóna, en þú verður að fikta við þau til að setja þau upp og festa viðskiptarökfræðina við.

Góðar fréttir: við höfum safnað nokkrum stórum skotum (td [2], [3]) og búið til annan ramma sem mun einfalda verulega lausnina á þessu vandamáli.

Tarantool skothylki er nýr rammi til að þróa flókin dreifð kerfi. Það gerir þér kleift að einbeita þér að því að skrifa viðskiptarökfræði í stað þess að leysa innviðavandamál. Fyrir neðan klippuna mun ég segja þér hvernig þessi rammi virkar og hvernig á að skrifa dreifða þjónustu með því að nota það.

Hvað nákvæmlega er vandamálið?

Við erum með tarantúlu, við höfum vshard - hvað meira gætirðu viljað?

Í fyrsta lagi er þetta spurning um þægindi. Vshard stillingin er stillt í gegnum Lua töflur. Til að dreift kerfi margra Tarantool ferla virki rétt verður uppsetningin að vera sú sama alls staðar. Enginn vill gera þetta handvirkt. Þess vegna eru notuð alls kyns forskriftir, Ansible og dreifingarkerfi.

Hylkið sjálft stjórnar vshard stillingunum, það gerir þetta út frá því eigin dreifða uppsetningu. Það er í rauninni einföld YAML skrá, afrit af henni er geymt í hverju Tarantool dæmi. Einföldunin er sú að umgjörðin sjálf fylgist með uppsetningu hennar og tryggir að hún sé eins alls staðar.

Í öðru lagi er þetta aftur þægindaatriði. Vshard uppsetningin hefur ekkert með þróun viðskiptarökfræði að gera og dregur aðeins athygli forritarans frá vinnu hans. Þegar rætt er um arkitektúr verkefnis er oftast talað um einstaka þætti og samspil þeirra. Það er of snemmt að hugsa um að útbúa þyrping í 3 gagnaver.

Við leystum þessi vandamál aftur og aftur og á einhverjum tímapunkti tókst okkur að þróa nálgun sem einfaldaði vinnu með forritið í gegnum allan lífsferil þess: sköpun, þróun, prófun, CI/CD, viðhald.

Cartridge kynnir hugmyndina um hlutverk fyrir hvert Tarantool ferli. Hlutverk eru hugtak sem gerir forritara kleift að einbeita sér að því að skrifa kóða. Hægt er að keyra öll hlutverk sem til eru í verkefninu á einu Tarantool tilviki og þetta mun duga fyrir próf.

Helstu eiginleikar Tarantool skothylkis:

sjálfvirk þyrping;
auka virkni forritsins með því að nota ný hlutverk;
umsóknarsniðmát fyrir þróun og dreifingu;
innbyggð sjálfvirk klipping;
samþætting við Luatest prófunarrammann;
klasastjórnun með því að nota WebUI og API;
pökkunar- og dreifingartæki.

Halló heimur!

Ég get ekki beðið eftir að sýna umgjörðina sjálfa, svo við látum söguna um arkitektúrinn eftir til seinna og byrjum á einhverju einföldu. Ef við gerum ráð fyrir að Tarantool sjálft sé þegar uppsett, þá er allt sem eftir er að gera

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Þessar tvær skipanir munu setja upp skipanalínutólin og gera þér kleift að búa til fyrsta forritið þitt úr sniðmátinu:

$ cartridge create --name myapp

Og þetta er það sem við fáum:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

Þetta er git geymsla með tilbúnu „Halló, heimur!“ umsókn. Við skulum reyna að keyra það strax, eftir að hafa áður sett upp ósjálfstæðin (þar á meðal rammann sjálfan):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Svo, við erum með einn hnút í gangi fyrir framtíðar rifta forritið. Forvitinn leikmaður getur strax opnað vefviðmótið, stillt þyrping af einum hnút með músinni og notið niðurstöðunnar, en það er of snemmt að gleðjast. Enn sem komið er getur forritið ekki gert neitt gagnlegt, svo ég segi þér frá dreifingunni síðar, en nú er kominn tími til að skrifa kóða.

Umsóknarþróun

Ímyndaðu þér, við erum að hanna verkefni sem verður að taka við gögnum, vista þau og búa til skýrslu einu sinni á dag.

Við byrjum að teikna skýringarmynd og setja þrjá hluti á það: gátt, geymsla og tímaáætlun. Við erum að vinna í arkitektúrnum frekar. Þar sem við notum vshard sem geymslu, bætum við vshard-beini og vshard-storage við kerfið. Hvorki gáttin né tímaáætlunin munu hafa beinan aðgang að geymslunni; það er það sem beininn er fyrir, það er það sem hann var búinn til.

Þessi skýringarmynd sýnir samt ekki nákvæmlega það sem við munum byggja í verkefninu vegna þess að íhlutirnir líta út fyrir að vera óhlutbundnir. Við þurfum enn að sjá hvernig þessu verður varpað á hið raunverulega Tarantool - við skulum flokka íhluti okkar eftir ferli.

Það þýðir lítið að hafa vshard-router og gátt í aðskildum tilvikum. Af hverju þurfum við að vafra um netið aftur ef þetta er nú þegar á ábyrgð beinisins? Þeir verða að vera keyrðir í sama ferli. Það er, bæði gátt og vshard.router.cfg eru frumstillt í einu ferli og láta þau hafa samskipti á staðnum.

Á hönnunarstigi var þægilegt að vinna með þrjá þætti, en ég, sem verktaki, á meðan ég skrifa kóðann, vil ekki hugsa um að ræsa þrjú tilvik af Tarnatool. Ég þarf að keyra próf og athuga hvort ég hafi skrifað gáttina rétt. Eða kannski vil ég sýna samstarfsmönnum mínum eiginleika. Af hverju ætti ég að fara í gegnum það vesen að dreifa þremur eintökum? Þannig varð hugmyndin um hlutverk til. Hlutverk er venjuleg luash eining þar sem líftíma hennar er stjórnað af Cartridge. Í þessu dæmi eru fjórir þeirra - gátt, leið, geymsla, tímaáætlun. Það gæti verið meira í öðru verkefni. Hægt er að keyra öll hlutverk í einu ferli og þetta verður nóg.

Og þegar kemur að dreifingu til sviðsetningar eða framleiðslu, þá munum við úthluta hverju Tarantool ferli sínu eigin hlutverki eftir vélbúnaðargetu:

Topology stjórnun

Upplýsingar um hvar hvaða hlutverk eru í gangi verða að vera geymdar einhvers staðar. Og þetta „einhvers staðar“ er dreifða uppsetningin, sem ég nefndi þegar hér að ofan. Það mikilvægasta við það er þyrpingasvæðifræðin. Hér eru 3 afritunarhópar af 5 Tarantool ferlum:

Við viljum ekki missa gögn, svo við förum varlega með upplýsingar um keyrslu ferla. Hylkið heldur utan um uppsetninguna með því að nota tveggja fasa skuldbindingu. Þegar við viljum uppfæra stillingarnar, athugar það fyrst að öll tilvik séu tiltæk og tilbúin til að samþykkja nýju stillingarnar. Eftir þetta beitir annar áfangi stillingunni. Þannig að jafnvel þótt eitt eintak reynist vera tímabundið ófáanlegt mun ekkert slæmt gerast. Stillingunni verður einfaldlega ekki beitt og þú munt sjá villu fyrirfram.

Einnig í staðfræðihlutanum er svo mikilvæg færibreyta sem leiðtogi hvers afritunarhóps tilgreindur. Venjulega er þetta afritið sem verið er að taka upp. Afgangurinn er oftast skrifvarinn, þó það geti verið undantekningar. Stundum eru hugrakkir verktaki ekki hræddir við árekstra og geta skrifað gögn á nokkrar eftirmyndir samhliða, en það eru nokkrar aðgerðir sem, sama hvað, ætti ekki að framkvæma tvisvar. Fyrir þetta er merki um leiðtoga.

Líf hlutverka

Til að óhlutbundið hlutverk sé til í slíkum arkitektúr verður ramminn að stjórna þeim einhvern veginn. Auðvitað á sér stað stjórn án þess að endurræsa Tarantool ferlið. Það eru 4 hringingar til að stjórna hlutverkum. Hylkið sjálft mun kalla þá eftir því sem er skrifað í dreifðri uppsetningu þess, og beitir þannig uppsetningunni á tiltekin hlutverk.

function init()
function validate_config()
function apply_config()
function stop()

Hvert hlutverk hefur hlutverk init. Það er kallað einu sinni annað hvort þegar hlutverkið er virkt eða þegar Tarantool er endurræst. Þar er til dæmis þægilegt að frumstilla box.space.create, eða tímaáætlunarmaðurinn getur ræst einhvern bakgrunnsþráð sem mun framkvæma vinnu með ákveðnu millibili.

Ein aðgerð init er kannski ekki nóg. Hylkið gerir hlutverkum kleift að nýta dreifðu uppsetninguna sem það notar til að geyma staðfræði. Við getum lýst yfir nýjum hluta í sömu uppsetningu og geymt brot af viðskiptauppsetningu í honum. Í mínu dæmi gæti þetta verið gagnaskema eða áætlunarstillingar fyrir tímaáætlunarhlutverkið.

Klasasímtöl validate_config и apply_config í hvert skipti sem dreifða uppsetningin breytist. Þegar stillingu er beitt með tveggja fasa skuldbindingu, athugar þyrpingin að hvert hlutverk sé tilbúið til að samþykkja þessa nýju stillingu og, ef nauðsyn krefur, tilkynnir notanda villu. Þegar allir eru sammála um að uppsetningin sé eðlileg, þá apply_config.

Einnig hafa hlutverk aðferð stop, sem þarf til að hreinsa upp afrakstur hlutverksins. Ef við segjum að tímaáætlun sé ekki lengur þörf á þessum netþjóni, getur það stöðvað þá trefjar sem það byrjaði með init.

Hlutverk geta haft samskipti sín á milli. Við erum vön að skrifa fallköll í Lua, en það getur gerst að tiltekið ferli hafi ekki það hlutverk sem við þurfum. Til að auðvelda símtöl yfir netið notum við rpc (remote procedure call) aukaeininguna, sem er byggð á grunni venjulegs netboxs sem er innbyggt í Tarantool. Þetta getur verið gagnlegt ef, til dæmis, hliðið þitt vill beint biðja tímaáætlunarmanninn um að vinna verkið núna, frekar en að bíða í dag.

Annað mikilvægt atriði er að tryggja bilanaþol. Hylkið notar SWIM samskiptareglur til að fylgjast með heilsu [4]. Í stuttu máli skiptast ferli á „sögusögnum“ sín á milli um UDP - hvert ferli segir nágrönnum sínum nýjustu fréttirnar og þeir bregðast við. Ef svarið kemur skyndilega ekki, byrjar Tarantool að gruna að eitthvað sé að, og eftir smá stund segir það dauðann og byrjar að segja öllum í kringum þessar fréttir.

Byggt á þessari samskiptareglu, skipuleggur Cartridge sjálfvirka bilunarvinnslu. Hvert ferli fylgist með umhverfi sínu og ef leiðtoginn hættir skyndilega að svara getur eftirmyndin tekið við hlutverki þess og Cartridge stillir hlaupandi hlutverkin í samræmi við það.

Þú þarft að vera varkár hér, því tíð skipti fram og til baka getur leitt til gagnaárekstra við afritun. Auðvitað ættirðu ekki að virkja sjálfvirka bilun af handahófi. Við verðum að skilja greinilega hvað er að gerast og vera viss um að afritun brotni ekki eftir að leiðtoginn er endurreistur og kórónu er skilað til hans.

Af öllu þessu gætirðu fengið á tilfinninguna að hlutverk séu svipuð og örþjónustur. Í vissum skilningi eru þeir bara það, aðeins sem einingar í Tarantool ferlum. En það er líka fjöldi grundvallarmuna. Í fyrsta lagi verða öll verkefnishlutverk að búa í sama kóðagrunni. Og öll Tarantool ferlar ættu að vera settir af stað frá sama kóðagrunni, svo að það komi ekki á óvart eins og þegar við reynum að frumstilla tímaáætlunina, en hann er einfaldlega ekki til. Einnig ættir þú ekki að leyfa mismun á kóðaútgáfum, vegna þess að hegðun kerfisins við slíkar aðstæður er mjög erfitt að spá fyrir um og kemba.

Ólíkt Docker getum við ekki bara tekið hlutverk „ímynd“, farið með hana í aðra vél og keyrt hana þar. Hlutverk okkar eru ekki eins einangruð og Docker gámar. Einnig getum við ekki keyrt tvö eins hlutverk á einu tilviki. Hlutverk er annað hvort til eða ekki; í vissum skilningi er það einhleyp. Og í þriðja lagi verða hlutverkin að vera þau sömu innan alls afritunarhópsins, því annars væri það fáránlegt - gögnin eru þau sömu, en uppsetningin er önnur.

Dreifingartæki

Ég lofaði að sýna hvernig Cartridge hjálpar til við að dreifa forritum. Til að gera lífið auðveldara fyrir aðra, pakkar ramma RPM pakka:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Uppsetti pakkinn inniheldur næstum allt sem þú þarft: bæði forritið og uppsettu ósjálfstæðin. Tarantool mun einnig koma á netþjóninn sem háð RPM pakkanum og þjónustan okkar er tilbúin til ræsingar. Þetta er gert í gegnum systemd, en fyrst þarftu að skrifa smá stillingar. Tilgreindu að minnsta kosti URI hvers ferlis. Þrír duga til dæmis.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Hér er áhugaverður blæbrigði. Í stað þess að tilgreina bara tvöfalda samskiptagáttina, tilgreinum við allt almennt heimilisfang ferlisins, þar með talið hýsilheitið. Þetta er nauðsynlegt svo að klasahnútarnir viti hvernig á að tengjast hver öðrum. Það er slæm hugmynd að nota 0.0.0.0 sem auglýsingu_uri vistfangið, það ætti að vera utanaðkomandi IP tölu, ekki socket bind. Án þess mun ekkert virka, svo Cartridge mun einfaldlega ekki leyfa þér að ræsa hnút með röngum advertise_uri.

Nú þegar uppsetningin er tilbúin geturðu hafið ferlana. Þar sem venjuleg kerfiseining leyfir ekki fleiri en einu ferli að hefjast, eru forrit á hylkinum sett upp af svokölluðu. Stundaðar einingar sem virka svona:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Í uppsetningunni tilgreindum við HTTP tengið sem Cartridge þjónar vefviðmótinu á - 8080. Við skulum fara í það og skoða:

Við sjáum að þó að ferlarnir séu í gangi eru þeir ekki enn stilltir. Hylkið veit ekki enn hver ætti að endurtaka sig með hverjum og getur ekki tekið ákvörðun á eigin spýtur, svo það bíður eftir aðgerðum okkar. En við höfum ekki mikið val: líf nýs klasa hefst með uppsetningu fyrsta hnútsins. Síðan munum við bæta hinum við þyrpinguna, úthluta þeim hlutverkum og á þessum tímapunkti má líta á dreifinguna sem lokið.

Við skulum hella upp á glas af uppáhaldsdrykknum þínum og slaka á eftir langa vinnuviku. Hægt er að nota forritið.