ProHoster > Blogs > Administrācija > Kā beigt uztraukties un sākt dzīvot bez monolīta

Kā beigt uztraukties un sākt dzīvot bez monolīta

Kā beigt uztraukties un sākt dzīvot bez monolīta

Mums visiem patÄ«k stāsti. Mums patÄ«k sēdēt pie ugunskura un runāt par savām pagātnes uzvarām, cīņām vai vienkārÅ”i savu darba pieredzi.

Å odien ir tieÅ”i tāda diena. Un pat ja jÅ«s Å”obrÄ«d neesat pie ugunskura, mums ir jums stāsts. Stāsts par to, kā mēs sākām strādāt ar krātuvi pakalpojumā Tarantool.

Kādreiz mÅ«su uzņēmumā bija pāris ā€œmonolÄ«tiā€ un visiem vieni ā€œgriestiā€, kuriem Å”ie monolÄ«ti lēnām, bet noteikti tuvojās, ierobežojot mÅ«su uzņēmuma lidojumu, mÅ«su attÄ«stÄ«bu. Un bija skaidra sapratne: kādu dienu mēs smagi sitÄ«sim Å”os griestus.

Tagad dominē ideoloģija, kas nodala visu un visus, sākot no aprīkojuma līdz biznesa loģikai. Tā rezultātā mums, piemēram, ir divi DC, kas tīkla līmenī ir praktiski neatkarīgi. Un tad viss bija pavisam savādāk.

MÅ«sdienās ir daudz rÄ«ku un rÄ«ku izmaiņu veikÅ”anai CI/CD, K8S utt. ā€œMonolÄ«tajāā€ laikā mums nevajadzēja tik daudz sveÅ”vārdu. Pietika vienkārÅ”i izlabot ā€œuzglabāŔanuā€ datu bāzē.

Taču laiks gāja uz priekÅ”u, un lÄ«dz ar to palielinājās arÄ« pieprasÄ«jumu skaits, dažkārt pārsniedzot mÅ«su iespējas. LÄ«dz ar NVS valstu ienākÅ”anu tirgÅ«, pirmā monolÄ«ta datu bāzes procesora slodze nenoslÄ«dēja zem 90%, un RPS palika 2400 lÄ«menÄ«. Un tie nebija tikai nelieli selektori, bet gan dūŔīgi vaicājumi ar virkne pārbaužu un JOIN, kas varētu darboties gandrÄ«z pusei datu uz liela IO fona.

Kad uz skatuves sāka parādÄ«ties pilnvērtÄ«gi Melnās piektdienas izpārdoÅ”anas ā€“ un Wildberry bija viena no pirmajām, kas tās rÄ«koja Krievijā ā€“, situācija kļuva pavisam bēdÄ«ga. Galu galā slodze Ŕādās dienās palielinās trÄ«s reizes.
Ak, Ŕie "monolītie laiki"! Esmu pārliecināts, ka esat piedzīvojis ko līdzīgu, un joprojām nevarat saprast, kā tas var notikt ar jums.

Ko jÅ«s varat darÄ«t - modei ir raksturÄ«ga tehnoloÄ£ija. Apmēram pirms 5 gadiem mums nācās pārdomāt vienu no Å”iem modiem, izveidojot .NET un MS SQL serverÄ« esoÅ”u vietni, kurā rÅ«pÄ«gi tika saglabāta visa vietnes loÄ£ika. Turēju to tik rÅ«pÄ«gi, ka tāda monolÄ«ta zāģēŔana izrādÄ«jās ilgs un nebÅ«t ne viegls prieks.
Neliela atkāpe.

Dažādos pasākumos saku: "ja nezāģēji monolÄ«tu, tad neaugi!" Mani interesē jÅ«su viedoklis par Å”o jautājumu, lÅ«dzu, rakstiet to komentāros.

Pērkona skaņa

