Ni ĉiuj amas rakontojn. Ni ŝatas sidi ĉirkaŭ la fajro kaj paroli pri niaj pasintaj venkoj, bataloj aŭ simple nia laborsperto.
Hodiaŭ estas ĝuste tia tago. Kaj eĉ se vi ne estas ĉe la fajro nun, ni havas rakonton por vi. La rakonto pri kiel ni komencis labori kun stokado sur Tarantool.
Iam, nia kompanio havis paron da "monolitoj" kaj unu "plafonon" por ĉiuj, al kiuj ĉi tiuj monolitoj malrapide sed certe alproksimiĝis, limigante la flugon de nia kompanio, nian evoluon. Kaj estis klara kompreno: iam ni forte batos ĉi tiun plafonon.
Ĝi nun estas la reganta ideologio disigi ĉion kaj ĉiujn, de ekipaĵo ĝis komerca logiko. Kiel rezulto, ni, ekzemple, havas du PK kiuj estas praktike sendependaj ĉe la retonivelo. Kaj tiam ĉio estis tute alia.
Hodiaŭ, ekzistas multaj iloj kaj iloj por fari ŝanĝojn en la formo de CI/KD, K8S, ktp. En la "monolita" tempo, ni ne bezonis tiom da fremdaj vortoj. Sufiĉis simple korekti la "stokadon" en la datumbazo.
Sed la tempo antaŭeniris, kaj la nombro da petoj antaŭeniris kune kun ĝi, foje pafante RPS preter niaj kapabloj. Kun la eniro de la CIS-landoj en la merkaton, la ŝarĝo sur la datumbaza procesoro de la unua monolito ne falis sub 90%, kaj RPS restis sur la nivelo de 2400. Kaj ĉi tiuj ne estis nur malgrandaj elektiloj, sed pezaj demandoj kun amaso da ĉekoj kaj JOIN-oj, kiuj povus funkcii preskaŭ por duono de la datumoj sur la fono de granda IO.
Kiam plenrajta vendo de Nigra Vendredo komencis aperi sur la sceno - kaj Wildberries estis unu el la unuaj, kiuj tenis ilin en Rusio - la situacio iĝis tute malĝoja. Post ĉio, la ŝarĝo en tiaj tagoj pliiĝas trifoje.
Ho, ĉi tiuj "monolitaj tempoj"! Mi certas, ke vi spertis ion similan, kaj vi ankoraŭ ne povas kompreni kiel tio povus okazi al vi.
Kion vi povas fari - modo estas propra al teknologio. Antaŭ ĉirkaŭ 5 jaroj, ni devis repensi unu el ĉi tiuj modoj en la formo de ekzistanta retejo sur .NET kaj MS SQL-servilo, kiu zorge konservis la tutan logikon de la retejo mem. Mi konservis ĝin tiel zorge, ke segi tian monoliton montriĝis longa kaj tute ne facila plezuro.
Eta digresio.
En diversaj eventoj mi diras: "se vi ne vidis monoliton, tiam vi ne kreskis!" Mi interesiĝas pri via opinio pri ĉi tiu afero, bonvolu skribi ĝin en la komentoj.
Sono de Tondro
Ni revenu al nia "fajro". Por distribui la ŝarĝon de "monolita" funkcieco, ni decidis dividi la sistemon en mikroservojn bazitajn sur malfermfontaj teknologioj. Ĉar, minimume, ili estas pli malmultekostaj por skalo. Kaj ni 100% komprenis, ke ni devos grimpi (kaj multe). Post ĉio, jam en tiu tempo eblis eniri la merkatojn de najbaraj landoj, kaj la nombro da registriĝoj, same kiel la nombro da mendoj, komencis kreski eĉ pli forte.
Analizinte la unuajn kandidatojn por foriro de la monolito al mikroservoj, ni rimarkis, ke 80% de la skribo en ili venas de back office-sistemoj, kaj legado de la frontoficejo. Antaŭ ĉio, ĉi tio koncernis kelkajn gravajn subsistemojn por ni - uzantajn datumojn kaj sistemon por kalkuli la finan koston de varoj surbaze de informoj pri pliaj klientaj rabatoj kaj kuponoj.
Indentigita. Nun estas timige imagi, sed krom la supre menciitaj subsistemoj ankaŭ estis forigitaj de nia monolito produktkatalogoj, aĉeta ĉaro de uzanto, produkta serĉsistemo, filtra sistemo por produktaj katalogoj kaj diversaj rekomendaj sistemoj. Por la funkciado de ĉiu el ili, ekzistas apartaj klasoj de mallarĝe tajloritaj sistemoj, sed iam ili ĉiuj vivis en unu "domo".
Ni tuj planis transdoni datumojn pri niaj klientoj al la sharded sistemo. La forigo de funkcieco por kalkuli la finan koston de varoj postulis bonan skaleblon por legado, ĉar ĝi kreis la plej grandan RPS-ŝarĝon kaj estis la plej malfacile efektivigi por la datumbazo (multaj datumoj estas implikitaj en la kalkulprocezo).
Kiel rezulto, ni elpensis skemon, kiu bone kongruas kun Tarantool.
Tiutempe, por funkciado de mikroservoj, skemoj por labori kun pluraj datumcentroj sur virtualaj kaj aparataj maŝinoj estis elektitaj. Kiel montrite en la figuroj, Tarantool-reproduktaj opcioj estis aplikitaj en kaj majstro-majstro kaj majstro-sklavo reĝimoj.
Arkitekturo. Opcio 1. Uzantservo
Nuntempe, ekzistas 24 fragmentoj, ĉiu el kiuj havas 2 okazojn (unu por ĉiu DC), ĉio en majstra-mastra reĝimo.
Aldone al la datumbazo estas aplikaĵoj, kiuj aliras datumbazajn kopiojn. Aplikoj funkcias kun Tarantool per nia kutima biblioteko, kiu efektivigas la ŝoforinterfacon de Tarantool Go. Ŝi vidas ĉiujn kopiojn kaj povas labori kun la majstro por legi kaj skribi. Esence, ĝi efektivigas la kopian aromodelon, kiu aldonas logikon por selektado de kopioj, elfarado de reprovoj, ŝaltilo kaj tariflimo.
En ĉi tiu kazo, eblas agordi la reproduktan elektopolitikon en la kunteksto de fragmentoj. Ekzemple, roundrobin.
Arkitekturo. Opcio 2. Servo por kalkuli la finan koston de varoj
Antaŭ kelkaj monatoj, la plej multaj el la petoj por kalkuli la finan koston de varoj iris al nova servo, kiu principe funkcias sen datumbazoj, sed antaŭ iom da tempo ĉio estis prilaborita 100% per servo kun Tarantool sub la kapuĉo.
La serva datumbazo konsistas el 4 majstroj en kiuj la sinkronigilo kolektas datumojn, kaj ĉiu el ĉi tiuj reproduktaj majstroj distribuas datumojn al nurlegeblaj kopioj. Ĉiu majstro havas proksimume 15 tiajn kopiojn.
Aŭ en la unua aŭ en la dua skemo, se unu PK estas neatingebla, la aplikaĵo povas ricevi datumojn en la dua.
Indas noti, ke reproduktado en Tarantool estas sufiĉe fleksebla kaj povas esti agordita ĉe rultempo. En aliaj sistemoj, malfacilaĵoj ekestis. Ekzemple, ŝanĝi la parametrojn max_wal_senders kaj max_replication_slots en PostgreSQL postulas rekomencon de la sorĉisto, kiu en iuj kazoj povas konduki al distranĉo de konektoj inter la aplikaĵo kaj la DBMS.
Serĉu kaj vi trovos!
Kial ni ne faris ĝin "kiel normalaj homoj", sed elektis maltipan manieron? Ĝi dependas de tio, kio estas konsiderata normala. Multaj homoj ĝenerale faras areton de Mongo kaj disvastigas ĝin tra tri geo-distribuitaj DC-oj.
Tiutempe, ni jam havis du Redis-projektojn. La unua estis kaŝmemoro, kaj la dua estis konstanta stokado por ne tro kritikaj datumoj. Estis sufiĉe malfacile kun li, parte pro nia kulpo. Foje sufiĉe grandaj volumoj estis en la ŝlosilo, kaj de tempo al tempo la retejo malboniĝis. Ni uzis ĉi tiun sistemon en la mastro-sklava versio. Kaj estis multaj kazoj kie io okazis al la majstro kaj reproduktado rompiĝis.
Tio estas, Redis estas bona por sennaciaj taskoj, ne ŝtataj. Principe ĝi permesis solvi plej multajn problemojn, sed nur se ili estis ŝlosilvaloraj solvoj kun paro da indeksoj. Sed Redis tiutempe estis sufiĉe malĝoja pro persisto kaj reproduktado. Krome, estis plendoj pri agado.
Ni pensis pri MySQL kaj PostgreSQL. Sed la unua iel ne atingis nin, kaj la dua estas sufiĉe altnivela produkto en si mem, kaj estus malkonvene konstrui simplajn servojn sur ĝi.
Ni provis RIAK, Cassandra, eĉ grafikan datumbazon. Ĉi tiuj ĉiuj estas sufiĉe niĉaj solvoj, kiuj ne taŭgis por la rolo de ĝenerala universala ilo por krei servojn.
Finfine ni decidis por Tarantool.
Ni turnis nin al ĝi kiam ĝi estis en versio 1.6. Ni interesiĝis pri ĝi per la simbiozo de ŝlosilvaloro kaj la funkcieco de interrilata datumbazo. Estas malĉefaj indeksoj, transakcioj kaj spacoj, ĉi tiuj estas kiel tabeloj, sed ne simplaj, vi povas konservi malsamajn nombrojn da kolumnoj en ili. Sed la mortiga trajto de Tarantool estis sekundaraj indeksoj kombinitaj kun ŝlosilvaloro kaj transakco.
Ankaŭ rolis la respondema ruslingva komunumo, preta helpi en babilado. Ni aktive uzis ĉi tion kaj vivas rekte en la babilejo. Kaj ne forgesu pri deca persista sen evidentaj eraroj kaj eraroj. Se vi rigardas nian historion kun Tarantool, ni havis multajn dolorojn kaj fiaskojn kun reproduktado, sed ni neniam perdis datumojn pro ĝia kulpo!
Efektivigo komenciĝis malglata
Tiutempe, nia ĉefa disvolva stako estis .NET, al kiu ne estis konektilo por Tarantool. Ni tuj komencis fari ion en Go. Ĝi funkciis bone ankaŭ kun Lua. La ĉefa problemo en tiu tempo estis pri senararigado: en .NET ĉio estas bonega kun tio, sed post tio estis malfacile plonĝi en la mondon de enigita Luao, kiam oni ne havas sencimigon krom protokoloj. Krome, ial reproduktado periode disfalis, do mi devis enprofundiĝi en la strukturon de la Tarantool-motoro. La babilejo helpis pri tio, kaj malpligrade, la dokumentado; foje ni rigardis la kodon. En tiu tempo, la dokumentado estis tiel-tiel.
Do, dum pluraj monatoj, mi sukcesis movi mian kapon kaj akiri decajn rezultojn de laborado kun Tarantool. Ni kompilis referencajn evoluojn en git, kiuj helpis kun la formado de novaj mikroservoj. Ekzemple, kiam aperis tasko: krei alian mikroservon, la programisto rigardis la fontkodon de la referenca solvo en la deponejo, kaj daŭris ne pli ol unu semajnon por krei novan.
Ĉi tiuj estis specialaj tempoj. Konvencie, tiam vi povus iri al la administranto ĉe la sekva tablo kaj demandi: "Donu al mi virtualan maŝinon." Ĉirkaŭ tridek minutojn poste la aŭto jam estis kun vi. Vi konektis vin, instalis ĉion, kaj trafiko estis sendita al vi.
Hodiaŭ ĉi tio ne plu funkcios: vi devas aldoni monitoradon kaj ensalutadon al la servo, kovri la funkciojn per testoj, mendi virtualan maŝinon aŭ liveradon al Kuber, ktp. Ĝenerale, estos pli bone tiel, kvankam ĝi daŭros pli longe kaj estos pli ĝena.
Dividu kaj regu. Kio estas la interkonsento kun Lua?
Estis serioza dilemo: iuj teamoj ne povis fidinde efektivigi ŝanĝojn al servo kun multe da logiko en Lua. Ĉi tio ofte estis akompanita de la servo ne funkcianta.
Tio estas, la programistoj preparas ian ŝanĝon. Tarantool komencas fari la migradon, sed la kopio ankoraŭ estas kun la malnova kodo; Iu DDL aŭ io alia alvenas tie per reproduktado, kaj la kodo simple disfalas ĉar ĝi ne estas konsiderata. Kiel rezulto, la ĝisdatiga proceduro por la administrantoj estis aranĝita sur A4-folio: ĉesu reproduktadon, ĝisdatigu ĉi tion, ŝaltu reproduktadon, malŝaltu ĉi tie, ĝisdatigu tie. Koŝmaro!
Rezulte, nun ni plej ofte provas fari nenion en Lua. Nur uzu iproto (binara protokolo por interagi kun la servilo), kaj jen ĝi. Eble ĉi tio estas manko de scio inter la programistoj, sed el ĉi tiu vidpunkto la sistemo estas kompleksa.
Ni ne ĉiam blinde sekvas ĉi tiun skripton. Hodiaŭ ni ne havas nigran kaj blankan: aŭ ĉio estas en Lua, aŭ ĉio estas en Go. Ni jam komprenas kiel ni povas kombini ilin, por ke ni ne poste havu migrajn problemojn.
Kie estas Tarantool nun?
Tarantool estas uzata en la servo por kalkuli la finan koston de varoj konsiderante rabatajn kuponojn, ankaŭ konatajn kiel "Promotanto". Kiel mi diris pli frue, li nun emeritiĝas: li estas anstataŭata de nova katalogo-servo kun antaŭkalkulitaj prezoj, sed antaŭ ses monatoj ĉiuj kalkuloj estis faritaj en Promotizer. Antaŭe, duono de ĝia logiko estis skribita en Lua. Antaŭ du jaroj, la servo estis igita stokejo, kaj la logiko estis reverkita en Go, ĉar la mekaniko de rabatoj iom ŝanĝiĝis kaj la servo mankis rendimento.
Unu el la plej kritikaj servoj estas la uzantprofilo. Tio estas, ĉiuj Wildberries-uzantoj estas stokitaj en Tarantool, kaj estas ĉirkaŭ 50 milionoj da ili.Sistemo dividita de uzantidentigilo, distribuita tra pluraj DC-oj konektitaj al Go-servoj.
Laŭ RPS, Promotor iam estis la gvidanto, atingante 6 mil petojn. Foje ni havis 50-60 ekzemplerojn. Nun la gvidanto en RPS estas uzantprofiloj, ĉirkaŭ 12 mil. Ĉi tiu servo uzas kutiman sharding, dividita per gamoj de uzantidentigiloj. La servo servas pli ol 20 maŝinojn, sed ĉi tio estas tro multaj; ni planas redukti la asignitajn rimedojn, ĉar la kapacito de 4-5 maŝinoj sufiĉas por ĝi.
Sesia servo estas nia unua servo pri vshard kaj Kartoĉo. Starigi vshard kaj ĝisdatigi Kartoĉon postulis iom da peno de ni, sed finfine ĉio funkciis.
La servo por montri malsamajn standardojn en la retejo kaj en la poŝtelefona aplikaĵo estis unu el la unuaj, kiuj estis publikigita rekte sur Tarantool. Ĉi tiu servo estas rimarkinda pro tio, ke ĝi aĝas 6-7 jarojn, ĝi ankoraŭ funkcias kaj neniam estis rekomencita. Majstro-majstra reproduktado estis uzita. Nenio iam rompiĝis.
Estas ekzemplo de uzado de Tarantool por rapida referenca funkcieco en magazena sistemo por rapide kontroli informojn en iuj kazoj. Ni provis uzi Redis por tio, sed la datumoj en memoro okupis pli da spaco ol Tarantool.
La servoj de atendolisto, klientaj abonoj, nuntempe modaj rakontoj kaj prokrastitaj varoj ankaŭ funkcias kun Tarantool. La lasta servo en memoro okupas ĉirkaŭ 120 GB. Ĉi tiu estas la plej ampleksa servo el la supre.
konkludo
Danke al malĉefaj indeksoj kombinitaj kun ŝlosilvaloro kaj transakco, Tarantool estas bone taŭga por mikroservoj-bazitaj arkitekturoj. Tamen, ni renkontis malfacilaĵojn dum la disvolvado de ŝanĝoj al servoj kun multe da logiko en Lua - la servoj ofte ĉesis funkcii. Ni ne povis venki ĉi tion, kaj kun la tempo ni venis al malsamaj kombinaĵoj de Lua kaj Go: ni scias kie uzi unu lingvon kaj kie uzi alian.
Kion alian legi pri la temo
- Krei altŝarĝan aplikaĵon de nulo uzante Tarantool
- Fida gvidanto elekto en Tarantool Kartoĉo
- Telegram-kanalo Tarantool kun novaĵoj pri la produkto
- Diskutu Tarantool en la komunuma babilejo
fonto: www.habr.com