Të gjithë ne i duam historitë. Na pëlqen të tregojmë përfitimet, luftërat tona apo thjesht përvojat tona duke u ulur pranë zjarrit.
Sot është një nga ato ditë. Edhe nëse nuk jeni pranë një zjarri, ne kemi një histori për ju. Një histori për mënyrën se si filluam të punojmë me ruajtjen në Tarantool.
Një herë e një kohë, në kompaninë tonë kishte disa "monolite" dhe një "tavan" për të gjithë, të cilit këto monolite i afrohen ngadalë, duke e kufizuar fluturimin e kompanisë tonë dhe zhvillimin tonë. Kishim një kuptim të qartë: një ditë do të përballeshim me këtë tavane.
Sot, ideologjia jonë është ndarja e gjithçkaje, duke filluar nga pajisjet deri tek logjika e biznesit. Si rezultat, ne, për shembull, kemi dy Qendra të Të Dhënave, pothuajse të pavarura në nivelin rrjetor. Në atë kohë, gjithçka ishte krejt ndryshe.
Sot ka shumë mjete dhe burime për të bërë ndryshime si CI/CD, K8S etj. Në kohën "monolite", nuk kishim nevojë për kaq shumë fjalë të huaja. Mjaftonte të rregulloje thjesht "ruajtjen" në bazën e të dhënave.
Por koha kalonte përpara, dhe numri i kërkesave rritej me të. Kur hynim në tregun e vendeve të CIS, ngarkesa në CPU të bazës së të dhënave të monolit të parë nuk u ul kurrë nën 90%, ndërsa RPS qëndronte në 2400. Dhe këto nuk ishin thjesht kërkesa të vogla, por kërkesa të mëdha me shumë verifikime dhe JOIN-e, të cilat mund të kalonin pothuajse gjysmën e të dhënave në një sfond të madh IO.
Kur u shfaqën shitjet me zbritje në "Black Friday", - dhe Wildberries filloi t'i organizonte ato një nga të parët në Rusi, situata u bë krejtësisht e trishtuar. Sepse ngarkesa në ato ditë rritej tri herë.
Ah, ato "koha monolite"! Jam i sigurt që edhe ju keni hasur në diçka të tillë, dhe ende nuk mund ta kuptoni se si mund t'ju ndodhte kjo.
ĂfarĂ« mund tĂ« bĂ«jmĂ« - moda Ă«shtĂ« e pranishme edhe nĂ« teknologji. Rreth pesĂ« vjet mĂ« parĂ«, na u desh tĂ« rishqyrtonim njĂ« nga kĂ«to moda nĂ« formĂ«n e njĂ« uebfaqeje nĂ« .NET dhe MS SQL Server, e cila ruante me kujdes gjithĂ« logjikĂ«n e funksionimit tĂ« vet. E ruante kaq me kujdes, saqĂ« ndarja e njĂ« monoliti tĂ« tillĂ« dukej si njĂ« kĂ«naqĂ«si e gjatĂ« dhe tepĂ«r e vĂ«shtirĂ«.
Një shpërthim i vogël.
Në ngjarje të ndryshme them: "nëse nuk keni ndarë një monolit, do thotë se nuk keni ecur përpara!" Interesi juaj në këtë temë, ju lutem shkruani në komentet.
Dhe ra goditja
Kthehemi te "zjarri" ynë. Për të shpërndarë ngarkesën e funksionalitetit "monolit", ne vendosëm të ndajmë sistemin në mikroshërbime, të bazuar në teknologji opensource. Sepse, së paku, shkalla e tyre është më e lirë. Dhe kishim 100% të qartë se do të duhej të shkallëzonim (dhe mjaft). Sepse, që atëherë ishim në gjendje të hynim në tregjet e vendeve fqinje, dhe numri i regjistrimeve, ashtu si dhe numri i porosive, filloi të rritet edhe më shumë.
Pas analizimit të pretendentëve të parë për daljen nga monoliti në mikroshërbime, kuptuam se në 80% prej tyre, shënimi në to 99% vinte nga sistemet back office, ndërsa leximi - nga fronti. Kjo i përkiste kryesisht dy nën-sistemeve të rëndësishme për ne - të dhënave të përdoruesve dhe sistemit për llogaritjen e çmimit përfundimtar të produkteve në bazë të informacionit mbi zbritjet e klientëve dhe kuponët.
Për të bërë një shpërthim. Tani është e frikshme të imagjinoni, por përveç nën-sistemeve të përmendura më sipër, nga monoliti ynë u larguan gjithashtu katalogët e produkteve, karroca e përdoruesve, sistemi i kërkimit të produkteve, sistemi i filtrimit të katalogëve të produkteve dhe një sërë sistemesh rekomandimi. Për të punuar për secilin prej tyre ka klasa të veçanta sistemesh të ngushta, por një herë ata të gjithë jetonin në një "shtëpi".
Plani ynë ishte që të nxirrnim të dhënat për klientët tanë në një sistem të ndarë. Ndërsa funksionaliteti për llogaritjen e çmimit përfundimtar të produkteve kërkonte shkallëzim të mirë për leximin, pasi krijonte ngarkesën më të madhe të RPS dhe ishte më e vështirë për t'u realizuar për bazën (shumë të dhëna ishin të angazhuara në procesin e llogaritjes).
Si rezultat, na lindi një skemë që kombinonte mirë me Tarantool.
Në atë kohë, për punën e mikroshërbimeve u zgjodhën skema të punës me disa Qendra të Të Dhënave në makinat virtuale dhe ato fizike. Siç tregohet në ilustrime, u përdorën opsione të replikimit në Tarantool si në mënyrën master-master, ashtu edhe master-slave.
Arkitektura. Variant 1. Shërbimi i përdoruesve
Aktualisht kjo është 24 shard-e, në secilin prej të cilave ka 2 instanca (një për çdo Qendër të Të Dhënave), të gjitha në mënyrën master-master.
Nën DB ndodhen aplikacione që komunikojnë me replikat e DB. Aplikacionet funksionojnë me Tarantool përmes bibliotekës sonë të personalizuar, që implementon ndërfaqen e drejtorit Go për Tarantool. Ajo sheh të gjitha replikat dhe mund të punojë me masterin për lexim dhe shkrim. Në thelb, implementon modelin e grupit të replikave, në të cilin është shtuar logjika e zgjedhjes së replikave, ekzekutimit të përpjekjeve të ripërsëritura, circuit breaker dhe limitimin e normës.
Po ashtu, ka mundësinë për të konfiguruar politikën e zgjedhjes së replikës në nivelin e shardit. Për shembull, me metoda të rastësishme.
Arkitektura. Opcioni 2. Shërbimi për llogaritjen e çmimit fundor të produktit
Disa muaj më parë, shumica e kërkesave për llogaritjen e çmimit fundor të produkteve kaluan në një shërbim të ri, i cili në parim funksionon pa bazë të dhënash, por një kohë më parë, 100% e kërkesave u përpunuan nga shërbimi me Tarantool në sfond.
DB e shĂ«rbimit ka 4 mastera, nĂ« tĂ« cilat sinkronizuesi mbledh tĂ« dhĂ«nat, dhe secili nga kĂ«ta mastera me replikimin shpĂ«rndan tĂ« dhĂ«nat nĂ« replikat readonly. Ădo master ka rreth 15 tĂ« tillĂ« replikash.
Në të dy skemat, në rast të papërfshirjes së një DC, aplikacioni mund të marrë të dhëna nga e dyta.
Vlen të përmendet se në Tarantool replikimi është mjaft fleksibël dhe konfigurohet në runtime. Në sisteme të tjera, ka pasur vështirësi. Për shembull, për të ndryshuar parametrat max_wal_senders dhe max_replication_slots në PostgreSQL është e nevojshme të rinisni masterin, që në disa raste mund të çojë në ndërprerjen e lidhjeve ndërmjet aplikacionit dhe DB.
Kërkoni dhe do të gjeni!
Pse nuk e bëmë «si njerëzit normalë», por zgjodhëm një qasje jo të zakonshme? Varet se çfarë e konsideroni normal. Shumë e bëjnë një grup nga Mongo dhe e shpërndajnë atë në tri DC të shpërndara gjeografikisht.
NĂ« atĂ« kohĂ«, ne kishim tashmĂ« dy projekte mbi Redis. E para â cache, dhe e dyta ishte njĂ« ruajtĂ«s i vazhdueshĂ«m pĂ«r tĂ« dhĂ«na qĂ« nuk ishin shumĂ« kritike. Me kĂ«tĂ« tĂ« fundit kishte vĂ«shtirĂ«si, pĂ«r pjesĂ« tĂ« cilĂ«s kĂ«rkesat. NdonjĂ«herĂ« volume tĂ« mĂ«dha ishin nĂ« çelĂ«s, dhe herĂ« pas here faqja shfaqte probleme. Kjo sistem ishte pĂ«rdorur nĂ« variantin master-slave. Kishte shumĂ« raste kur ndodhte diçka me masterin dhe replikimi prishej.
Pra, Redis është i mirë për detyrat stateless, jo për ato stateful. Në thelb, ai lejonte zgjidhjen e shumicës së detyrave, por vetëm nëse ishin zgjidhje key-value me disa indekse. Por në atë kohë, Redis kishte probleme me peristencën dhe replikimin. Për më tepër, kishte ankesa për performancën.
Kishim menduar për MySQL dhe PostgreSQL. Por i pari nuk ishte mirëpritur nga ne, ndërsa i dyti është një produkt mjaft i sofistikuar, dhe ndërtimi i shërbimeve të thjeshta mbi të do të ishte joefektiv.
Provuam RIAK, Cassandra, madje edhe një DB grafike. E gjithë kjo është mjaft niche dhe nuk i përshtatej rolit si një mjet universale për krijimin e shërbimeve.
Në fund, vendosëm për Tarantool.
Ne i kemi drejtuar asaje kur ishte në versionin 1.6. Na tërhoqi kombinimi i key-value me funksionalitetin e një DB të relacional. Ka indekse dytësore, transaksione dhe hapësira, ato janë si tavolina, por jo të thjeshta, mund të ruhet një numër i ndryshëm kolonash. Por veçoria kryesore e Tarantool ishte indekset dytësore në kombinim me key-value dhe transaksionalitetin.
Po ashtu, komuniteti i përgjegjshëm anglishtfolës luajti një rol, i gatshëm të ofronte ndihmë në bisedë. Ne e kemi përdorur këtë aktivisht dhe jetonim në bisedë. Dhe nuk duhemi të harrojmë një peristencë të mirë pa gabime të dukshme. Nëse shohim historinë tonë me Tarantool, kemi pasur shumë vështirësi dhe gabime me replikimin, por asnjëherë nuk kemi humbur të dhëna për shkak të saj!
Zbatimi filloi me vështirësi
Në atë kohë, stoku ynë kryesor i zhvillimit ishte .NET, për të cilin nuk kishte konektor për Tarantool. Ne filluam menjëherë të bënim diçka në Go. Edhe me Lua dilte mirë. Problemi kryesor në atë kohë ishte debugging: në .NET ishte shkëlqyer, por më pas kalimi në botën e embedded Lua, kur nuk kishit as ndihma përveç logeve, ishte mjaft e vështirë. Për më tepër, replikimi për një arsye ndodhte herë pas here, na duhej të thellohemi në funksionimin e motorit Tarantool. Kjo u ndihmua nga biseda, në një masë më të vogël nga dokumentacioni, ndonjëherë shihnim edhe kodin. Në atë kohë dokumentacioni ishte mjaft i dobët.
Njësoj, për disa muaj, mblodhëm përvojë dhe arritëm rezultate të kënaqshme në punën me Tarantool. Organizuam në git përvojat standarde që ndihmonin në formimin e mikrosherbimeve të reja. Për shembull, kur shfaqej kërkesa: për të krijuar një mikrosherbim tjetër, zhvilluesi shihte kodin burimor të zgjidhjes standarde në repository, dhe krijimi i një të re duhej të merrte jo më shumë se një javë.
Ishin ishinin koha të veçanta. Mund të thoshim se atëherë mund të shkoje te admini në tavolinën e përbese dhe të kërkoje: "Më jep një virtuale". Pas 30 minutash, makina do të ishte tashmë te ti. Ti lidheshe vetë, instalove gjithçka dhe ata të sillnin trafik për të.
Sot kjo nuk funksionon më: duhet të vendosësh monitorim në shërbim, regjistrim, të mbulosh funksionalitetin me teste, të porosisësh një virtuale ose një shpërndarje në Kubernetes etj. Në përgjithësi, kështu është më mirë, edhe pse më e gjatë dhe me më shumë mundime.
Ndaje dhe qeverise. Si qëndron çështja me Lua?
Ishin dilema serioze: disa ekipe nuk arrinin të nxjerrin me besueshmëri ndryshimet në shërbim me shumë logjikë në Lua. Shpesh, kjo shoqërohej me mosfunksionimin e shërbimit.
Pra, zhvilluesit përgatitnin një ndryshim. Tarantool fillonte migrimin, ndërsa një riprodhim kishte ende kodin e vjetër; aty mbërrinte një DDL përmes riprodhimit, diçka tjetër, dhe kodi thjesht shkatërrohej, sepse kjo nuk ishte parashikuar. Si rezultat, procedura e përditësimit për adminët ishte e shkruar në një fletë A4: ndaloni riprodhimin, përditësoni këtë, aktivizoni riprodhimin, çaktivizoni këtu, përditësoni atje. Një makth!
Tani, ne zakonisht përpiqemi të mos bëjmë asgjë në Lua. Thjesht me ndihmën e iproto (protokolli binar për komunikimin me serverin), dhe gjithçka. Ndoshta, kjo është një papërgatitje e njohurive te zhvilluesit, por nga kjo pikëpamje sistemi është i komplikuar.
Nuk ndjekim gjithmonë verbërisht këtë skenar. Sot nuk kemi të zezë dhe të bardhë: ose gjithçka në Lua, ose gjithçka në Go. Tani e kuptojmë se si mund ta kombinojmë, për të mos marrë më pas probleme me migrimin.
Ku ka aktualisht Tarantool?
Tarantool përdoret në shërbimin e llogaritjes së kostos përfundimtare të produkteve me llogaritjen e kuponëve të zbritjes, ndryshe "Promotajzer". Siç thashë më parë, tani ai po dalë nga skena: e zëvendëson një shërbim të ri katalogu me çmimet e parakalkuluara, por gjashtë muaj më parë të gjitha llogaritjet bëheshin në "Promotajzer". Më parë gjysma e logjikës së tij ishte e shkruar në Lua. Dy vjet më parë krijuam një depo nga shërbimi dhe logjika u kalua në Go, sepse mekanika e punës së zbritjeve paksoi dhe shërbimit i mungonte performanca.
Një nga shërbimet më kritike është profili i përdoruesit. Kështu që të gjithë përdoruesit e Wildberries ruhen në Tarantool, dhe ata janë rreth 50 milion. Një sistem i ndarë sipas ID-së së përdoruesit, i shpërndarë në disa DC me lidhje në shërbimet Go.
Dikur lider në RPS ishte "Promotajzer", duke arritur deri në 6000 kërkesa. Në një moment, ne kishim 50-60 instanca. Tani lideri në RPS është profili i përdoruesit, rreth 12000. Në këtë shërbim aplikohet një ndarje e personalizuar me ndarjen sipas intervaleve të ID-ve të përdoruesve. Shërbimi shërben mbi 20 makina, por kjo është tepër shumë, planifikojmë të zvogëlojmë resurset e rezervuara, sepse ka mjaftueshëm kapacitet 4-5 makinash.
Shërbimi i seancave është shërbimi ynë i parë në vshard dhe Cartridge. Konfigurimi i vshard dhe përditësimi i Cartridge kërkuan nga ne disa përpjekje, por në fund gjithçka funksionoi.
Shërbimi për tregimin e banerëve të ndryshëm në faqe dhe në aplikacionin mobil ishte një nga të parët që u lëshua menjëherë në Tarantool. Ky shërbim është i njohur për faktin se është rreth 6-7 vjeç, ai është ende aktiv dhe nuk ka pasur asnjëherë një rimëkëmbje. U përdor replikimi master-master. Kurrë nuk është prishur asgjë.
Ka një shembuj të përdorimit të Tarantool për funksionalitetin e katalogëve të shpejtë në sistemin e magazinës, për të verifikuar shpejt informacionin në disa raste. Kemi provuar të përdorim Redis për këtë qëllim, por të dhënat në memorie merrnin më shumë hapësirë se në Tarantool.
Shërbimet e listës së pritjes, abonimet e klientëve, storjet aktualisht të modës dhe produktet e vonuara gjithashtu punojnë me Tarantool. Shërbimi i fundit në memorie ndalon rreth 120 GB. Ky është shërbimi më voluminoz nga të gjithë të mësipërmit.
PĂ«rfundimi
Falë indekseve të dyta në përputhje me key-value dhe transaksionet, Tarantool përshtatet shumë mirë për arkitekturën bazuar në mikroshërbime. Megjithatë, hasëm vështirësi kur nxorrëm ndryshimet në shërbimet me shumë logjikë në Lua - shërbimet shpesh ndalonin së punuari. Të hapur e përballëm këtë, dhe me kalimin e kohës arritëm në kombinime të ndryshme të Lua dhe Go: dimë se kur duhet të përdorim një gjuhë dhe kur tjetrën.
ĂfarĂ« tjetĂ«r tĂ« lexoni nĂ« kĂ«tĂ« temĂ«
- Krijojmë nga e para një aplikacion me ngarkesë të lartë në Tarantool
- Zgjedhja e besueshme e liderit në Tarantool Cartridge
- Kanal i Telegramit Tarantool me lajmet mbi produktin
- Diskutoni Tarantool në bisedën e komunitetit
Burimi: habr.com