AtgriezÄ«simies pie sava "ugunskura". Lai sadalÄ«tu ā€œmonolÄ«tāsā€ funkcionalitātes slodzi, mēs nolēmām sistēmu sadalÄ«t mikropakalpojumos, kuru pamatā ir atvērtā pirmkoda tehnoloÄ£ijas. Jo tos ir vismaz lētāk mērogot. Un mums bija 100% izpratne, ka mums bÅ«s jāmēro (un daudz). Galu galā jau tajā laikā bija iespēja iekļūt kaimiņvalstu tirgos, un reÄ£istrāciju skaits, kā arÄ« pasÅ«tÄ«jumu skaits sāka augt vēl spēcÄ«gāk.

Izanalizējot pirmos kandidātus pārejai no monolÄ«ta uz mikropakalpojumiem, sapratām, ka 80% tajos rakstÄ«tā nāk no back office sistēmām, bet lasÄ«Å”ana ā€“ no front office. Pirmkārt, tas attiecās uz pāris mums svarÄ«gām apakÅ”sistēmām - lietotāju datiem un preču galÄ«go izmaksu aprēķināŔanas sistēmu, pamatojoties uz informāciju par papildu klientu atlaidēm un kuponiem.

Atkāpe. Tagad ir bail iedomāties, bet bez iepriekÅ”minētajām apakÅ”sistēmām no mÅ«su monolÄ«ta tika izņemti arÄ« preču katalogi, lietotāju iepirkumu grozs, preču meklÄ“Å”anas sistēma, preču katalogu filtrÄ“Å”anas sistēma un dažādas ieteikumu sistēmas. Katras no tām darbÄ«bai ir atseviŔķas Å”auri pielāgotu sistēmu klases, taču kādreiz tās visas dzÄ«voja vienā ā€œmājāā€.

Uzreiz plānojām pārsÅ«tÄ«t datus par saviem klientiem uz Ŕķelto sistēmu. Preču gala izmaksu aprēķināŔanas funkcionalitātes noņemÅ”anai bija nepiecieÅ”ama laba mērogojamÄ«ba lasÄ«Å”anai, jo tā radÄ«ja vislielāko RPS slodzi un bija visgrÅ«tāk Ä«stenojama datu bāzei (aprēķinu procesā tiek iesaistÄ«ts daudz datu).

Rezultātā mēs nonācām pie shēmas, kas labi sader ar Tarantool.

Tolaik mikropakalpojumu darbÄ«bai tika izvēlētas shēmas darbam ar vairākiem datu centriem uz virtuālajām un aparatÅ«ras maŔīnām. Kā parādÄ«ts attēlos, Tarantool replikācijas opcijas tika izmantotas gan galvenā-galvenā, gan galvenā-pakalpojuma režīmos.

Kā beigt uztraukties un sākt dzīvot bez monolīta
Arhitektūra. 1. iespēja. Lietotāja pakalpojums

PaÅ”laik ir 24 shards, no kuriem katrā ir 2 eksemplāri (pa vienam katram DC), un tas viss ir galvenais ā€” galvenais režīms.

Datu bāzes augÅ”pusē ir lietojumprogrammas, kas piekļūst datu bāzes replikām. Lietojumprogrammas darbojas ar Tarantool, izmantojot mÅ«su pielāgoto bibliotēku, kas ievieÅ” Tarantool Go draivera saskarni. Viņa redz visas kopijas un var strādāt kopā ar meistaru, lai lasÄ«tu un rakstÄ«tu. BÅ«tÄ«bā tas ievieÅ” repliku kopas modeli, kas pievieno loÄ£iku kopiju atlasei, atkārtojumu veikÅ”anai, ķēdes pārtraucēju un ātruma ierobežojumu.

Šajā gadījumā ir iespējams konfigurēt replikas atlases politiku fragmentu kontekstā. Piemēram, roundrobin.

Kā beigt uztraukties un sākt dzīvot bez monolīta
ArhitektÅ«ra. Variants 2. Pakalpojums preču galÄ«go izmaksu aprēķināŔanai

Pirms dažiem mēneÅ”iem lielākā daļa pieprasÄ«jumu par preču galÄ«go paÅ”izmaksu nonāca pie jauna servisa, kas principā strādā bez datu bāzēm, bet pirms kāda laika visu 100% apstrādāja serviss ar Tarantool zem motora pārsega.

