Të gjithë i duam historitë. Na pëlqen të ulemi rreth zjarrit dhe të flasim për fitoret, betejat ose thjesht përvojën tonë të punës.
Sot është një ditë e tillë. Dhe edhe nëse nuk jeni pranë zjarrit tani, ne kemi një histori për ju. Historia se si filluam të punonim me ruajtjen në Tarantool.
Njëherë e një kohë, kompania jonë kishte nja dy “monolite” dhe një “tavan” për të gjithë, tek të cilët këto monolite po afroheshin ngadalë por me siguri, duke kufizuar fluturimin e kompanisë sonë, zhvillimin tonë. Dhe kishte një mirëkuptim të qartë: një ditë do ta godasim fort këtë tavan.
Tani është ideologjia mbizotëruese e ndarjes së gjithçkaje dhe të gjithëve, nga pajisjet te logjika e biznesit. Si rezultat, ne, për shembull, kemi dy DC që janë praktikisht të pavarura në nivel rrjeti. Dhe pastaj gjithçka ishte krejtësisht ndryshe.
Sot ka shumë mjete dhe mjete për të bërë ndryshime në formën e CI/CD, K8S, etj. Në kohën “monolitike” nuk na duheshin kaq shumë fjalë të huaja. Mjaftonte thjesht korrigjimi i "ruajtjes" në bazën e të dhënave.
Por koha eci përpara dhe së bashku me të edhe numri i kërkesave shkoi përpara, ndonjëherë duke gjuajtur RPS përtej aftësive tona. Me hyrjen e vendeve të CIS në treg, ngarkesa në procesorin e bazës së të dhënave të monolitit të parë nuk ra nën 90%, dhe RPS mbeti në nivelin e 2400. Dhe këta nuk ishin thjesht përzgjedhës të vegjël, por pyetje të rënda me një një grup kontrollesh dhe JOIN që mund të ekzekutohen pothuajse për gjysmën e të dhënave në sfondin e IO të mëdha.
Kur shitjet e plota të së Premtes së Zezë filluan të shfaqen në skenë - dhe Wildberries ishte një nga të parët që i mbajti ato në Rusi - situata u bë plotësisht e trishtuar. Në fund të fundit, ngarkesa në ditë të tilla rritet tre herë.
Oh, këto “kohë monolite”! Unë jam i sigurt se ju keni përjetuar diçka të ngjashme, dhe ju ende nuk mund ta kuptoni se si mund të ndodhë me ju.
Çfarë mund të bëni - moda është e natyrshme në teknologji. Rreth 5 vjet më parë, na u desh të rimendonim një nga këto modalitete në formën e një faqeje ekzistuese në serverin .NET dhe MS SQL, i cili ruante me kujdes të gjithë logjikën e vetë faqes. E mbajta me aq kujdes sa sharrimi i një monolit të tillë doli të ishte një kënaqësi e gjatë dhe aspak e lehtë.
Një digresion i vogël.
Në ngjarje të ndryshme them: "nëse nuk keni parë një monolit, atëherë nuk jeni rritur!" Më intereson mendimi juaj për këtë çështje, ju lutemi shkruani në komente.
Një Tingull Bubullimash
Të kthehemi te “zjarri ynë”. Për të shpërndarë ngarkesën e funksionalitetit "monolitik", vendosëm ta ndajmë sistemin në mikroshërbime të bazuara në teknologjitë me burim të hapur. Sepse, të paktën, ato janë më të lira në shkallë. Dhe ne kishim 100% të kuptuar se do të duhej të shkallëzonim (dhe shumë). Në fund të fundit, tashmë në atë kohë ishte e mundur të hynte në tregjet e vendeve fqinje, dhe numri i regjistrimeve, si dhe numri i porosive, filloi të rritet edhe më fuqishëm.
Pasi kemi analizuar kandidatët e parë për largim nga monoliti në mikroshërbime, kuptuam se 80% e shkrimeve në to vjen nga sistemet back office, dhe leximi nga zyra e përparme. Para së gjithash, kjo kishte të bënte me disa nënsisteme të rëndësishme për ne - të dhënat e përdoruesit dhe një sistem për llogaritjen e kostos përfundimtare të mallrave bazuar në informacionin në lidhje me zbritjet dhe kuponët shtesë të klientëve.
I futur. Tani është e frikshme të imagjinohet, por përveç nënsistemeve të lartpërmendura, nga monoliti ynë u hoqën edhe katalogët e produkteve, një karrocë blerjesh përdoruesish, një sistem kërkimi produktesh, një sistem filtrimi për katalogët e produkteve dhe lloje të ndryshme sistemesh rekomandimi. Për funksionimin e secilit prej tyre, ekzistojnë klasa të veçanta të sistemeve të përshtatura ngushtë, por një herë e një kohë ata të gjithë jetonin në një "shtëpi".
Ne planifikuam menjëherë transferimin e të dhënave për klientët tanë në sistemin e copëtuar. Heqja e funksionalitetit për llogaritjen e kostos përfundimtare të mallrave kërkonte shkallëzim të mirë për lexim, sepse krijonte ngarkesën më të madhe RPS dhe ishte më e vështira për t'u zbatuar për bazën e të dhënave (shumë të dhëna përfshihen në procesin e llogaritjes).
Si rezultat, ne dolëm me një skemë që përshtatet mirë me Tarantool.
Në atë kohë, për funksionimin e mikroshërbimeve, u zgjodhën skema për të punuar me disa qendra të dhënash në makina virtuale dhe harduerike. Siç tregohet në figura, opsionet e riprodhimit të Tarantool u aplikuan në të dy modalitetet master-master dhe master-slave.
Arkitekturë. Opsioni 1. Shërbimi i përdoruesit
Për momentin, ka 24 copëza, secila 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ë aksesojnë kopjet e bazës së të dhënave. Aplikacionet punojnë me Tarantool përmes bibliotekës sonë të personalizuar, e cila zbaton ndërfaqen e drejtuesit të Tarantool Go. Ajo i sheh të gjitha kopjet dhe mund të punojë me mjeshtrin për të lexuar dhe shkruar. Në thelb, ai zbaton modelin e grupit të kopjeve, i cili shton logjikën për zgjedhjen e kopjeve, kryerjen e riprovave, një ndërprerës dhe një kufi shpejtësie.
Në këtë rast, është e mundur të konfiguroni politikën e përzgjedhjes së kopjeve në kontekstin e copëzave. Për shembull, roundrobin.
Arkitekturë. Opsioni 2. Shërbimi për llogaritjen e kostos përfundimtare të mallrave
Pak muaj më parë, shumica e kërkesave për llogaritjen e kostos përfundimtare të mallrave shkuan në një shërbim të ri, i cili në parim funksionon pa baza të dhënash, por pak kohë më parë gjithçka u përpunua 100% nga një shërbim me Tarantool nën kapuç.
Baza e të dhënave të shërbimit përbëhet nga 4 master në të cilët sinkronizuesi mbledh të dhëna dhe secila prej këtyre masterave të riprodhimit shpërndan të dhëna në kopje vetëm për lexim. Çdo master ka afërsisht 15 kopje të tilla.
Ose në skemën e parë ose të dytë, nëse një DC nuk është e disponueshme, aplikacioni mund të marrë të dhëna në të dytën.
Vlen të përmendet se përsëritja në Tarantool është mjaft fleksibël dhe mund të konfigurohet në kohën e ekzekutimit. Në sisteme të tjera, u shfaqën vështirësi. Për shembull, ndryshimi i parametrave max_wal_senders dhe max_replication_slots në PostgreSQL kërkon një rinisje të magjistarit, i cili në disa raste mund të çojë në shkëputjen e lidhjeve midis aplikacionit dhe DBMS.
Kërkoni dhe do të gjeni!
Pse nuk e bëmë "si njerëzit normalë", por zgjodhëm një mënyrë atipike? Varet nga ajo që konsiderohet normale. Shumë njerëz në përgjithësi krijojnë një grup nga Mongo dhe e shpërndajnë atë në tre DC të gjeo-shpërndara.
Në atë kohë kishim tashmë dy projekte Redis. E para ishte një cache, dhe e dyta ishte një ruajtje e vazhdueshme për të dhëna jo shumë kritike. Ishte mjaft e vështirë me të, pjesërisht për fajin tonë. Ndonjëherë vëllime mjaft të mëdha ishin në çelës, dhe herë pas here faqja nuk ishte e mirë. Ne e përdorëm këtë sistem në versionin master-slave. Dhe kishte shumë raste kur diçka i ndodhi masterit dhe replikimi u prish.
Domethënë, Redis është i mirë për detyra pa shtetësi, jo për ato shtetërore. Në parim, ai lejonte zgjidhjen e shumicës së problemeve, por vetëm nëse ato ishin zgjidhje me vlerë kyçe me një palë indeksesh. Por Redis në atë kohë ishte mjaft i trishtuar me këmbënguljen dhe përsëritjen. Përveç kësaj, ka pasur ankesa për performancën.
Ne menduam për MySQL dhe PostgreSQL. Por e para disi nuk na kapi, dhe e dyta është një produkt mjaft i sofistikuar në vetvete dhe do të ishte e papërshtatshme të ndërtonim shërbime të thjeshta mbi të.
Ne provuam RIAK, Cassandra, madje edhe një bazë të dhënash grafike. Këto janë të gjitha zgjidhje mjaft të veçanta që nuk ishin të përshtatshme për rolin e një mjeti të përgjithshëm universal për krijimin e shërbimeve.
Më në fund u vendosëm në Tarantool.
Ne iu drejtuam asaj kur ishte në versionin 1.6. Ne ishim të interesuar për të nga simbioza e vlerës-kyç dhe funksionaliteti i një baze të dhënash relacionale. Ka indekse dytësore, transaksione dhe hapësira, këto janë si tabela, por jo të thjeshta, mund të ruani numra të ndryshëm kolonash në to. Por tipari vrasës i Tarantool ishin indekset dytësore të kombinuara me vlerën kyçe dhe transaksionalitetin.
Një rol luajti edhe komuniteti i përgjegjshëm rusisht-folës, i gatshëm për të ndihmuar në bisedë. Ne e përdorëm këtë në mënyrë aktive dhe jetojmë drejtpërdrejt në bisedë. Dhe mos harroni për këmbënguljen e mirë pa gabime dhe gabime të dukshme. Nëse shikoni historinë tonë me Tarantool, kemi pasur shumë dhimbje dhe dështime me replikimin, por nuk kemi humbur kurrë të dhëna për fajin e tij!
Zbatimi filloi me një fillim të vështirë
Në atë kohë, grupi ynë kryesor i zhvillimit ishte .NET, në të cilin nuk kishte asnjë lidhës për Tarantool. Filluam menjëherë të bënim diçka në Go. Ka funksionuar mirë edhe me Luan. Problemi kryesor në atë kohë ishte me korrigjimin: në .NET gjithçka është e shkëlqyeshme me këtë, por pas kësaj ishte e vështirë të zhytesh në botën e Lua-s së integruar, kur nuk ke korrigjim përveç regjistrave. Për më tepër, për disa arsye përsëritja u shpërbë periodikisht, kështu që më duhej të gërmoja në strukturën e motorit Tarantool. Biseda ndihmoi me këtë, dhe në një masë më të vogël, dokumentacionin; ndonjëherë ne shikonim kodin. Në atë kohë, dokumentacioni ishte kështu.
Kështu që, gjatë disa muajve, arrita të bëja mendjen time dhe të marr rezultate të mira nga puna me Tarantool. Ne përpiluam zhvillimet e referencës në git që ndihmuan në formimin e mikroshërbimeve të reja. Për shembull, kur u shfaq një detyrë: për të krijuar një tjetër mikroshërbim, zhvilluesi shikoi kodin burimor të zgjidhjes së referencës në depo, dhe u desh jo më shumë se një javë për të krijuar një të re.
Këto ishin kohë të veçanta. Në mënyrë konvencionale, atëherë mund të shkoni te administratori në tryezën tjetër dhe të pyesni: "Më jep një makinë virtuale". Rreth tridhjetë minuta më vonë makina ishte tashmë me ju. Ju u lidhët vetë, instaluat gjithçka dhe trafiku u dërgua tek ju.
Sot kjo nuk do të funksionojë më: duhet të shtoni monitorimin dhe regjistrimin në shërbim, të mbuloni funksionalitetin me teste, të porosisni një makinë virtuale ose dërgesë në Kuber, etj. Në përgjithësi, do të jetë më mirë në këtë mënyrë, megjithëse do të zgjasë më shumë dhe do të jetë më e mundimshme.
Ndani dhe sundoni. Si është puna me Luan?
Kishte një dilemë serioze: disa skuadra nuk ishin në gjendje të bënin ndryshime të besueshme në një shërbim me shumë logjikë në Lua. Kjo shpesh shoqërohej me mosfunksionimin e shërbimit.
Kjo do të thotë, zhvilluesit po përgatisin një lloj ndryshimi. Tarantool fillon të bëjë migrimin, por kopja është ende me kodin e vjetër; Disa DDL ose diçka tjetër mbërrin atje nëpërmjet replikimit, dhe kodi thjesht shpërbëhet sepse nuk merret parasysh. Si rezultat, procedura e përditësimit për administratorët u vendos në fletën A4: ndaloni përsëritjen, përditësoni këtë, aktivizoni përsëritjen, fikni këtu, përditësoni atje. Makth!
Si rrjedhojë, tani më shpesh përpiqemi të mos bëjmë asgjë në Lua. Thjesht përdorni iproto (një protokoll binar për të bashkëvepruar me serverin), dhe kjo është ajo. Ndoshta kjo është një mungesë njohurish midis zhvilluesve, por nga ky këndvështrim sistemi është kompleks.
Ne nuk e ndjekim gjithmonë verbërisht këtë skenar. Sot nuk kemi bardh e zi: ose gjithçka është në Lua, ose gjithçka është në Go. Ne tashmë e kuptojmë se si mund t'i kombinojmë ato në mënyrë që të mos përfundojmë me probleme migrimi më vonë.
Ku është Tarantool tani?
Tarantool përdoret në shërbimin për llogaritjen e kostos përfundimtare të mallrave duke marrë parasysh kuponët e zbritjes, i njohur edhe si "Promoter". Siç thashë edhe më herët, ai tani del në pension: po zëvendësohet nga një shërbim i ri katalogu me çmime të parallogaritura, por gjashtë muaj më parë të gjitha llogaritjet janë bërë në Promotizer. Më parë, gjysma e logjikës së saj shkruhej në Lua. Dy vite më parë, shërbimi u kthye në një magazinë dhe logjika u rishkrua në Go, sepse mekanika e zbritjeve kishte ndryshuar pak dhe shërbimi kishte mungesë të performancës.
Një nga shërbimet më kritike është profili i përdoruesit. Kjo do të thotë, të gjithë përdoruesit e Wildberries ruhen në Tarantool dhe ka rreth 50 milionë të tillë.Një sistem i ndarë nga ID-ja e përdoruesit, i shpërndarë në disa DC të lidhura me shërbimet Go.
Sipas RPS, Promoter ka qenë dikur lider, duke arritur në 6 mijë kërkesa. Në një moment kishim 50-60 kopje. Tani lider në RPS janë profilet e përdoruesve, rreth 12 mijë. Ky shërbim përdor ndarjen e personalizuar, të ndarë sipas diapazoneve të ID-ve të përdoruesve. Shërbimi u shërben më shumë se 20 makinerive, por kjo është shumë, ne planifikojmë të reduktojmë burimet e alokuara, sepse kapaciteti prej 4-5 makinerish është i mjaftueshëm për të.
Shërbimi i sesionit është shërbimi ynë i parë në vshard dhe Cartridge. Vendosja e vshard dhe përditësimi i fishekut kërkonte disa përpjekje nga ne, por në fund gjithçka funksionoi.
Shërbimi për shfaqjen e banderolave të ndryshëm në uebsajt dhe në aplikacionin celular ishte një nga të parët që u lëshua drejtpërdrejt në Tarantool. Ky shërbim shquhet për faktin se është 6-7 vjeç, është ende në funksion dhe nuk është rindezur asnjëherë. Është përdorur replikimi master-master. Asgjë nuk u prish kurrë.
Ekziston një shembull i përdorimit të Tarantool për funksione referimi të shpejtë në një sistem magazine për të kontrolluar shpejt informacionin në disa raste. Ne u përpoqëm të përdornim Redis për këtë, por të dhënat në memorie zinin më shumë hapësirë sesa Tarantool.
Shërbimet e listës së pritjes, abonimet e klientëve, tregimet aktualisht në modë dhe mallrat e shtyra funksionojnë gjithashtu me Tarantool. Shërbimi i fundit në memorie merr rreth 120 GB. Ky është shërbimi më gjithëpërfshirës nga sa më sipër.
Përfundim
Falë indekseve dytësore të kombinuara me vlerën kyçe dhe transaksionalitetin, Tarantool është i përshtatshëm për arkitekturat e bazuara në mikroshërbime. Megjithatë, ne hasëm vështirësi gjatë paraqitjes së ndryshimeve në shërbime me shumë logjikë në Lua - shërbimet shpesh nuk funksiononin. Ne nuk ishim në gjendje ta kapërcenim këtë dhe me kalimin e kohës arritëm në kombinime të ndryshme të Lua dhe Go: ne dimë ku të përdorim një gjuhë dhe ku të përdorim një tjetër.
Çfarë tjetër për të lexuar në këtë temë
- Krijimi i një aplikacioni me ngarkesë të lartë nga e para duke përdorur Tarantool
- Zgjedhja e liderit të besuar në Tarantool Cartridge
- Kanali Telegram Tarantool me lajme rreth produktit
- Diskutoni Tarantool në bisedën e komunitetit
Burimi: www.habr.com