{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Kuidas l\u00f5petada muretsemine ja alustada elu ilma monoliidita","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nMe k\u00f5ik armastame lugusid. Meile meeldib istuda l\u00f5kke \u00e4\u00e4res ja r\u00e4\u00e4kida oma m\u00f6\u00f6dunud v\u00f5itudest, lahingutest v\u00f5i lihtsalt oma t\u00f6\u00f6kogemusest.<\/p>\n

T\u00e4na on just selline p\u00e4ev. Ja kuigi te ei istu praegu l\u00f5kke \u00e4\u00e4res, on meil teile lugu. Lugu sellest, kuidas me hakkasime t\u00f6\u00f6tama Tarantooli salvestusega.<\/p>\n

Kord ammu oli meie firmas paar \u00abmonoliiti\u00bb ja \u00fcks k\u00f5ikidele \u00ablagi\u00bb, mille poole need monoliidid aeglaselt, kuid kindlalt liikusid, piirates meie ettev\u00f5tte edasiviimist. Meil oli selge arusaam: \u00fchel p\u00e4eval saame me sellesse lage tugevalt takistuseks.
\n<\/a><\/noindex>
\nPraegu valitseb meil ideoloogia k\u00f5ike ja k\u00f5iki jagada, alustades seadmetest ja l\u00f5petades \u00e4riloogikaga. Selle tulemusena on meil n\u00e4iteks kaks andmekeskust, mis on praktiliselt s\u00f5ltumatud v\u00f5rgu tasandil. Kuid tol ajal oli k\u00f5ik hoopis teistmoodi.<\/p>\n

T\u00e4nap\u00e4eval on muudatuste tegemiseks palju vahendeid ja t\u00f6\u00f6riistu, nagu CI\/CD, K8S jne. \u00abMonoliitsetel\u00bb aegadel ei olnud meil vaja nii palju ilusaid s\u00f5nu. Piisas, kui lihtsalt parandada \u00absalvestust\u00bb andmebaasis.<\/p>\n

Aeg m\u00f6\u00f6dus ning p\u00e4ringute arv kasvas koos sellega, tulistades RPS m\u00f5nikord k\u00f5rgemale kui meie v\u00f5imalused. Kui me sisenesime SR\u00dc riikide turule, ei langenud andmebaasi esimese monoliidi protsessorikoormus kunagi alla 90 %, samas kui RPS p\u00fcsis 2400 tasemel. Ja need ei olnud lihtsalt v\u00e4iksed p\u00e4ringud, vaid hiiglaslikud p\u00e4ringud, millel oli palju kontrollimisi ja JOIN-e, mis jooksid l\u00e4bi peaaegu poole andmetest suure IO taustal.<\/p>\n

Kui t\u00e4iecene hakkasid ilmnema t\u00f5elised allahindlused \u00abMustal reedel\u00bb, \u2014 ja Wildberries alustas nende korraldamist \u00fchtesid esimesi Venemaal, \u2014 siis olukord muutus t\u00f5eliselt kurvaks. Sellistel p\u00e4evadel t\u00f5useb koormus kolm korda.
\nOeh, need \u00abmonoliitsed ajad\u00bb! Olen kindel, et olete sarnast kogenud ja siiani ei saa aru, kuidas see teie jaoks juhtuda sai.<\/p>\n

Mida siin teha \u2014 mood on iseloomulik ka tehnoloogiatele. Veel 5 aastat tagasi pidime m\u00f5tlema \u00fcmber \u00fche sellise moe \u2014 .NET-is ja MS SQL-serveris eksisteeriva veebisaidi, mis hoidis enda sees kogu saidi t\u00f6\u00f6loogikat. Hoidis nii hoolikalt, et sellise monoliidi lahtiv\u00f5tmine osutus pika ja v\u00e4ga keerulise naudinguga.
\nV\u00e4ike k\u00f5rvalep\u00f5ige. <\/p>\n

Erinevatel \u00fcritustel \u00fctlen: \"kui te ei ole monoliiti l\u00f5hkemiseks saanud, siis te ei ole kasvanud!\" Huvitav on teie arvamus selle kohta, palun kirjutage see kommentaaridesse.<\/p>\n

Ja m\u00fcristades k\u00f5las \u00e4ike<\/h3>\n

\nNaaseme meie \"m\u00e4ge\". Koormuse jaotamiseks \"monoliitse\" funktsionaalsuse vahel otsustasime s\u00fcsteemi jagada mikroteenusteks, mis p\u00f5hinevad avatud l\u00e4htekoodiga tehnoloogiatel. Sest v\u00e4hemalt on nende skaleerimine odavam. Ja arusaamine, et tuleb skaleerida (ja mitte v\u00e4he) oli meil 100% selge. Sest juba sel hetkel oli meil \u00f5nnestunud siseneda naaberriikide turgudele ja registreerimiste arv, nagu ka tellimuste arv, hakkas veelgi kiiremini kasvama.<\/p>\n

Anal\u00fc\u00fcsides esimesi kandidaate, kes lahkusid monoliidist mikroteenustesse, m\u00f5istsime, et 80% andmetest nende kohta p\u00e4rineb 99% ulatuses back office s\u00fcsteemidest, samas kui lugemine toimub esirinnast. Eriti puudutas see kahe olulise alams\u00fcsteemi \u2014 kasutajate andmete s\u00fcsteemi ja kaupade l\u00f5pphinnastamise s\u00fcsteemi, mis p\u00f5hineb lisakliendi allahindlustel ja kupongidel \u2014 funktsionaalsust.<\/p>\n

N\u00fc\u00fcd, kui me tagasi vaatame, on raske ette kujutada, et lisaks \u00fclalmainitud alams\u00fcsteemidele viidi meie monoliidist v\u00e4lja ka tootekataloogid, kasutajakorv, tooteotsingu s\u00fcsteem, tootekataloogide filtreerimiss\u00fcsteem ja erinevad soovituslikud s\u00fcsteemid. Iga\u00fche jaoks on olemas eraldi kitsa fookusega s\u00fcsteemide klassid, kuid kunagi elasid nad k\u00f5ik \u00fches \"majas\". <\/p>\n

Kliendiandmete v\u00e4ljav\u00f5tmine plaaniti kohe sharded s\u00fcsteemi peal. Kuid kaupade l\u00f5pphinna arvutamise funktsionaalsusele esitatud n\u00f5uded n\u00f5udsid head skaleeritavust lugemisel, kuna see genereeris suurima koormuse RPS-i p\u00f5hjal ja oli baasiga teostamiseks k\u00f5ige keerulisem (protsessis kaasatud v\u00e4ga palju andmeid). <\/p>\n

Selle tulemusena tekkis meil skeem, mis sobib h\u00e4sti Tarantooliga.<\/p>\n

Sel ajal valiti mikroteenuste t\u00f6\u00f6ks mitme andmekeskuse s\u00fcsteemid virtuaalsetel ja riistvaralistel masinatel. Nagu on n\u00e4idatud joonistel, kasutati Tarantooli replikatsiooni variante nii master-master kui ka master-slave re\u017eiimis. <\/p>\n

\"Kuidas
\nArhitektuur. Variant 1. Kasutajate teenus<\/i><\/p>\n

Praeguseks on olemas 24 shard'i, milles igas on 2 instants (\u00fcks igas andmekeskuses), k\u00f5ik master-master re\u017eiimis.<\/p>\n

Andmete kohal on rakendused, mis p\u00f6\u00f6rduvad andmebaasi koopiate poole. Rakendused t\u00f6\u00f6tavad Tarantooliga meie kohandatud raamatukogu kaudu, mis rakendab Go-draiveri Tarantooli liidest. See n\u00e4eb k\u00f5iki koopiaid ja suudab t\u00f6\u00f6tada peamise andmebaasiga lugemise ja kirjutamise osas. Sisuliselt rakendab see koopiate komplekti mudelit, millele on lisatud koopiate valiku loogika, uuesti proovimise teostamine, k\u00fcsitluskatkestaja ja m\u00e4\u00e4ratud limiit.<\/p>\n

Samuti on v\u00f5imalik konfigureerida koopiate valimise poliiikat shardi l\u00f5ikes. N\u00e4iteks ringh\u00e4\u00e4letamine.<\/p>\n

\"Kuidas
\nArhitektuur. Variant 2. Teenus toote l\u00f5pphinnangu arvutamiseks<\/i><\/p>\n

M\u00f5ned kuud tagasi suunati enamik l\u00f5pphinnangu arvutamise p\u00e4ringutest uuele teenusele, mis p\u00f5him\u00f5tteliselt t\u00f6\u00f6tab ilma andmebaasideta, kuid m\u00f5ni aeg tagasi t\u00f6\u00f6tas 100% teenusest Tarantooli peal.<\/p>\n

Teenuse andmebaas koosneb neljast peamise andmebaasi serverist, kuhu s\u00fcnkronisaator kogub andmeid, ja iga\u00fchel neist masteritest jagatakse koopiad ainult lugemiseks etten\u00e4htud koopiatele. Igal peamisel andmebaasi serveril on umbes 15 sellist koopiat.<\/p>\n

Nii esimeses kui teises skeemis, kui \u00fcks andmeressurss ei ole saadaval, saavad rakendused andmeid teiselt.<\/p>\n

Tasub m\u00e4rkida, et Tarantooli koopiate replikatsioon on suhteliselt paindlik ja konfigureeritav reaalajas. Teistes s\u00fcsteemides on tekkinud probleeme. N\u00e4iteks PostgreSQL-is n\u00f5uab max_wal_sendersi ja max_replication_slots parameetrite muutmine peamise andmebaasi serveri taask\u00e4ivitamist, mis m\u00f5nel juhul v\u00f5ib p\u00f5hjustada \u00fchenduste katkemist rakenduse ja andmebaasi vahel.<\/p>\n

Otsige ja leiate!<\/h3>\n

\nMiks me ei teinud \u00abnagu tavalised inimesed\u00bb, vaid valisime ebatavalise meetodi? S\u00f5ltub sellest, mida normaalseks pidada. Paljud teevad hoopis Mongo klustere ja hajutavad selle kolme geograafiliselt jaotatud andmeressursi vahel.<\/p>\n

Sel ajal olid meil juba kaks projekti Redisil. Esiteks \u2014 vahem\u00e4lu ja teiseks oli see p\u00fcsiv salvestus mitte v\u00e4ga kriitilistele andmetele. Sellega oli \u00fcsna keeruline, osaliselt meie enda s\u00fc\u00fcl. M\u00f5nikord oli m\u00e4rkimisv\u00e4\u00e4rne kogus andmeid v\u00f5tmes, ja aeg-ajalt oli saidil halvad hetked. Kasutasime seda s\u00fcsteemi peamine-moodul variandina. Ja oli palju juhtumeid, kui midagi juhtus p\u00f5hiserveriga ja replikatsioon katkestas. <\/p>\n

Redis on hea stateless-\u00fclesannete jaoks, mitte stateful. \u00dcldiselt aitas see enamikke probleeme lahendada, kuid vaid juhul, kui need olid key-value lahendused koos paari indeksiga. Kuid Redis'i varasematel aegadel oli p\u00fcsivuse ja replikatsiooni osas olukord \u00fcsna nukker. Lisaks olid ka kaebused j\u00f5udluse \u00fcle.<\/p>\n

M\u00f5tlesime MySQL ja PostgreSQL \u00fcle. Kuid esimene ei sobinud kuidagi meile, samas kui teine on iseenesest \u00fcsna keeruline toode, ning lihtsate teenuste loomine selle p\u00f5hjal ei oleks otstarbekas.
\nProovisime RIAK'i, Cassandra't, isegi graafikandmebaasi. Need olid k\u00f5ik piisavalt ni\u0161ilahendused, mis ei sobinud \u00fcldiseks universaalseks t\u00f6\u00f6riistaks teenuste loomiseks.<\/p>\n

L\u00f5puks valisime Tarantooli.<\/p>\n

Me p\u00f6\u00f6rdusime selle poole, kui see oli versioonis 1.6. Meid huvitas key-value ja relatsioonilise andmebaasi funktsionaalsuse s\u00fcmbioos. Seal on teised indeksid, tehingud ja spacet, need on nagu tabelid, kuid mitte lihtsad, sinna saab salvestada erinevate arvu veerge. Kuid Tarantooli t\u00f5eline m\u00fc\u00fcgiargument olid sekundaarsed indeksid koos key-value ja tehingutel p\u00f5hineva l\u00e4henemisega.<\/p>\n

Samuti m\u00e4ngis oma rolli reageeriv venekeelne kogukond, kes oli valmis chatis appi tulema. Kasutasime seda aktiivselt ja elasime chatis. Ja ei tohi unustada korralikku p\u00fcsivust ilma ilmselgete probleemide ja vigadeta. Kui vaadata meie ajalugu Tarantooliga, siis meil oli palju valu ja eba\u00f5nnestumisi replikatsiooniga, kuid me ei ole kunagi andmeid tema t\u00f5ttu kaotanud!<\/p>\n

Rakendamine algas raskelt.<\/h3>\n

\nSel ajal oli meie peamine arendustegevuse virn .NET, mille jaoks Tarantoolile ei olnud konnektorit. Alustasime kohe Go'ga midagi kirjutamist. Lua'ga tuli ka p\u00e4ris h\u00e4sti v\u00e4lja. Sel hetkel oli peamine probleem silumisest: .NET-is oli sellega k\u00f5ik suurep\u00e4rane, aga seej\u00e4rel siseneda embedded Lua maailma, kus sul pole mingit silumist peale logide, oli keeruline. Lisaks hakkas replikatsioon mingil p\u00f5hjusel perioodiliselt purunema, pidime s\u00fcvenema Tarantooli mootori seadmetesse. Sellega aitas chat, dokumentatsioon v\u00e4hem, m\u00f5nikord vaatasime ka koodi. Sel ajal oli dokumentatsioon keskp\u00e4rane.<\/p>\n

Nii on m\u00f5ne kuu jooksul \u00f5nnestunud koguda kogemusi ja saavutada muljetavaldavaid tulemusi Tarantooliga t\u00f6\u00f6tamisel. Meie git-repositooriumis on dokumenteeritud ideaaln\u00e4idised, mis on aidanud luua uusi mikroteenuseid. N\u00e4iteks, kui tekkis \u00fclesanne luua uus mikroteenus, vaatas arendaja standardlahenduse l\u00e4htekoodi repositooriumist ja uue loomine ei v\u00f5tnud rohkem kui n\u00e4dal. <\/p>\n

Need olid erilised ajad. Sel ajal sai administ naabert\u00f6\u00f6laual k\u00fcsida: \"Anna mulle virtuaalserver\". Umbes kolmk\u00fcmmend minutit hiljem oli masin juba sinu k\u00e4es. Sa ise \u00fchendusid, installisid k\u00f5ik vajaliku ja sulle suunati sinna liiklus.<\/p>\n

T\u00e4nap\u00e4eval ei \u00f5nnestu see enam niimoodi: peab seadistama teenusele monitooringu, logimise, funktsionaalsuse katmiseks testid, tellima virtuaalserveri v\u00f5i Kuberneetse seadistuse jne. \u00dcldiselt on see parem, kuigi see v\u00f5tab rohkem aega ja on vaevarikam.<\/p>\n

Jaga ja valluta. Kuidas on lood Luaga?<\/h3>\n

\nSellel oli t\u00f5sine dilemma: m\u00f5nel meeskonnal ei \u00f5nnestunud usaldusv\u00e4\u00e4rselt reklaamida muudatusi teenuses, milles oli palju loogikat Luas. Sageli saatis see kaasa teenuse toimimatuks j\u00e4\u00e4mise. <\/p>\n

See t\u00e4hendab, et arendajad valmistavad mingisuguse muudatuse ette. Tarantool hakkab tegema migratsiooni, samas kui replikal on veel vana kood; sinna j\u00f5uab replikatsiooni kaudu mingi DDL, veel midagi, ja kood lihtsalt laguneb, kuna see ei ole arvesse v\u00f5etud. Tulemuseks oli see, et administraatorite uuendamisprotseduur oli kirjutatud A4-le: peata replikatsioon, uuenda see, k\u00e4ivita replikatsioon, l\u00fclita siit v\u00e4lja, uuenda seal. \u00d5udus! <\/p>\n

L\u00f5puks \u00fcritame me n\u00fc\u00fcd enamasti Luaga mitte midagi teha. Lihtsalt iproto kaudu (binaarne protokoll serveriga suhtlemiseks) ja k\u00f5ik. V\u00f5ib-olla on see arendajate teadmiste puudus, kuid sellisest vaatenurgast on s\u00fcsteem keeruline.<\/p>\n

Me ei j\u00e4rgigi seda stsenaariumi alati pimesi. T\u00e4na ei ole meil musta ega valget: kas k\u00f5ik on Luas v\u00f5i k\u00f5ik on Go-s. Me juba m\u00f5istame, kuidas neid kombineerida, et hiljem migratsiooni probleemidega silmitsi seista.<\/p>\n

Kus on praegu Tarantool?
\nTarantool on kasutusel kauba l\u00f5pphinnangute arvutamise teenuses, mis arvestab ka allahindluskupongidega, tuntud kui \u00abPromotayzer\u00bb. Nagu eelnevalt mainitud, j\u00e4\u00e4b see n\u00fc\u00fcd ajalukku: selle asemele tuleb uus katalooge teenus koos eelnevalt arvutatud hindadega, kuid veel kuus kuud tagasi tehti k\u00f5ik arvutused \u00abPromotayzeris\u00bb. Varem oli pool selle loogikast kirjutatud Lua-s. Kaks aastat tagasi muudeti teenus arhiveerimiseks ja loogika kirjutati Go-s \u00fcmber, kuna allahindluste t\u00f6\u00f6mehaanika muutus veidi ja teenusele ei piisanud j\u00f5udlusest. <\/p>\n

\u00dcks kriitilisemaid teenuseid on kasutajaprofiil. Seega k\u00f5ik Wildberries kasutajad on salvestatud Tarantooli, neid on umbes 50 miljonit. ID p\u00f5hjal sharditud s\u00fcsteem, mis on jaotatud mitme andmekeskuse vahel ja \u00fchendatud Go-teenustega.
\nRPS j\u00e4rgi oli kunagi liider \u00abPromotayzer\u00bb, mis j\u00f5udis 6000 p\u00e4ringuni. \u00dchel hetkel oli meil 50-60 eksemplari. Praegu on RPS liider - kasutajaprofiilid, umbes 12 tuhat. Selle teenuse puhul kasutatakse kohandatud shardingut, jagades kasutaja ID-de vahemike kaupa. Teenus teenindab rohkem kui 20 masinat, kuid see on liiga palju, plaanime eraldatud ressursse v\u00e4hendada, sest 4-5 masina v\u00f5imekusest piisab.<\/p>\n

Sessiooniteenus on meie esimene teenus vshard ja Cartridge'i peal. Vshard'i seadistamine ja Cartridge'i uuendamine n\u00f5udis meilt teatud t\u00f6\u00f6j\u00f5udu, kuid l\u00f5puks sai k\u00f5ik korda.<\/p>\n

Teenuse, mis kuvab erinevaid b\u00e4nnerid veebisaidil ja mobiilirakenduses, oli \u00fcks esimesi, mis lasti v\u00e4lja kohe Tarantooli peal. See teenus on t\u00e4helepanuv\u00e4\u00e4rne, et see on olnud kasutuses umbes 6-7 aastat ning pole kordagi taask\u00e4ivitatud. Kasutati replikeerimist master-master. Midagi ei ole kunagi katkenud.<\/p>\n

On n\u00e4ide Tarantooli kasutamisest kiirete kataloogide funktsionaalsuses laos\u00fcsteemis, et kiiremini teatud juhtudel teavet uuesti kontrollida. Proovisime selleks kasutada Redis't, kuid andmed m\u00e4lus v\u00f5tsid rohkem kohta kui Tarantoolil.<\/p>\n

Ootej\u00e4rjekorra, klienditellimuste, praegu moes olevate lugude ja ootel toodete teenused t\u00f6\u00f6tavad samuti Tarantooliga. Viimane teenus v\u00f5tab m\u00e4lus umbes 120 GB. See on k\u00f5ige mahukam teenus eespool nimetatutest. <\/p>\n

Kokkuv\u00f5te<\/h3>\n

\nSekundaarsete indeksite, key-value ja tehingute kombinatsioon teeb Tarantooli suurep\u00e4raseks valikuks mikroteenuste arhitektuuridele. Siiski kohtasime raskusi teenuste muudatuste juurutamisel, kus oli palju Lua-logi - teenused lakkasid tihti t\u00f6\u00f6tamast. Seda me ei suutnud lahendada ja aja jooksul j\u00f5udsime erinevatesse Lua ja Go kombinatsioonidesse: teame, millal kasutada \u00fchte keelt ja millal teist.<\/p>\n

Mida veel selle kohta lugeda<\/b><\/p>\n