Habr muudab maailma. Oleme blogi pidanud juba üle aasta. Umbes kuus kuud tagasi saime Khabroviteselt täiesti loogilise tagasiside: “Dodo, sa ütled igal pool, et sul on oma süsteem. Ja mis see süsteem on? Ja milleks pitsakett seda vajab?
Istusime, mõtlesime ja saime aru, et sul on õigus. Üritame kõike näpuga seletada, aga see tuleb välja rebitud tükkidena ja kuskil pole täielikku süsteemi kirjeldust. Nii algas pikk teekond teabe kogumiseks, autorite otsimiseks ja Dodo ISi artiklite sarja kirjutamiseks. Lähme!
Tänuavaldused: Täname, et jagasite meiega tagasisidet. Tänu temale kirjeldasime lõpuks süsteemi, koostasime tehnilise radari ja peagi avaldame oma protsesside mahuka kirjelduse. Ilma teieta oleksime seal istunud veel 5 aastat.
Artiklisari "Mis on Dodo IS?" räägib sellest:
- Varajane monoliit Dodo IS-is (2011-2015). (Käimas...)
- Tagakontori tee: eraldi baasid ja buss. (sa oled siin)
- Kliendipoolne tee: fassaad üle aluse (2016-2017). (Käimas...)
- Päris mikroteenuste ajalugu. (2018–2019). (Käimas...)
- Valmis monoliidi saagimine ja arhitektuuri stabiliseerimine. (Käimas...)
Kui olete huvitatud veel millestki - kirjutage kommentaaridesse.
Autori arvamus kronoloogilise kirjelduse kohta
Korraldan regulaarselt uute töötajate koosolekut teemal "Süsteemi arhitektuur". Nimetame seda "Sissejuhatus Dodo IS-i arhitektuurisse" ja see on osa uute arendajate sisseelamisprotsessist. Rääkides ühel või teisel kujul meie arhitektuurist, selle eripäradest, olen kirjeldusele sündinud teatud ajaloolise lähenemise.
Traditsiooniliselt vaatleme süsteemi kui komponentide (tehniliste või kõrgema taseme) kogumit, ärimooduleid, mis suhtlevad üksteisega mingi eesmärgi saavutamiseks. Ja kui selline vaade on kujundamisel õigustatud, siis pole see kirjeldamiseks ja mõistmiseks päris sobiv. Siin on mitu põhjust:
- Tegelikkus erineb paberil olevast. Kõik ei lähe nii, nagu ette nähtud. Ja meid huvitab, kuidas see tegelikult välja kukkus ja toimib.
- Info järjepidev esitamine. Tegelikult saate algusest kronoloogiliselt liikuda hetkeseisuni.
- Lihtsast keerukani. Mitte universaalselt, aga meie puhul on. Arhitektuur liikus lihtsamatelt lähenemistelt keerukamatele. Sageli lahendati keerukuse kaudu juurutamise kiiruse ja stabiilsuse probleemid, aga ka kümned muud omadused mittefunktsionaalsete nõuete loendist ( hästi räägitud keerukuse vastandamisest muudele nõuetele).
2011. aastal nägi Dodo IS arhitektuur välja selline:
Aastaks 2020 on see muutunud veidi keerulisemaks ja muutunud selliseks:
Kuidas see areng toimus? Miks on vaja süsteemi erinevaid osi? Milliseid arhitektuurilisi otsuseid tehti ja miks? Uurime sellest artiklite sarjast.
2016. aasta esimesed probleemid: miks peaksid teenused monoliidist lahkuma
Tsükli esimesed artiklid räägivad teenustest, mis esimesena monoliidist eraldusid. Konteksti asetamiseks räägin teile, millised probleemid meil 2016. aasta alguseks süsteemis olid, et pidime tegelema teenuste eraldamisega.
Üks MySql andmebaas, kuhu kõik Dodo IS-is sel ajal eksisteerinud rakendused oma kirjed kirjutasid. Tagajärjed olid:
- Suur koormus (85% päringutest moodustas lugemise).
- Alus on kasvanud. Seetõttu muutusid selle maksumus ja tugi probleemiks.
- Üks ebaõnnestumise punkt. Kui üks andmebaasi kirjutav rakendus hakkas seda järsku aktiivsemalt tegema, siis teised rakendused tundsid seda enda peal.
- Ebaefektiivsus salvestuses ja päringutes. Sageli salvestati andmeid mõnes struktuuris, mis oli mõne stsenaariumi jaoks mugav, kuid ei sobinud teiste jaoks. Indeksid kiirendavad mõnda toimingut, kuid võivad aeglustada teisi.
- Mõned probleemid eemaldati kiiruga tehtud vahemälude ja baaside lugemise-koopiate abil (see tuleb eraldi artikkel), kuid need võimaldasid neil ainult aega võita ega lahendanud probleemi põhimõtteliselt.
Probleemiks oli monoliidi enda olemasolu. Tagajärjed olid:
- Üksikud ja haruldased väljaanded.
- Raskused suure hulga inimeste ühisel arendamisel.
- Suutmatus tuua sisse uusi tehnoloogiaid, uusi raamistikke ja teeke.
Probleeme aluse ja monoliidiga on korduvalt kirjeldatud, näiteks 2018. aasta alguses toimunud avariide kontekstis (, и ), nii et ma ei peatu liiga palju. Ütlen vaid, et soovisime teenuste arendamisel anda rohkem paindlikkust. Esiteks puudutas see neid, mis olid kogu süsteemis kõige rohkem laaditud ja juurutatud - Auth ja Tracker.
Tagakontori tee: eraldi baasid ja buss
Peatükk Navigeerimine
Monoliitskeem 2016
Siin on Dodo IS 2016 monoliidi peamised plokid ja allpool on nende peamiste ülesannete ärakiri.
Kassa kohaletoimetamine. Kullerite raamatupidamine, kulleritele tellimuste väljastamine.
Kontaktkeskus. Tellimuste vastuvõtmine operaatori kaudu.
Saidi. Meie veebisaidid (dodopizza.ru, dodopizza.co.uk, dodopizza.by jne).
Auth. Autoriseerimis- ja autentimisteenus tagakontori jaoks.
Jälgija. Köögis tellimuste jälgija. Teenus valmisoleku oleku märkimiseks tellimuse koostamisel.
Restorani kassa. Tellimuste vastuvõtmine restoranis, kassa liidesed.
Eksport. Aruannete üleslaadimine 1C-s raamatupidamise jaoks.
Teated ja arved. Köögis häälkäsklused (näiteks “Uus pitsa saabus”) + kulleritele arve trükkimine.
Vahetustehaldur. Liidesed vahetuse juhataja tööks: tellimuste loetelu, töötulemuste graafikud, töötajate vahetusse üleviimine.
Kontori juhataja. Liidesed frantsiisivõtja ja juhi tööks: töötajate vastuvõtt, pizzeria töö aruanded.
Restorani tulemustabel. Menüü kuvamine telerites pizzeriates.
admin. Seaded konkreetses pitsabaaris: menüü, hinnad, raamatupidamine, sooduskoodid, kampaaniad, veebisaidi bännerid jne.
Töötaja isiklik konto. Töötajate töögraafikud, info töötajate kohta.
Köögi motivatsiooninõukogu. Eraldi ekraan, mis ripub köögis ja kuvab pitsategijate kiirust.
KOMMUNIKATSIOON. Saadan sms ja meili.
FileStorage. Oma teenus staatiliste failide vastuvõtmiseks ja väljastamiseks.
Esimesed katsed probleeme lahendada aitasid meid, kuid need olid vaid ajutine hingetõmbeaeg. Süsteemseid lahendusi neist ei saanud, seega oli selge, et alustega tuleb midagi ette võtta. Näiteks üldandmebaasi jagamiseks mitmeks spetsialiseeritud andmebaasiks.
Monoliidi mahalaadimise alustamine: autentimise ja jälgija eraldamine
Peamised teenused, mis seejärel salvestasid ja lugesid andmebaasist rohkem kui teised:
- Aut. Autoriseerimis- ja autentimisteenus tagakontori jaoks.
- Jälgija. Köögis tellimuste jälgija. Teenus valmisoleku oleku märkimiseks tellimuse koostamisel.
Mida Auth teeb?
Auth on teenus, mille kaudu kasutajad logivad sisse tagakontorisse (kliendi poolel on eraldi iseseisev sissepääs). Samuti palutakse päringus veenduda, et vajalikud juurdepääsuõigused on olemas ja et need õigused pole pärast viimast sisselogimist muutunud. Selle kaudu sisenevad seadmed pizzeriasse.
Näiteks tahame esikus rippuval teleril avada kuva valmis tellimuste olekutega. Seejärel avame auth.dodopizza.ru, valime "Logi sisse seadmena", ilmub kood, mille saab sisestada vahetusehalduri arvuti spetsiaalsele lehele, mis näitab seadme (seadme) tüüpi. Teler lülitub ise oma pitsabaari soovitud liidesele ja hakkab kuvama klientide nimesid, kelle tellimused on seal valmis.
Kust koormused tulevad?
Iga back office'i sisse loginud kasutaja läheb iga päringu jaoks andmebaasi, kasutajate tabelisse, tõmbab kasutaja sql-päringu kaudu välja ja kontrollib, kas tal on sellele lehele vajalik juurdepääs ja õigused.
Iga seade teeb sama ainult seadmete tabeliga, kontrollides oma rolli ja juurdepääsu. Suur hulk põhiandmebaasi päringuid põhjustab selle laadimise ja ühise andmebaasi ressursside raiskamise nende toimingute jaoks.
Aut. mahalaadimine
Authil on isoleeritud domeen, st andmed kasutajate, sisselogimiste või seadmete kohta sisenevad teenusesse (praegu) ja jäävad sinna. Kui kellelgi neid vaja läheb, läheb ta andmete saamiseks sellesse teenusesse.
OLI. Algne tööskeem oli järgmine:
Tahaksin veidi selgitada, kuidas see toimis:
- Väljastpoolt päring tuleb taustaprogrammi (seal on Asp.Net MVC), toob endaga kaasa seansiküpsise, mida kasutatakse Redis(1) seansiandmete hankimiseks. See sisaldab teavet juurdepääsude kohta ja seejärel on juurdepääs kontrollerile avatud (3,4, XNUMX) või mitte.
- Kui juurdepääsu pole, peate läbima autoriseerimisprotseduuri. Siin näidatakse seda lihtsuse huvides samas atribuudis oleva tee osana, kuigi see on üleminek sisselogimislehele. Positiivse stsenaariumi korral saame korrektselt lõpetatud seansi ja läheme Backoffice'i kontrollerisse.
- Kui andmeid on, siis peate kontrollima nende asjakohasust kasutajabaasis. Kas tema roll on muutunud, kas teda ei tohi nüüd lehele lubada? Sel juhul peate pärast seansi (1) saamist minema otse andmebaasi ja kontrollima kasutaja juurdepääsu autentimisloogikakihi (2) abil. Järgmisena minge sisselogimislehele või juhtseadmesse. Selline lihtne süsteem, aga mitte päris standardne.
- Kui kõik protseduurid on läbitud, jätame kontrollerite ja meetodite loogikast edasi.
Kasutajaandmed eraldatakse kõigist muudest andmetest, neid hoitakse eraldi liikmelisuse tabelis, AuthService'i loogikakihi funktsioonid võivad muutuda api-meetoditeks. Domeenipiirid on üsna selgelt määratletud: kasutajad, nende rollid, juurdepääsuandmed, juurdepääsu andmine ja tühistamine. Kõik näeb välja selline, et saab eraldi hoolduses välja võtta.
SAADA. Nii nad tegid:
Sellel lähenemisviisil on mitmeid probleeme. Näiteks protsessi sees meetodi kutsumine ei ole sama, mis välisteenuse kutsumine http kaudu. Operatsiooni latentsus, töökindlus, hooldatavus, läbipaistvus on täiesti erinevad. Andrei Morevski rääkis sellistest probleemidest oma raportis üksikasjalikumalt. .
Autentimisteenust ja koos sellega ka seadmeteenust kasutatakse tagakontori jaoks ehk tootmises kasutatavate teenuste ja liideste jaoks. Klienditeenuste (nt veebisaidi või mobiilirakenduse) autentimine toimub eraldi ilma autentimist kasutamata. Eraldamine võttis aega umbes aasta ja nüüd tegeleme taas selle teemaga, viies süsteemi üle uutele autentimisteenustele (standardprotokollidega).
Miks lahkuminek nii kaua aega võttis?
Teel oli palju probleeme, mis aeglustasid:
- Tahtsime teisaldada kasutaja-, seadme- ja autentimisandmed riigipõhistest andmebaasidest ühte. Selleks pidime tõlkima kõik tabelid ja kasutuse int identifikaatorist globaalseks UUId identifikaatoriks (töötasin selle koodi hiljuti ümber ja avatud lähtekoodiga projekt ). Kasutajaandmete säilitamisel (kuna tegemist on isikuandmetega) on oma piirangud ja mõne riigi puhul on vaja neid eraldi salvestada. Kuid kasutaja globaalne ID peab olema.
- Paljudes andmebaasi tabelites on audititeave toimingu sooritanud kasutaja kohta. See nõudis järjepidevuse tagamiseks täiendavat mehhanismi.
- Pärast api-teenuste loomist toimus pikk ja järkjärguline üleminekuperiood teisele süsteemile. Ümberlülitamine pidi olema kasutajatele sujuv ja nõudma käsitsitööd.
Seadme registreerimisskeem pizzerias:
Üldarhitektuur pärast autentimis- ja seadmete teenuse ekstraheerimist:
Märkus. 2020. aastaks töötame välja Authi uue versiooni, mis põhineb OAuth 2.0 autoriseerimisstandardil. See standard on üsna keeruline, kuid see on kasulik läbipääsu autentimisteenuse arendamiseks. Artiklis "» püüdsime Aleksei Tšernjajev rääkida standardist võimalikult lihtsalt ja selgelt, et säästate selle õppimisele aega.
Mida Tracker teeb?
Nüüd umbes teisest laaditud teenustest. Jälgija täidab kahte rolli:
- Ühest küljest on selle ülesanne köögis töötajatele näidata, millised tellimused parasjagu töös on, milliseid tooteid tuleb praegu küpsetada.
- Teisalt digitaliseerida kõik protsessid köögis.
Kui tellimuses ilmub uus toode (näiteks pitsa), läheb see Rullimise jälgimisjaama. Selles jaamas on pitsategija, kes võtab vajaliku suurusega kukli ja rullib selle lahti, misjärel märgib jälgimistabletile, et on oma ülesande täitnud ja kannab rullitud taignapõhja järgmisse jaama - “Algatus” .
Seal täidab järgmine pitsategija pitsa, seejärel märgib tahvelarvutile, et on oma ülesande täitnud ja paneb pitsa ahju (see on ka eraldi jaam, mis tuleb tahvelarvutile märkida). Selline süsteem oli Dodos algusest peale ja Dodo ISi eksisteerimise algusest peale. See võimaldab teil kõiki tehinguid täielikult jälgida ja digiteerida. Lisaks soovitab jälgija, kuidas konkreetset toodet valmistada, juhendab igat tüüpi toodet vastavalt selle tootmisskeemidele, salvestab toote optimaalse küpsetusaja ja jälgib kõiki tootega seotud toiminguid.
Nii näeb tahvelarvuti ekraan välja jälgija "Raskatka" jaamas
Kust koormused tulevad?
Igas pitsabaaris on umbes viis jälgijaga tahvelarvutit. 2016. aastal oli meil üle 100 pitsabaari (nüüd juba üle 600). Iga tahvelarvuti teeb iga 10 sekundi järel päringu taustaprogrammi ja kraabib andmed tellimuste tabelist (ühendus kliendiga ja aadressiga), tellimuse koostisest (ühendus tootega ja koguse näitamine), motivatsiooniarvestuse tabelist ( selles jälgitakse pressimise aega). Kui pitsategija klõpsab jälgimisseadmes tootel, värskendatakse kõigi nende tabelite kirjeid. Tellimuste tabel on üldine, sisaldab ka lisasid tellimuse vastuvõtmisel, uuendusi süsteemi muudest osadest ja arvukalt näitu näiteks pizzerias rippuvast telerist, mis näitab klientidele valmis tellimusi.
Koormustega võitlemise perioodil, kui kõik ja kõik oli vahemällu salvestatud ja baasi asünkroonsesse koopiasse üle kantud, läksid need toimingud jälgijaga edasi põhibaasi. Viivitust ei tohiks olla, andmed peaksid olema ajakohased, sünkroonist väljas on vastuvõetamatu.
Samuti ei võimaldanud oma tabelite ja nende peal olevate indeksite puudumine kirjutada täpsemaid nende kasutamiseks kohandatud päringuid. Näiteks võib olla tõhus, kui jälgijal on tellimuste tabelis pizzeria indeks. Pizzeriatellimused eemaldame alati jälgijate andmebaasist. Samas pole tellimuse vastuvõtmisel niivõrd oluline, millisesse pitsabaarsse see satub, vaid olulisem on see, milline klient selle tellimuse tegi. Ja see tähendab, et kliendi indeks on vajalik. Samuti ei pea jälgija salvestama tellimuse tabelisse trükitud kviitungi või tellimusega seotud boonuskampaaniate ID-d. See teave ei paku meie jälgimisteenusele huvi. Ühises monoliitses andmebaasis saaksid tabelid olla ainult kompromiss kõigi kasutajate vahel. See oli üks algsetest probleemidest.
OLI. Algne arhitektuur oli:
Isegi pärast eraldi protsessideks eraldamist jäi suurem osa koodibaasist erinevate teenuste jaoks ühiseks. Kõik, mis oli kontrollerite all, oli üksik ja elas samas hoidlas. Kasutasime ühiseid teenuste meetodeid, hoidlaid, ühist baasi, milles asuvad ühised tabelid.
Trackeri mahalaadimine
Trackeri põhiprobleem on see, et andmeid tuleb erinevate andmebaaside vahel sünkroniseerida. See on ka selle peamine erinevus autentimisteenuse eraldamisest, tellimus ja olek võivad muutuda ning neid tuleks kuvada erinevates teenustes.
Tellimuse võtame vastu Restorani Kassas (see on teenus), see salvestatakse andmebaasi olekus "Aktsepteeritud". Pärast seda peaks ta jõudma jälgija juurde, kus ta muudab oma staatust veel mitu korda: “Köök” asemel “Pakitud”. Samal ajal võivad tellimusega esineda välismõjud kassast või vahetusehalduri liidesest. Esitan tellimuste olekud koos nende kirjeldusega tabelis:
Tellimuse oleku muutmise skeem näeb välja järgmine:
Olekud muutuvad erinevate süsteemide vahel. Ja siin pole jälgija lõplik süsteem, milles andmed on suletud. Oleme näinud mitmeid võimalikke lähenemisviise sellisel juhul partitsioonideks:
- Kontsentreerime kõik tellimistoimingud ühte teenusesse. Meie puhul nõuab see valik tellimusega töötamiseks liiga palju teenindust. Kui selle juures peatuda, saaksime teise monoliidi. Me ei lahendaks probleemi.
- Üks süsteem helistab teisele. Teine variant on juba huvitavam. Kuid sellega on kõneahelad võimalikud (), komponentide ühenduvus on suurem, seda on keerulisem hallata.
- Korraldame üritusi ja iga teenus suhtleb nende sündmuste kaudu teistega. Selle tulemusena valiti kolmas variant, mille kohaselt hakkavad kõik teenused omavahel sündmusi vahetama.
See, et valisime kolmanda variandi, tähendas, et jälgijal oleks oma andmebaas ja iga tellimuse muudatuse kohta saadaks ta sellekohase sündmuse, mille tellivad teised teenused ja mis samuti langeb põhiandmebaasi. Selleks vajasime teenust, mis tagaks sõnumite edastamise teenuste vahel.
Selleks ajaks oli meil RabbitMQ juba virnas, sellest ka lõplik otsus kasutada seda sõnumivahendajana. Diagramm näitab tellimuse üleminekut restorani kassast läbi Trackeri, kus see muudab oma olekut ja selle kuvamist halduri tellimuste liideses. SAADA:
Telli tee samm-sammult
Tellimuse tee algab ühest tellimuse lähteteenusest. Siin on restorani kassapidaja:
- Kassas on tellimus täiesti valmis ja on aeg see trackerisse saata. Sündmus, millele jälgija on tellitud, visatakse.
- Jälgija, võttes enda jaoks tellimuse vastu, salvestab selle oma andmebaasi, tehes sündmuse “Tellimuse vastu võetud Tracker” ja saates selle RMQ-le.
- Ühe tellimuse kohta on ürituse bussiga liitunud juba mitu töötlejat. Meie jaoks on oluline see, mis teeb sünkroniseerimist monoliitse alusega.
- Käitleja võtab vastu sündmuse, valib sealt välja selle jaoks olulised andmed: meie puhul on selleks tellimuse olek "Jälgija poolt vastu võetud" ja uuendab selle tellimuse olemit põhiandmebaasis.
Kui kellelgi on vaja tellimust monoliitsete lauatellimuste hulgast, siis saab seda lugeda ka sealt. Näiteks vahetuste halduri tellimuste liides vajab järgmist:
Kõik teised teenused saavad ka tellida jälgijast sündmusi, et neid enda jaoks kasutada.
Kui tellimus mõne aja pärast tööle võetakse, muutub selle olek esmalt selle andmebaasis (Trackeri andmebaasis) ja seejärel genereeritakse kohe sündmus "OrderIn Progress". See satub ka RMQ-sse, kust see sünkroonitakse monoliitses andmebaasis ja edastatakse teistele teenustele. Teekonnal võib ette tulla erinevaid probleeme, nende kohta saab täpsemalt lugeda Ženja Peškovi raportist .
Lõplik arhitektuur pärast muudatusi Authis ja Trackeris
Vahetulemuse kokkuvõtteks: Algselt tekkis mul mõte Dodo IS süsteemi üheksa-aastane ajalugu ühte artiklisse pakkida. Tahtsin kiiresti ja lihtsalt rääkida evolutsiooni etappidest. Materjali järele istudes sain aga aru, et kõik on palju keerulisem ja huvitavam, kui pealtnäha paistab.
Mõtiskledes sellise materjali kasulikkuse (või selle puudumise) üle, jõudsin järeldusele, et pidev areng on võimatu ilma täisväärtuslike sündmuste annaalide, üksikasjalike tagasivaadete ja oma varasemate otsuste analüüsita.
Loodan, et teile oli kasulik ja huvitav meie tee kohta teada saada. Nüüd olen valiku ees, millist Dodo IS süsteemi osa järgmises artiklis kirjeldada: kirjutada kommentaaridesse või hääletada.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Millise Dodo IS osa kohta soovite järgmises artiklis teada saada?
-
24,1%Varajane monoliit Dodo IS-is (2011-2015)14
-
24,1%Esimesed probleemid ja nende lahendused (2015-2016)14
-
20,7%Kliendipoolne tee: fassaad üle aluse (2016-2017)12
-
36,2%Päris mikroteenuste ajalugu (2018-2019)21
-
44,8%Monoliidi täielik saagimine ja arhitektuuri stabiliseerimine26
-
29,3%Edasistest plaanidest süsteemi arendamiseks17
-
19,0%Ma ei taha Dodo IS11 kohta midagi teada
58 kasutajat hääletas. 6 kasutajat jäi erapooletuks.
Allikas: www.habr.com