Pakalpojumu datu bāze sastāv no 4 masteriem, kuros sinhronizators apkopo datus, un katrs no Å”iem replikācijas pamatelementiem izplata datus tikai lasāmām replikām. Katram meistaram ir aptuveni 15 Ŕādas kopijas.

Pirmajā vai otrajā shēmā, ja viena līdzstrāva nav pieejama, lietojumprogramma var saņemt datus otrajā.

Ir vērts atzÄ«mēt, ka replikācija programmā Tarantool ir diezgan elastÄ«ga un to var konfigurēt izpildes laikā. Citās sistēmās radās grÅ«tÄ«bas. Piemēram, mainot parametrus max_wal_senders un max_replication_slots programmā PostgreSQL, ir jārestartē vednis, kas dažos gadÄ«jumos var izraisÄ«t savienojumu pārtraukÅ”anu starp lietojumprogrammu un DBVS.

Meklē un atradīsi!

Kāpēc mēs to nedarījām "kā normāli cilvēki", bet izvēlējāmies netipisku veidu? Tas ir atkarīgs no tā, kas tiek uzskatīts par normālu. Daudzi cilvēki parasti veido kopu no Mongo un izplata to trīs ģeogrāfiski sadalītos DC.

TobrÄ«d mums jau bija divi Redis projekti. Pirmā bija keÅ”atmiņa, bet otrā - pastāvÄ«ga ne pārāk kritisku datu krātuve. Ar viņu bija diezgan grÅ«ti, daļēji mÅ«su vainas dēļ. Reizēm galvenais bija diezgan lieli sējumi, un laiku pa laikam vietā kļuva slikti. Mēs izmantojām Å”o sistēmu master-slave versijā. Un bija daudz gadÄ«jumu, kad kaut kas notika ar meistaru un replikācija sabojājās.

Tas ir, Redis ir labs bezvalstnieku uzdevumiem, nevis statusa uzdevumiem. Principā tas ļāva atrisināt lielāko daļu problēmu, bet tikai tad, ja tie bija atslēgas vērtÄ«bas risinājumi ar indeksu pāri. Bet Redis toreiz bija diezgan bēdÄ«gs ar neatlaidÄ«bu un atkārtoÅ”anos. Turklāt bija sÅ«dzÄ«bas par veiktspēju.

Mēs domājām par MySQL un PostgreSQL. Bet pirmais mums kaut kā nesanāca, un otrais pats par sevi ir diezgan sarežģīts produkts, un nebÅ«tu pareizi uz tā veidot vienkārÅ”us pakalpojumus.
Mēs izmēģinājām RIAK, Cassandra, pat grafiku datu bāzi. Tie visi ir diezgan niÅ”as risinājumi, kas nebija piemēroti vispārēja universāla pakalpojumu radÄ«Å”anas instrumenta lomai.

Galu galā mēs apmetāmies uz Tarantool.

Mēs tam pievērsāmies, kad tas bija 1.6 versijā. MÅ«s ieinteresēja atslēgas vērtÄ«bas simbioze un relāciju datu bāzes funkcionalitāte. Ir sekundārie indeksi, transakcijas un atstarpes, tās ir kā tabulas, bet nav vienkārÅ”as, tajās var uzglabāt dažādu kolonnu skaitu. Bet Tarantool galvenā iezÄ«me bija sekundārie indeksi, kas apvienoti ar atslēgas vērtÄ«bu un darÄ«jumu spēju.

Savu lomu spēlēja arÄ« atsaucÄ«gā krievvalodÄ«go kopiena, kas bija gatava palÄ«dzēt tērzÄ“Å”anā. Mēs to aktÄ«vi izmantojām un dzÄ«vojam tieÅ”i tērzÄ“Å”anā. Un neaizmirstiet par pienācÄ«gu neatlaidÄ«bu bez acÄ«mredzamām kļūdām un kļūdām. Ja paskatās uz mÅ«su vēsturi ar Tarantool, mums bija daudz sāpju un neveiksmju ar replikāciju, taču mēs nekad nezaudējām datus tās vainas dēļ!

