Ons is almal lief vir stories. Ons sit graag om die vuur en praat oor ons vorige oorwinnings, gevegte, of bloot ons werkservaring.
Vandag is net so 'n dag. En al is jy nie nou by die vuur nie, het ons 'n storie vir jou. Die storie van hoe ons met berging op Tarantool begin werk het.
Eens op 'n tyd het ons maatskappy 'n paar "monoliete" en een "plafon" vir almal gehad, waarheen hierdie monoliete stadig maar seker nader gekom het, wat die vlug van ons maatskappy, ons ontwikkeling, beperk het. En daar was 'n duidelike begrip: eendag sal ons hierdie plafon hard tref.
Dit is nou die heersende ideologie om alles en almal te skei, van toerusting tot besigheidslogika. As gevolg hiervan het ons byvoorbeeld twee GS'e wat feitlik onafhanklik is op netwerkvlak. En toe was alles heeltemal anders.
Vandag is daar baie gereedskap en gereedskap om veranderinge aan te bring in die vorm van CI/CD, K8S, ens. In die “monolitiese” tyd het ons nie soveel vreemde woorde nodig gehad nie. Dit was genoeg om bloot die "berging" in die databasis reg te stel.
Maar die tyd het vorentoe beweeg, en die aantal versoeke het saam met dit vorentoe beweeg, en soms het RPS bo ons vermoëns geskiet. Met die toetrede van die GOS-lande tot die mark, het die las op die databasisverwerker van die eerste monoliet nie onder 90% gedaal nie, en RPS het op die vlak van 2400 gebly. En dit was nie net klein keurders nie, maar stewige navrae met 'n klomp tjeks en JOINs wat byna vir die helfte van die data kan loop teen die agtergrond van groot IO.
Toe volwaardige Swart Vrydag-verkope op die toneel begin verskyn - en Wildberries was een van die eerstes wat dit in Rusland gehou het - het die situasie heeltemal hartseer geword. Die las op sulke dae neem immers drie keer toe.
O, hierdie “monolitiese tye”! Ek is seker dat jy iets soortgelyks ervaar het, en jy kan steeds nie verstaan hoe dit met jou kan gebeur nie.
Wat kan jy doen - mode is inherent aan tegnologie. Ongeveer 5 jaar gelede moes ons een van hierdie mods heroorweeg in die vorm van 'n bestaande webwerf op .NET en MS SQL-bediener, wat al die logika van die webwerf self noukeurig gestoor het. Ek het dit so versigtig gehou dat die saag van so 'n monoliet 'n lang en glad nie maklike plesier was nie.
'n Klein afwyking.
By verskeie geleenthede sê ek: "As jy nie 'n monoliet gesien het nie, dan het jy nie gegroei nie!" Ek stel belang in jou mening oor hierdie saak, skryf dit asseblief in die kommentaar.
'n Geluid van donderweer
Kom ons keer terug na ons “bonfire”. Om die vrag "monolitiese" funksionaliteit te versprei, het ons besluit om die stelsel in mikrodienste te verdeel wat op oopbrontegnologieë gebaseer is. Omdat hulle ten minste goedkoper is om te skaal. En ons het 100% begrip gehad dat ons sou moes skaal (en baie). Dit was immers reeds in daardie tyd moontlik om die markte van buurlande te betree, en die aantal registrasies, sowel as die aantal bestellings, het selfs sterker begin groei.
Nadat ons die eerste kandidate vir die afwyking van die monoliet na mikrodienste ontleed het, het ons besef dat 80% van die skrif daarin afkomstig is van agterkantoorstelsels en lees vanaf die voorkantoor. Eerstens het dit betrekking op 'n paar belangrike substelsels vir ons - gebruikersdata en 'n stelsel vir die berekening van die finale koste van goedere gebaseer op inligting oor bykomende klantafslag en koepons.
Ingekeep. Nou is dit skrikwekkend om te dink, maar benewens bogenoemde substelsels is produkkatalogusse, 'n gebruikersinkopiemandjie, 'n produksoekstelsel, 'n filterstelsel vir produkkatalogusse en verskeie soorte aanbevelingstelsels ook uit ons monoliet verwyder. Vir die werking van elkeen van hulle is daar afsonderlike klasse van nougepasmaakte stelsels, maar eens op 'n tyd het hulle almal in een "huis" gewoon.
Ons het dadelik beplan om data oor ons kliënte na die versnipperde stelsel oor te dra. Die verwydering van funksionaliteit vir die berekening van die finale koste van goedere het goeie skaalbaarheid vir lees vereis, omdat dit die grootste RPS-lading geskep het en die moeilikste was om te implementeer vir die databasis (baie data is betrokke by die berekeningsproses).
Gevolglik het ons met 'n skema vorendag gekom wat goed by Tarantool pas.
Op daardie tydstip, vir die bedryf van mikrodienste, is skemas gekies om met verskeie datasentrums op virtuele en hardewaremasjiene te werk. Soos in die figure getoon, is Tarantool-replikasie-opsies in beide meester-meester- en meester-slaaf-modusse toegepas.
Argitektuur. Opsie 1. Gebruikersdiens
Op die oomblik is daar 24 skerwe, wat elk 2 gevalle het (een vir elke GS), alles in meester-meester-modus.
Op die top van die databasis is toepassings wat toegang verkry tot databasis replikas. Toepassings werk met Tarantool deur ons pasgemaakte biblioteek, wat die Tarantool Go-bestuurderkoppelvlak implementeer. Sy sien al die replikas en kan saam met die meester werk om te lees en skryf. In wese implementeer dit die replika-stelmodel, wat logika byvoeg vir die kies van replikas, die uitvoering van herprobasies, 'n stroombreker en 'n tempolimiet.
In hierdie geval is dit moontlik om die replika-seleksiebeleid in die konteks van skerwe op te stel. Byvoorbeeld, roundrobin.
Argitektuur. Opsie 2. Diens vir die berekening van die finale koste van goedere
'n Paar maande gelede het die meeste van die versoeke vir die berekening van die finale koste van goedere na 'n nuwe diens gegaan, wat in beginsel sonder databasisse werk, maar 'n tyd gelede is alles 100% verwerk deur 'n diens met Tarantool onder die kap.
Die diensdatabasis bestaan uit 4 meesters waarin die sinchroniseerder data insamel, en elkeen van hierdie replikasiemeesters versprei data na leesalleen replikas. Elke meester het ongeveer 15 sulke replikas.
Of in die eerste of in die tweede skema, as een DC nie beskikbaar is nie, kan die toepassing data in die tweede ontvang.
Dit is opmerklik dat replikasie in Tarantool redelik buigsaam is en tydens looptyd gekonfigureer kan word. In ander stelsels het probleme ontstaan. Byvoorbeeld, die verandering van die max_wal_senders en max_replication_slots parameters in PostgreSQL vereis 'n herbegin van die towenaar, wat in sommige gevalle kan lei tot die verbreek van verbindings tussen die toepassing en die DBMS.
Soek en jy sal vind!
Hoekom het ons dit nie "soos normale mense" gedoen nie, maar 'n atipiese manier gekies? Dit hang af van wat as normaal beskou word. Baie mense maak gewoonlik 'n groep van Mongo en versprei dit oor drie geo-verspreide DC's.
Op daardie stadium het ons reeds twee Redis-projekte gehad. Die eerste was 'n kas, en die tweede was 'n aanhoudende berging vir nie te kritieke data nie. Dit was nogal moeilik met hom, deels deur ons skuld. Soms was nogal groot volumes in die sleutel, en van tyd tot tyd het die terrein onwel geraak. Ons het hierdie stelsel in die meester-slaaf weergawe gebruik. En daar was baie gevalle waar iets met die meester gebeur het en replikasie onklaar geraak het.
Dit wil sê, Redis is goed vir staatlose take, nie statige take nie. In beginsel kon dit die meeste probleme oplos, maar slegs as dit sleutelwaarde-oplossings met 'n paar indekse was. Maar Redis was destyds nogal hartseer met volharding en replikasie. Boonop was daar klagtes oor prestasie.
Ons het aan MySQL en PostgreSQL gedink. Maar die eerste een het ons op een of ander manier nie vasgevang nie, en die tweede een is 'n taamlik gesofistikeerde produk op sigself, en dit sal onvanpas wees om eenvoudige dienste daarop te bou.
Ons het RIAK, Cassandra, selfs 'n grafiekdatabasis probeer. Dit is alles redelike nisoplossings wat nie geskik was vir die rol van 'n algemene universele hulpmiddel om dienste te skep nie.
Uiteindelik het ons op Tarantool gevestig.
Ons het daarna gedraai toe dit in weergawe 1.6 was. Ons was daarin geïnteresseerd deur die simbiose van sleutel-waarde en die funksionaliteit van 'n relasionele databasis. Daar is sekondêre indekse, transaksies en spasies, dit is soos tabelle, maar nie eenvoudig nie, jy kan verskillende getalle kolomme daarin stoor. Maar die moordende kenmerk van Tarantool was sekondêre indekse gekombineer met sleutelwaarde en transaksionaliteit.
Die responsiewe Russiessprekende gemeenskap, gereed om in die gesels te help, het ook 'n rol gespeel. Ons het dit aktief gebruik en leef direk in die klets. En moenie vergeet van ordentlike aanhoudende sonder ooglopende flaters en foute nie. As u na ons geskiedenis met Tarantool kyk, het ons baie pyn en mislukkings gehad met replikasie, maar ons het nooit data verloor as gevolg van die fout nie!
Implementering het moeilik begin
Op daardie tydstip was ons hoofontwikkelingstapel .NET, waaraan daar geen verbinding vir Tarantool was nie. Ons het dadelik iets in Go begin doen. Dit het ook goed gewerk met Lua. Die grootste probleem op daardie tydstip was met ontfouting: in .NET is alles goed hiermee, maar daarna was dit moeilik om in die wêreld van ingebedde Lua in te duik, wanneer jy geen ontfouting het nie, behalwe logs. Boonop het replikasie om een of ander rede periodiek uitmekaar geval, so ek moes in die struktuur van die Tarantool-enjin delf. Die klets het hiermee gehelp, en in 'n mindere mate die dokumentasie; soms het ons na die kode gekyk. Op daardie stadium was die dokumentasie so-so.
So, in die loop van 'n paar maande, het ek daarin geslaag om my kop rond te kry en ordentlike resultate te kry deur met Tarantool te werk. Ons het verwysingsontwikkelings in git saamgestel wat gehelp het met die vorming van nuwe mikrodienste. Byvoorbeeld, wanneer 'n taak ontstaan het: om 'n ander mikrodiens te skep, het die ontwikkelaar na die bronkode van die verwysingsoplossing in die bewaarplek gekyk, en dit het nie meer as 'n week geneem om 'n nuwe een te skep nie.
Dit was spesiale tye. Konvensioneel, dan kan jy na die admin by die volgende tafel gaan en vra: "Gee my 'n virtuele masjien." So dertig minute later was die kar reeds by jou. Jy het jouself gekoppel, alles geïnstalleer, en verkeer is na jou gestuur.
Vandag sal dit nie meer werk nie: jy moet monitering en aantekening by die diens voeg, die funksionaliteit met toetse dek, 'n virtuele masjien bestel of aflewering by Kuber, ens. Oor die algemeen sal dit beter wees op hierdie manier, hoewel dit langer sal neem en meer lastig sal wees.
Verdeel en heers. Wat is die saak met Lua?
Daar was 'n ernstige dilemma: sommige spanne was nie in staat om veranderinge aan 'n diens met baie logika in Lua betroubaar uit te voer nie. Dit het dikwels gepaard gegaan met die diens wat nie gewerk het nie.
Dit wil sê, die ontwikkelaars berei 'n soort verandering voor. Tarantool begin die migrasie doen, maar die replika is steeds met die ou kode; Sommige DDL of iets anders kom daar aan deur replikasie, en die kode val eenvoudig uitmekaar omdat dit nie in ag geneem word nie. As gevolg hiervan is die opdateringsprosedure vir die administrateurs op A4-vel uiteengesit: stop replikasie, werk dit op, skakel replikasie aan, skakel hier af, werk daar op. Nagmerrie!
Gevolglik probeer ons nou meestal niks in Lua doen nie. Gebruik net iproto ('n binêre protokol vir interaksie met die bediener), en dit is dit. Miskien is dit 'n gebrek aan kennis onder die ontwikkelaars, maar vanuit hierdie oogpunt is die stelsel kompleks.
Ons volg nie altyd blindelings hierdie skrif nie. Vandag het ons nie swart en wit nie: óf alles is in Lua, óf alles is in Go. Ons verstaan reeds hoe ons dit kan kombineer sodat ons nie later met migrasieprobleme sit nie.
Waar is Tarantool nou?
Tarantool word in die diens gebruik vir die berekening van die finale koste van goedere met inagneming van afslagkoepons, ook bekend as "Promotor". Soos ek vroeër gesê het, tree hy nou af: hy word vervang deur 'n nuwe katalogusdiens met vooraf berekende pryse, maar ses maande gelede is alle berekeninge in Promotizer gemaak. Voorheen was die helfte van sy logika in Lua geskryf. Twee jaar gelede is die diens in 'n bergingsfasiliteit omskep, en die logika is in Go herskryf, want die meganika van afslag het 'n bietjie verander en die diens het nie werkverrigting nie.
Een van die mees kritieke dienste is die gebruikersprofiel. Dit wil sê, alle Wildberries-gebruikers word in Tarantool gestoor, en daar is ongeveer 50 miljoen van hulle.
Volgens RPS was Promoter eens die leier en het 6 duisend versoeke bereik. Op 'n stadium het ons 50-60 kopieë gehad. Nou is die leier in RPS gebruikersprofiele, ongeveer 12 duisend. Hierdie diens maak gebruik van pasgemaakte sharding, gedeel deur reekse gebruikers-ID's. Die diens bedien meer as 20 masjiene, maar dit is te veel; ons beplan om die toegewese hulpbronne te verminder, want die kapasiteit van 4-5 masjiene is genoeg daarvoor.
Sessiediens is ons eerste diens op vshard en Cartridge. Om vshard op te stel en Cartridge op te dateer het 'n bietjie moeite van ons geverg, maar op die ou end het alles uitgewerk.
Die diens vir die vertoon van verskillende baniere op die webwerf en in die mobiele toepassing was een van die eerstes wat direk op Tarantool vrygestel is. Hierdie diens is opvallend vir die feit dat dit 6-7 jaar oud is, dit is steeds in werking en is nog nooit herlaai nie. Meester-meester-replikasie is gebruik. Niks het ooit gebreek nie.
Daar is 'n voorbeeld van die gebruik van Tarantool vir vinnige verwysingsfunksies in 'n pakhuisstelsel om inligting in sommige gevalle vinnig na te gaan. Ons het Redis hiervoor probeer gebruik, maar die data in die geheue het meer spasie opgeneem as Tarantool.
Die dienste van 'n waglys, kliëntintekeninge, tans modieuse stories en uitgestelde goedere werk ook saam met Tarantool. Die laaste diens in die geheue neem ongeveer 120 GB op. Dit is die mees omvattende diens van bogenoemde.
Gevolgtrekking
Danksy sekondêre indekse gekombineer met sleutelwaarde en transaksionaliteit, is Tarantool goed geskik vir mikrodienste-gebaseerde argitekture. Ons het egter probleme ondervind met die uitrol van veranderinge aan dienste met baie logika in Lua - die dienste het dikwels opgehou werk. Ons kon dit nie oorkom nie, en mettertyd het ons tot verskillende kombinasies van Lua en Go gekom: ons weet waar om een taal te gebruik en waar om 'n ander te gebruik.
Wat anders om te lees oor die onderwerp
- Die skep van 'n hoë-lading toepassing van nuuts af met behulp van Tarantool
- Betroubare leier keuse in Tarantool Cartridge
- Telegramkanaal Tarantool met nuus oor die produk
- Bespreek Tarantool in die gemeenskapklets
Bron: will.com
