Të gjithë ne i duam historitë. Na pëlqen të rrëfejmë përfitimet, betejat ose thjesht përvojat tona kur jemi ulur pranë zjarrit.
Sot është një ditë e tillë. Edhe nëse nuk jeni pranë zjarrit, ne kemi një histori për ju. Një histori për mënyrën se si filluam të punojmë me depozitën në Tarantool.
Dikur, në kompaninë tonë kishte disa 'monolite' dhe një 'tavan' që i kufizonte këta monolitë, duke ngadalësuar fluturimin e kompanisë sonë dhe zhvillimin tonë. Kishim një kuptim të qartë: një ditë do të përballemi me këtë tavani.
Tani ideologjia jonë është të gjithë dhe gjithçka ndarë, duke filluar nga pajisjet dhe duke përfunduar me logjikën e biznesit. Si rezultat, tani kemi dy DC, thuajse të pavarur në nivelin rrjet. Por atëherë çdo gjë ishte krejt ndryshe.
Sot ka shumë mjete dhe mënyra për të bërë ndryshime, si CI/CD, K8S dhe të tjerë. Në kohën e 'monolitëve', nuk na duheshin aq shumë fjalë të huaja. Mjaftonte të rregullonim 'depozitën' në bazë.
Por koha kalonte, dhe numri i kërkesave po rritej, duke dërguar RPS herë pas here më lart se kapaciteti ynë. Në daljen në tregun e vendeve të CIS, ngarkesa në procesorin e DB të monolitit të parë nuk zbret nën 90%, ndërsa RPS qëndronte në nivelin 2400. Dhe këto nuk ishin thjesht kërkesa të vogla, por kërkesa të mëdha me shumë kontroll dhe JOIN, që mund të kalonin thuajse gjysmën e të dhënave në një sfond të madh IO.
Kur filluan të shfaqen zbritjet në 'Black Friday', dhe Wildberries ishte një nga të parët që i organizoi ato në Rusi, situata filloi të bëhej shumë e zymtë. Ngarkesa në këto ditë rritet trefish.
O sa mirë që ishin ato 'monolitë! Jam i sigurt që dhe ju jeni ndeshur me diçka të tillë dhe akoma nuk kuptoni si ndodhi kjo me ju.
ĂfarĂ« mund tĂ« bĂ«sh - moda u takon dhe teknologjive. Para rreth 5 vjetĂ«sh, na duhej tĂ« rishikonim njĂ« nga kĂ«to moda, njĂ« sit tĂ« ndĂ«rtuar nĂ« .NET dhe MS SQL-server, i cili ruante me kujdes tĂ« gjithĂ« logjikĂ«n e funksionimit tĂ« sitit. E ruante aq mirĂ«, saqĂ« ndarja e kĂ«tij monoliti rezultoi tĂ« ishte njĂ« kĂ«naqĂ«si e gjatĂ« dhe e komplikuar.
Një shkëputje e vogël.
Në ngjarje të ndryshme, unë them: "nëse nuk e keni prishur monolitin, atëherë nuk jeni rritur!" Më intereson mendimi juaj për këtë, ju lutem ndajnë atë në komentet.
Dhe ra shkuma
Të kthehemi te "zjarri" ynë. Për të shpërndarë ngarkesën e funksionalitetit "monolit", ne vendosëm ta ndajmë sistemin në mikroshërbime, të bazuar në teknologji opensource. Sepse, të paktën, shkallëzimi i tyre është më i lehtë. Dhe ne ishim të vetëdijshëm që do të duhej të shkallëzonim (dhe shumë) me 100%. Sepse që atëherë arritëm të hyjmë në tregjet e kombeve fqinje, dhe numri i regjistrimeve, ashtu si dhe numri i porosive, filloi të rritet edhe më shumë.
Pas analizimit tĂ« kandidatĂ«ve tĂ« parĂ« pĂ«r daljen nga monoliti nĂ« mikroshĂ«rbime, kuptuam se nĂ« 80% tĂ« rasteve shĂ«nimi nĂ« to Ă«shtĂ« 99% nga sistemet back office, ndĂ«rsa leximi Ă«shtĂ« nga pĂ«rparĂ«sitĂ«. Kjo lidhej kryesisht me dy nga nĂ«n-sistemet e rĂ«ndĂ«sishme pĂ«r ne â tĂ« dhĂ«nat e pĂ«rdoruesve dhe sistemi i kalkulimit tĂ« çmimit pĂ«rfundimtar tĂ« produkteve nĂ« bazĂ« tĂ« informacionit mbi zbritjet e klientĂ«ve dhe kuponĂ«t.
Si një këndvështrim. Tani është tmerrshëm të mendoj, por përveç nën-sistemeve të përmendura më sipër, nga monoliti ynë gjithashtu u ndanë katalogët e produkteve, karroca e përdoruesit, sistemi i kërkimit të produkteve, sistemi i filtrimit të katalogjeve të produkteve dhe lloje të ndryshme sistemesh rekomandimi. Për secilin prej tyre ekzistojnë klasa të veçanta të sistemeve të ngushta, por dikur të gjitha ato jetonin në një "shtëpizë".
Ne kishim planifikuar të nxirrnim të dhënat për klientët tanë menjëherë në një sistem të sharduar. Megjithatë, funksionaliteti që lidhet me kalkulimin e çmimit përfundimtar të produkteve kërkonte një shkallëzim të mirë për leximin, sepse ajo krijonte ngarkesën më të madhe në RPS dhe ishte më e komplikuar në ekzekutim për bazën (shumë të dhëna janë të involvuar në procesin e kalkulimeve).
Si rezultat, ne krijuam një skemë që përshtatej mirë me Tarantool.
Në ato kohë, për punën e mikroshërbimeve u zgjodhën skemat për të punuar me disa Qendra të të Dhënave në makina virtuale dhe harduerike. Siç tregohet në ilustrime, u zbatuan opsione të replikimit Tarantool në mënyrë master-master, si dhe master-slave.
Arkitektura. Opsioni 1. Shërbimi i përdoruesve
Në këtë moment ka 24 sharda, në çdo një prej të cilave ka 2 instanca (një për çdo DC), të gjitha në modalitetin master-master.
Në krye të bazës së të dhënave janë aplikacionet që i referohen replika të bazës së të dhënave. Aplikacionet punojnë me Tarantool përmes bibliotekës sonë të personalizuar, e cila implementon ndërfaqen e shoferit Go për Tarantool. Ajo sheh të gjitha replikat dhe mund të punojë me masterin për lexim dhe shk writingim. Në thelb, ajo implementon modelin e grupit të replikave, në të cilin është shtuar logjistika e zgjedhjes së replikave, realizimi i përpjekjeve të përsëritura, kthesa e qarkut dhe kufizimi i normës.
Ka një mundësi për të konfiguruar politikën e zgjedhjes së replikës në kontekstin e shardit. Për shembull, me rrotullim dykahësh.
Arkitektura. Opsioni 2. Shërbimi i llogaritjes së çmimit përfundimtar të produktit.
Disa muaj më parë, pjesa më e madhe e kërkesave për llogaritjen e çmimit përfundimtar të produkteve u transferua në një shërbim të ri, i cili në parim punon pa bazë të dhënash, por ndonjëherë më parë të gjitha 100% u përpunuan nga shërbimi me Tarantool nën kapak.
Baza e tĂ« dhĂ«nave tĂ« shĂ«rbimit pĂ«rbĂ«het nga 4 mastera, nĂ« tĂ« cilat sinkronizatori mbledh tĂ« dhĂ«nat, dhe çdo master nga kĂ«to shpĂ«rndan tĂ« dhĂ«na nĂ« replikat readonly pĂ«rmes replikimit. Ădo master ka rreth 15 prej kĂ«tyre replikave.
Si në skemën e parë ashtu edhe në atë të dytë, në rast të pamundësisë së një DC, aplikacioni mund të marrë të dhëna nga i dyti.
Vlen të përmendet se në Tarantool replikimi është mjaft fleksibël dhe konfigurohet në runtime. Në sistemet e tjera kanë ndodhur vështirësi. Për shembull, me ndryshimin e parametrave max_wal_senders dhe max_replication_slots në PostgreSQL, kërkohet rinisja e masterit, e cila në disa raste mund të shkaktojë ndërprerje të lidhjeve midis aplikacionit dhe DBMS.
KĂ«rkoni dhe do ta gjeni!
Pse nuk e bëmë "si njerëz normal", por zgjodhëm një mënyrë jotipike? Duke parë se çfarë e konsiderojmë normal. Shumë thjesht bëjnë një grup nga Mongo dhe e shpërndajnë atë në tre DC të shpërndarë gjeografikisht.
Në atë kohë ne kishim tashmë dy projekte në Redis. E para ishte cache, ndërsa e dyta përbënte një depozitë të përhershme për të dhënat jo aq kritike. Kjo e fundit na dha disa vështirësi, pjesërisht për fajin tonë. Ndonjëherë një sasi e konsiderueshme të dhënash ruheshin në çelës, dhe nga koha në kohë, faqja e internetit ndiheshin keq. Ky sistem e përdorëm në variantin master-slave. Dhe kishte shumë raste kur ndodhte diçka me masterin dhe replikimi thyhej.
Pra ndodhi që Redis ishte i mirë për detyrat stateless dhe jo për ato stateful. Në parim, ai e zgjidhi shumicën e problemeve, por vetëm nëse ishin zgjidhje key-value me disa indekse. Megjithatë, në atë kohë, Redis kishte probleme të mëdha me persistencën dhe replikimin. Po ashtu, pati ankesat për performancën.
Menduam për MySQL dhe PostgreSQL. Por e para nuk ishte e përshtatshme për ne, ndërsa e dyta është një produkt mjaft i avancuar dhe do të ishte e papërshtatshme të ndërtosh shërbime të thjeshta mbi të.
Provuan RIAK, Cassandra, madje dhe një bazë të dhënash grafike. Të gjitha këto janë zgjidhje të mjaftueshme për niƥa, që nuk përputheshin për rolin e një instrumenti universale për krijimin e shërbimeve.
Në fund, u ndalëm te Tarantool.
Ne e kontaktuam atë kur ishte në versionin 1.6. Na interesoi simbioza e key-value dhe funksionalitetit të një baze të dhënash relacional. Ka indekse të dyta, transaksione dhe hapësira, që janë si tabela, por jo të thjeshta, mund të ruajmë në to një numër të ndryshëm kolonash. Por karakteristika killer e Tarantool ishte indeksi i dytë në kombinim me key-value dhe transaksionalitetin.
Po ashtu, luajti një rol komuniteti të përgjegjshëm në gjuhën ruse, të gatshëm për të ndihmuar në chat. Ne e shfrytëzuam këtë aktivisht dhe jetuam në chat. Dhe nuk duhet të harrojmë për një persistencë të mirë pa gabime të dukshme dhe probleme. Në historinë tonë me Tarantool, patëm shumë dhimbje dhe komplikacionesh me replikimin, por nuk humbëm asnjëherë të dhëna për shkakun e tij!
Zbatimi filloi vështirë
NĂ« atĂ« kohĂ«, staku ynĂ« kryesor i zhvillimit ishte .NET, pĂ«r tĂ« cilin nuk kishte njĂ« lidhĂ«s pĂ«r Tarantool. Ne filluam menjĂ«herĂ« tĂ« bĂ«nim diçka nĂ« Go. Po ashtu, Lua doli tĂ« ishte mjaft e mirĂ«. Problemi kryesor nĂ« atĂ« kohĂ« ishte me debugin: nĂ« .NET gjithçka ishte e shkĂ«lqyer, ndĂ«rsa pas kĂ«saj tĂ« kthehesh nĂ« botĂ«n e Lua embeded, kur nuk ke asgjĂ« tjetĂ«r veç logjeve, ishte e vĂ«shtirĂ«. Po ashtu, replikimi, ndonjĂ«herĂ«, u shemb papritur, dhe na duhej tĂ« kuptonim strukturĂ«n e motorit Tarantool. Chat ndihmoi nĂ« kĂ«tĂ«, nĂ« njĂ« masĂ« mĂ« tĂ« vogĂ«l â dokumentacioni, ndonjĂ«herĂ« shihnim kodin. NĂ« atĂ« kohĂ« dokumentacioni nuk ishte shumĂ« i mirĂ«.
Kështu, për disa muaj arritëm të grumbullojmë përvojë dhe të arrijmë rezultate të kënaqshme në punën me Tarantool. Kemi organizuar në git praktikat standarte që ndihmuan në krijimin e mikroshërbimeve të reja. Për shembull, kur na dilte puna: të krijonim një mikroshërbim tjetër, zhvilluesi shikonte kodin burimor të zgjidhjes standarde në depo, dhe krijimi i një të ri zgjaste maksimalisht një javë.
Ishin kohë të veçanta. Në mënyrë të zakonshme, atëherë mund të afroheshe te admini në tryezën ngjitur dhe të kërkoje: "Më jap një virtuale". Pas rreth tridhjetë minutash, makina ishte tashmë te ti. Ti vetë lidhe, installove gjithçka, dhe të drejtonin trafik për të.
Sot nuk funksionon kështu më: duhet të vendosësh monitorimin e shërbimit, regjistrimin, të mbulosh funksionalitetin me prova, të porositesh një virtuale ose një instalim në Kubernetes, etj. Në përgjithësi, kjo do të jetë më mirë, megjithatë më e gjatë dhe më e mundimshme.
Ndaje dhe sundo. Si është puna me Lua?
Ishte një dilemë serioze: disa ekipe nuk arrinin të implementonin me besueshmëri ndryshimet në shërbim me një sasi të madhe logjike në Lua. Shpeshherë kjo shoqërohej me pasiguri të shërbimit.
Do thotë që zhvilluesit përgatisin një ndryshim. Tarantool fillon të kryejë migrimin, ndërsa replika ende ka kodin e vjetër; atje mbërrin përmes replikimit ndonjë DDL, diçka tjetër, dhe kodi thjesht shembet, sepse nuk është marrë parasysh. Si rezultat, procedura e përditësimit për administratorët ishte shkruar në një fletë A4: ndalo replikimin, përditësoje këtë, aktivizo replikimin, fik aty, përditëso atje. Fushatë!
Si rezultat, tani më shpesh përpiqemi të mos bëjmë asgjë në Lua. Thjesht me ndihmën e iproto (protokolli i binarëve për ndërveprimin me serverin), dhe kjo është gjithçka. Ndoshta, kjo është një mangësi e njohurive të zhvilluesve, por nga kjo pikëpamje sistemi është i komplikuar.
Ne nuk e 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. Ne tashmë e kuptojmë si të kombinojmë, për të mos pasur më vonë probleme me migrimin.
Ku ndodhet tani Tarantool?
Tarantool përdoret në shërbimin e llogaritjes së çmimit final të artikujve duke marrë parasysh kuponat e zbritjeve, i njohur si "Promotizer". Siç e përmenda më parë, tani ai po tërhiqet nga tregu: një shërbim i ri katalogu me çmime të parakalkuluara e zëvendëson, por gjashtë muaj më parë të gjitha llogaritjet bëheshin në "Promotizer". Njëherë, gjysma e logjikës së tij ishte shkruar në Lua. Dy vjet më parë, shërbimi u bë një depo, dhe logjikën e rinovuan në Go, sepse mekanika e punës me zbritjet ndryshoi pak dhe shërbimit i mungonte performanca.
Një nga shërbimet më kritike është profili i përdoruesit. Pra, të gjithë përdoruesit e Wildberries ruhen në Tarantool, dhe janë rreth 50 milion. Një sistem i ndarë sipas ID përdoruesi, i shpërndarë në disa qendra të të dhënave me lidhje në shërbimet Go.
Dikur, lideri në RPS ishte "Promotizer", duke arritur deri në 6,000 kërkesa. Në një moment, kishim 50-60 ekzemplarë. Tani, lideri sipas RPS është profili i përdoruesve, duke arritur rreth 12,000. Në këtë shërbim përdoret ndarje e personalizuar me ndarje sipas intervaleve të ID përdoruesve. Shërbimi shërben mbi 20 makineri, por kjo është shumë, planifikojmë të zvogëlojmë burimet e dedikuara, sepse i mjaftojnë kapacitetet e 4-5 makinerive.
Shërbimi i sesioneve është shërbimi ynë i parë në vshard dhe Cartridge. Konfigurimi i vshard dhe përditësimi i Cartridge kërkuan nga ne disa burime pune, por në fund gjithçka doli siç duhej.
Shërbimi për shfaqjen e bannerave të ndryshme në faqen e internetit dhe në aplikacionin në celular ishte një nga të parët që u publikuan menjëherë në Tarantool. Ky shërbim është interesant sepse është rreth 6-7 vjeç, ai është akoma në funksion dhe nuk është rinisur asnjëherë. U përdor replikimi master-master. Asnjëherë nuk ka dështuar.
Ka një shembull të përdorimit të Tarantool për funksionalitetin e regjistrave të shpejtë në sistemin e magazinimit, për të kontrolluar shpejt informacionin në disa raste. Provuan të përdorin Redis për këtë qëllim, por të dhënat në memorie zinin më shumë hapësirë sesa në Tarantool.
Shërbimet e listës së pritjes, abonimeve të klientëve, storieve të njohura tani dhe artikujve të vonuar gjithashtu punojnë me Tarantool. Ky shërbim zë rreth 120 GB në memorie. Ky është shërbimi më voluminoz nga ato të përmendura më parë.
PĂ«rfundim
FalĂ« indeksit tĂ« dytĂ« nĂ« kombinim me key-value dhe transaksionet, Tarantool Ă«shtĂ« jashtĂ«zakonisht e pĂ«rshtatshme pĂ«r arkitekturat e bazuara nĂ« mikrosĐ”ŃĐČice. MegjithatĂ«, ne u pĂ«rballĂ«m me vĂ«shtirĂ«si kur implementuam ndryshime nĂ« shĂ«rbimet me shumĂ« logjikĂ« nĂ« Lua â shĂ«rbimet shpesh ndalonin sĂ« funksionuari. Ne nuk arrijmĂ« ta zgjidhim kĂ«tĂ«, dhe me kalimin e kohĂ«s kemi arritur nĂ« kombinime tĂ« ndryshme tĂ« Lua dhe Go: e dimĂ« se ku duhet tĂ« pĂ«rdorim njĂ« gjuhĂ« dhe ku tjetra.
ĂfarĂ« tjetĂ«r tĂ« lexoni mbi kĂ«tĂ« temĂ«
- Krijojmë nga e para një aplikacion me ngarkesë të lartë në Tarantool
- Zgjedhje e besueshme lideri në Tarantool Cartridge
- Kanal Telegram Tarantool me lajme për produktin
- Diskuto Tarantool në bisedën e komunitetit
Burimi: habr.com