ÄŖstenoÅ”anas sākums bija aptuvens

Tajā laikā mÅ«su galvenais izstrādes steks bija .NET, kuram nebija Tarantool savienotāja. Uzreiz sākām kaut ko darÄ«t Go. Tas labi strādāja arÄ« ar Lua. Galvenā problēma tajā laikā bija ar atkļūdoÅ”anu: .NET ar Å”o viss ir lieliski, bet pēc tam bija grÅ«ti ienirt iegultās Lua pasaulē, kad jums nav nekādas atkļūdoÅ”anas, izņemot žurnālus. Turklāt replikācija nez kāpēc periodiski izjuka, tāpēc nācās iedziļināties Tarantool dzinēja struktÅ«rā. TērzÄ“Å”ana palÄ«dzēja ar to un mazākā mērā arÄ« dokumentāciju; dažreiz mēs apskatÄ«jām kodu. Toreiz dokumentācija bija tik un tā.

Tāpēc vairāku mēneÅ”u laikā man izdevās sakārtot galvu un iegÅ«t pienācÄ«gus rezultātus, strādājot ar Tarantool. Mēs apkopojām atsauces izstrādes git, kas palÄ«dzēja izveidot jaunus mikropakalpojumus. Piemēram, kad radās uzdevums: izveidot citu mikropakalpojumu, izstrādātājs repozitorijā apskatÄ«ja atsauces risinājuma pirmkodu, un jauna izveide aizņēma ne vairāk kā nedēļu.

Tie bija Ä«paÅ”i laiki. Parasti jÅ«s varētu pieiet pie administratora pie blakus galda un pajautāt: "Dodiet man virtuālo maŔīnu." Pēc apmēram trÄ«sdesmit minÅ«tēm automaŔīna jau bija pie jums. JÅ«s pats izveidojāt savienojumu, visu instalējāt, un satiksme tika nosÅ«tÄ«ta jums.

Å odien tas vairs nedarbosies: pakalpojumam jāpievieno uzraudzÄ«ba un reÄ£istrÄ“Å”ana, funkcionalitāte jāpārklāj ar testiem, jāpasÅ«ta virtuālā maŔīna vai piegāde uz Kuber utt. Kopumā tā bÅ«s labāk, lai gan tas prasÄ«s ilgāku laiku un bÅ«s apgrÅ«tinoŔāk.

Skaldi un valdi. Kāds darījums ar Lua?

Bija nopietna dilemma: dažas komandas nespēja droÅ”i ieviest izmaiņas pakalpojumā ar daudz loÄ£ikas Lua. To bieži pavadÄ«ja pakalpojums, kas nedarbojās.

Tas ir, izstrādātāji gatavo kaut kādas izmaiņas. Tarantool sāk veikt migrāciju, bet kopija joprojām ir ar veco kodu; Kāds DDL vai kas cits tur nonāk caur replikāciju, un kods vienkārÅ”i izjÅ«k, jo netiek ņemts vērā. Rezultātā administratoru atjaunināŔanas procedÅ«ra tika izklāstÄ«ta uz A4 lapas: pārtrauciet replikāciju, atjauniniet Å”o, ieslēdziet replikāciju, izslēdziet Å”eit, atjauniniet tur. Murgs!

Rezultātā tagad Luā visbiežāk cenÅ”amies neko nedarÄ«t. VienkārÅ”i izmantojiet iproto (bināro protokolu mijiedarbÄ«bai ar serveri), un tas arÄ« viss. VarbÅ«t tas ir izstrādātāju zināŔanu trÅ«kums, taču no Ŕī viedokļa sistēma ir sarežģīta.

Mēs ne vienmēr akli sekojam Å”im scenārijam. Å odien mums nav melnā un baltā: vai nu viss ir Lua, vai viss ir Go. Mēs jau saprotam, kā mēs varam tos apvienot, lai vēlāk nesaskartos ar migrācijas problēmām.

Kur tagad atrodas Tarantool?
Pakalpojumā Tarantool tiek izmantots, lai aprēķinātu preču galÄ«gās izmaksas, ņemot vērā atlaižu kuponus, kas pazÄ«stami arÄ« kā ā€œReklāmdevējsā€. Kā jau teicu iepriekÅ”, viņŔ tagad dodas pensijā: viņu aizstāj jauns katalogu pakalpojums ar iepriekÅ” aprēķinātām cenām, bet pirms pusgada visi aprēķini tika veikti Promotizer. IepriekÅ” puse no tās loÄ£ikas tika rakstÄ«ta Lua valodā. Pirms diviem gadiem serviss tika pārvērsts par krātuvi, un Go tika pārrakstÄ«ta loÄ£ika, jo bija nedaudz mainÄ«jusies atlaižu mehānika un pakalpojumam pietrÅ«ka veiktspējas.

Viens no svarīgākajiem pakalpojumiem ir lietotāja profils. Tas nozīmē, ka visi Wildberry lietotāji tiek glabāti pakalpojumā Tarantool, un to ir aptuveni 50 miljoni. Sistēma, kas sadalīta ar lietotāja ID, kas sadalīta pa vairākiem DC, kas savienoti ar Go pakalpojumiem.
Pēc RPS datiem, Promoter savulaik bija lÄ«deris, sasniedzot 6 tÅ«kstoÅ”us pieprasÄ«jumu. Vienā brÄ«dÄ« mums bija 50-60 eksemplāru. Tagad RPS lÄ«deris ir lietotāju profili, aptuveni 12 tÅ«kstoÅ”i. Å is pakalpojums izmanto pielāgotu sadalÄ«Å”anu, dalÄ«tu ar lietotāju ID diapazoniem. Serviss apkalpo vairāk nekā 20 maŔīnas, bet tas ir par daudz, plānojam samazināt pieŔķirtos resursus, jo tam pietiek ar 4-5 aparātu jaudu.

Sesijas pakalpojums ir mūsu pirmais pakalpojums vshard un kasetnei. Vshard iestatīŔana un Kasetnes atjaunināŔana prasīja no mums zināmas pūles, taču galu galā viss izdevās.

Pakalpojums dažādu baneru attēloÅ”anai vietnē un mobilajā aplikācijā bija viens no pirmajiem, kas tika izlaists tieÅ”i Tarantool. Å is pakalpojums ir ievērojams ar to, ka tam ir 6-7 gadi, tas joprojām darbojas un nekad nav pārstartēts. Tika izmantota galvenā un galvenā replikācija. Nekad nekas nav salÅ«zis.

Ir piemērs Tarantool izmantoÅ”anai ātrai uzziņas funkcionalitātei noliktavas sistēmā, lai dažos gadÄ«jumos ātri vēlreiz pārbaudÄ«tu informāciju. Mēs mēģinājām Å”im nolÅ«kam izmantot Redis, taču dati atmiņā aizņēma vairāk vietas nekā Tarantool.

Ar Tarantool darbojas arÄ« gaidÄ«Å”anas saraksta pakalpojumi, klientu abonementi, Å”obrÄ«d modÄ«gi stāsti un atliktās preces. Pēdējais pakalpojums atmiņā aizņem apmēram 120 GB. Å is ir visplaŔākais pakalpojums no iepriekÅ”minētajiem.

Secinājums

Pateicoties sekundārajiem indeksiem, kas apvienoti ar atslēgas vērtÄ«bu un transakciju, Tarantool ir labi piemērots uz mikropakalpojumiem balstÄ«tām arhitektÅ«rām. Tomēr mēs saskārāmies ar grÅ«tÄ«bām, ievieÅ”ot izmaiņas pakalpojumos ar lielu loÄ£iku pakalpojumā Lua ā€” pakalpojumi bieži pārstāja darboties. Mēs nevarējām to pārvarēt, un laika gaitā mēs nonācām pie dažādām Lua un Go kombinācijām: mēs zinām, kur lietot vienu valodu un kur citu valodu.

Ko vēl lasīt par tēmu

Avots: www.habr.com

Pievieno komentāru