🥇Dodo IS arhitektuuri ajalugu: back-office tee

Habrahabr muudab maailma. Oleme pidanud oma blogi üle aasta. Kusagil pool aastat tagasi saime Habra külastajate käest üsna loogilist tagasisidet: „Dodo, te räägite igal pool, et teil on oma süsteem. Mis see süsteem on? Ja milleks on see vajalik pizzakettidele?”

Mõtlesime natuke ja mõistsime, et teil on õigus. Proovime kõike selgitada lihtsal viisil, kuid see tuleb katkendlikult ja kustki ei leia täielikku süsteemi kirjeldust. Nii algas pikk teekond teabe kogumise, autorite otsimise ja Dodo IS-i seeria artiklite kirjutamise suunas. Alustame!

Aitäh: tänu teile, et jagate meiega oma tagasisidet. Tänu sellele oleme lõpuks süsteemi kirjeldanud, koostanud tehnoradarit ja peagi avaldame põhjaliku ülevaate meie protsessidest. Ilma teieta istuksime veel 5 aastat.

Artiklite seeria „Mis on Dodo IS?” räägib:

Varajane monoliit Dodo IS-is (2011-2015). (Töös…)

Tagakontori tee: eraldi andmebaasid ja buss. (Olete siin)

Kliendiosakonna tee: fassaad andmebaasi kohal (2016-2017). (Töös…)

Tõeliste mikroteenuste ajalugu. (2018-2019). (Töös…)

Monoliidi lõplik jagamine ja arhitektuuri stabiliseerimine. (Töös…)
Kui soovite veel midagi teada, kirjutage kommentaaridesse.

Autorilt ajaloost põhinev arvamus
Korraldan regulaarselt uutest töötajatest koosolekuid teemal "Süsteemi arhitektuur". Meie juures nimetatakse seda "Intro to Dodo IS Architecture" ning see on osa uute arendajate onboarding-protsessist. Rääkides meie arhitektuurist ja selle omadustest, tekkis mul ajalooline lähenemine selle kirjeldamiseks.

Tavaliselt vaatame süsteemi kui komponentide (tehniliste või kõrgema taseme) kogumit, ärimooduleid, mis omavahel sümbioosis töötavad mingi eesmärgi nimel. Ja kuigi selline lähenemine on projekteerimise jaoks õigustatud, ei sobi see kirjeldamiseks ja mõistmiseks. Siin on mitu põhjust:

Reaalsus erineb sellest, mis on paberil. Mitte kõik, mida plaanitakse, ei teostu. Ja meid huvitab, kuidas asjad tegelikult välja kukkusid ja töötavad.
Informatsiooni järjestikune esitlemine. Üldiselt võiks liikuda kronoloogiliselt algusest praeguse seisundini.
Lihtsalt keeruliseks. See ei ole universaalne, kuid meie puhul on see just nii. Ahnemad lähenemised arhitektuuris liikusid keerulisematele. Tihti saadi keerukamaid lahendusi rakendamise kiirus- ja stabiilsusprobleemide lahendamiseks, samuti tosin muud omadust, mis on loetletud mittefunktsionaalsetes nõuetes (siit hästi räägitud keerukuse vastandamisest teistele nõuetele).

2011. aastal nägi Dodo IS arhitektuur välja selline:

Kuni 2020. aastani oli see pisut keerulisem ja nägi välja selline:

Kuidas see evolutsioon toimus? Miks on süsteemi erinevad osad vajalikud? Milliseid arhitektuurilisi lahendusi ja miks oli valitud? Uurime seda artiklite seerias.

Esimesed probleemid 2016. aastast: miks peavad teenused loobuma monoliidist.

Esimesed artiklid tsüklist käsitlevad teenuseid, mis esimesena monoliidist eraldusid. Et viia teid konteksti, räägin, millised probleemid olid meie süsteemis 2016. aasta alguseks ja millega pidime tegelema teenuste jagamisel.

Üks ühisandmebaas MySql, kuhu kirjutasid oma kirjed kõik rakendused, mis tol hetkel Dodo IS-is eksisteerisid. Tagajärjed olid sellised:

Suurelt koormus (85% päringutest langes lugemisele).
Andmebaas laienes. Selle tõttu muutusid selle hind ja tugi probleemiks.
Üksik rikke punkt. Kui üks rakendus, mis andmebaasi kirjutab, hakkas äkki seda aktiivsemalt tegema, siis teised rakendused tundsid seda endas.
Ebaefektiivne andmete hoidmine ja päringud. Tihti hoiti andmeid sellises struktuuris, mis oli mugav ühe stsenaariumi jaoks, kuid ei sobinud teiste jaoks. Indeksid kiirendasid ühtede toimingute tegemist, kuid võisid aeglustada teisi.
Osaliselt leevendasid probleeme kiired suhted ja read-repliigid andmebaasidele (sellest tuleb eraldi artikkel), kuid nad andsid vaid ajaliselt võitu ja probleemi põhimõtteliselt ei lahendanud.

Probleemiks oli monoliidi eksisteerimine. Tagajärjed olid sellised:

Üksikud ja haruldased väljaanded.
Paljude inimeste koostöö keerukus.
Uute tehnoloogiate, uute raamistike ja raamatukogude juurutamise võimatus.

Probleemid andmebaasi ja monoliidiga on korduvalt ilmnenud, näiteks 2018. aasta alguse languste kontekstis (Ole nagu Munk, või paar sõna tehnilise võla kohta, Päev, mil Dodo IS peatati. Asünkroonne stsenaarium ja Lugu Dodo linnust Fenixi liigist. Suur Dodo IS langus), nii et ei jää kauaks peatuma. Ütleksin vaid, et soovisime arenduses rohkem paindlikkust. Eelkõige kehtib see kõige koormatumate ja juuri ulatuvate teenuste kohta — Auth ja Tracker.

Tagavarahalduri tee: eraldi andmebaasid ja buss.

Jaotise navigeerimine.

2016. aasta monoliidi skeem.

Alustame monoliidi koormuse vähendamist: Authi ja Trackeri eraldamine.

Mida teeb Auth?

Kust koormus tuleb?

Vähendame Authi koormust.

Mida teeb Tracker?

Kust koormus tuleb?

Vähendame Trackeri koormust.

2016. aasta monoliidi skeem.

Teie ees on Dodo IS 2016. aasta monoliidi põhistruktuurid ja allpool nende põhifunktsioonide selgitus.

Kohaletoimetamise kassa. Kullerite haldamine, tellimuste väljastamine kulleritele.
Kontaktikeskus.. Tellimuste vastuvõtmine operaatori kaudu.
Veebileht.. Meie veebilehed (dodopizza.ru, dodopizza.co.uk, dodopizza.by jne).
Auth.. Autoriseerimise ja autentimise teenus tagavarahalduritele.
Tracker.. Tellimuste jälgimise teenus köögis. Valmistamise staatuste märkimise teenus.
Restorani kassa.. Tellimuste vastuvõtmine restoranis, kassapidaja liidesed.
Export. Aruannete eksportimine 1C-sse raamatupidamise tarbeks.
Teavitused ja saatedokumendid.. Häälkäsklused köögis (näiteks „Uus pitsatellimus“) + saatedokumentide printimine kulleritele.
Vahetuse juht. Vahetuse halduri tööliidesed: tellimuste nimekiri, tulemusgraafikud, töötajate vahetuse väljastamine.
Kontori juht. Frantsiisi ja juhataja tööliidesed: töötajate vastuvõtmine, pitsarestorani töö raportid.
Restorani ekraan. Menüü kuvamine pitsarestoranide televiisorites.
Admin-paneel. Seaded konkreetse pitsarestorani jaoks: menüü, hinnad, arvestus, sooduskoodid, kampaaniad, veebibännerid jne.
Töötaja isiklik kabinet. Töötajate töögraafikud, teave töötajate kohta.
Köögi motiveerimise ekraan. Eraldiseisev ekraan, mis rippub köögis ja näitab pitsameistrite töö kiirus.
Kommunikatsioon. SMS-i ja e-kirjade saatmine.
FileStorage. Omanikuteenuse jaoks staatiliste failide vastuvõtu ja väljastamise teenus.

Esimesed katsed probleemide lahendamiseks aitasid meid, kuid olid vaid ajutised peatükid. Need ei saanud süsteemseteks lahendusteks, seega oli selge, et andmebaasidega on midagi ette võtta. Näiteks jagada üldine andmebaas mitmeks spetsialiseeritumaks.

Alustame monoliidi koormuse vähendamist: Authi ja Trackeri eraldamine.

Peamised teenused, mis tol ajal rohkem registreerisid ja lugesid andmebaasist:

Auth. Autentimise ja autentimise teenus tagakontoris.
Tracker. Tellimuste jälgija köögis. Teenus, mis märgib valmistamise staatuseid tellimuste valmisoleku kohta.

Mida teeb Auth?

Auth — see on teenus, mille kaudu kasutajad logivad sisse tagakontorisse (klientide osas on eraldi iseseisev sisenemine). Samuti pöördutakse selle poole, et veenduda, et sobivad õigused on olemas ja et need õigused ei ole viimase sisenemisega muutunud. Just selle kaudu siseneb seadmed pitsarestoranidesse.

Näiteks tahame avada teleris, mis on saalis, ekraani valmis tellimuste staatustega. Seetõttu avame auth.dodopizza.ru, valime "Sisenemine seadmena", kuvatakse kood, mille saab sisestada vahetusjuhi arvuti spetsiaalsesse lehte, märkides seadme tüübi. Teler liigub automaatselt oma pitsarestorani vajaliku liidese juurde ja hakkab seal kuvama klientide nimesid, kelle tellimused on valminud.

Kust koormus tuleb?

Iga sisse loginud kasutaja tagakontoris teeb iga päringu korral otsingu andmebaasi, kasutajate tabelisse, tõmbab sealt sql-päringuga kasutaja ja kontrollib, kas tal on vajalikud õigused ja juurdepääs sellele lehele.

Iga seade teeb sama, vaid seadmete tabeliga, kontrollides oma rolli ja õigusi. Suur hulk päringutest meesteribi andmebaasi toob kaasa selle suure koormuse ja ressursside raiskamise üldisele andmebaasile nende toimingute jaoks.

Vähendame Authi koormust.

Authil on isoleeritud domeen, mis tähendab, et andmed kasutajate, sisselogimiste või seadmete kohta tulevad teenusesse (hetkel tuleviku teenus) ja jäävad sinna. Kui need kellelegi vajalikud on, läheb ta nende andmete saamiseks sellesse teenusesse.

OLI. Töö scheem kujunes algselt selliseks:

Tahaksin veidi selgitada, kuidas see töötas:

Päring väljastpoolt jõuab tagasi (seal on Asp.Net MVC), toomine endaga sessiooni küpsise, mida kasutatakse sessiooniandmete saamiseks Redisest (1). See sisaldab kas ligipääsu teavet, siis juurdepääs kontrollerisse on avatud (3,4), või ei ole.
Kui ligipääsu ei ole, tuleb läbida autentimisprotseduur. Siin on see lihtsuse huvides näidatud kui osa teest samas atribuudis, kuigi see on üleminek sisselogimise lehele. Positiivse stsenaariumi korral saame õigesti täidetud sessiooni ja liigume Backoffice Controllerisse.
Kui andmed on olemas, tuleb need kontrollida kasutaja andmebaasis. Kas tema roll on muutunud, kas teda ei tohi nüüd lehele lubada. Sel juhul tuleb sessiooni saamisel (1) otse andmebaasi minna ja kontrollida kasutaja õigusi autentimise loogika kihiga (2). Edasi kas logimislehele või suunduda kontrollerisse. Selline lihtne süsteem, kuid mitte täiesti tavaline.
Kui kõik protseduurid on läbitud, siis jätkame edasi loogikas kontrollerites ja meetodites.

Kasutaja andmed on eraldatud kõikidest teistest andmetest, need hoitakse eraldi membership tabelis, AuthService loogika kihist pärinevaid funktsioone võib täiesti kasutada API meetoditena. Domeeni piirid on üsna selgelt määratletud: kasutajad, nende rollid, ligipääsuandmed, ligipääsude väljastamine ja tühistamine. Kõik näeb välja nii, et selle saab viia eraldi teenusesse.

ON TÖÖDAS. Nii ka tegime:

Selle lähenemisviisi puhul on mitmeid probleeme. Näiteks meetodi kutsumine protsessi sees ei ole sama, mis välise teenuse kutsumine http kaudu. Latentsus, usaldusväärsus, hooldatavus ja operatsiooni läbipaistvus on täielikult erinevad. Rohkem nende probleemide kohta rääkis Andrei Morevski oma ettekandes. „50 varjundit mikroteenuseid“.

Autentimis teenus ja seadmete teenus kasutatakse tagakontoris, st teenustes ja liidestes, mida kasutatakse tootmises. Klientide teenuste (nt veebisaidi või mobiilirakenduse) autentimine toimub eraldi ilma Auth'i kasutamata. Eraldamine võttis aega umbes aasta, ja nüüd tegeleme taas selle teemaga, viies süsteemi üle uutele autentimis teenustele (standardsete protokollide alusel).

Miks eraldamine kestis nii kaua?
Teel oli palju probleeme, mis aeglustasid:

Soovisime viia kasutajate, seadmete ja autentimise andmed riigi andmebaasid üheks. Selleks tuli kõik tabelid üle viia ning ID int kasutada globaalse ID UUId (olenud hiljuti selle koodi ümber töötanud). Roman Bukin «Uuid — suur lugu väikese struktuuri kohta» ja avatud lähtekoodiga projekt Primitives). Kasutajate andmete salvestamine (kuna see on isiklik teave) on oma piirangutega ja mõnes riigis tuleb neid eraldi hoida. Kuid globaalse kasutaja identifikaator peab olema.
Paljusid andmebaasi tabeleid jälgib teavet selle kasutaja kohta, kes operatsiooni sooritas. See nõudis täiendavat mehhanismi, et tagada järjepidevus.
Pärast api-teenuste loomist oli pikk ja järk-järguline periood üleviimiseks teisele süsteemile. Üleminekud pidid toimuma sujuvalt kasutajatele ja nõudsid käsitsi tööd.

Seadmise registreerimise skeem pitsarestoranis:

Üldine arhitektuur pärast Auth ja Devices-teenuse eraldamist:

Märkus. 2020. aastaks töötame uue Auth versiooni kallal, mis põhineb OAuth 2.0 autoriseerimise standardil. See standard on üsna keeruline, kuid on kasulik lõpuauditeerimise teenuse arendamisel. Artiklis «Autoriseerimise nüansid: OAuth 2.0 tehnoloogia ülevaade» on Aleksei Cherniaev püüdnud rääkida standardist võimalikult lihtsalt ja selgelt, et te saaksite õppimisele aega säästa.

Mida teeb Tracker?

Räägime nüüd teisest koormatäiest teenusest. Jälgija täidab kaht vastastikku seotud rolli:

Esiteks, selle ülesanne on näidata köögitöötajatele, millised tellimused on hetkel töös, milliseid tooteid tuleb praegu valmistada.
Teiseks — digitaliseerida kõik köögis toimuvad protsessid.

Kui tellimusesse lisatakse uus toode (näiteks pitsat), jõuab see jälgija jaama „Rullimine“. Sellel jaamal töötab pitsameister, kes võtab sobiva suurusega taina ja rullib selle lahti, seejärel märgib ta jälgija tahvelarvutis, et on oma ülesande täitnud, ja edastab rullitud taigna aluse järgmisse jaama — „Täidise valmistamine“.

Siin järgmine pitsameister täidab pitsat, seejärel märgib tahvelarvutisse, et ta on oma ülesande täitnud ja paneb pitsa ahju (see on samuti eraldi jaama, mille tuleb tahvelarvutisse märkida). Selline süsteem oli algusest peale Dodo ja Dodo IS olemas. See võimaldab täielikult jälgida ja digiteerida kõiki operatsioone. Lisaks annab jälgija juhiseid, kuidas valmistada seda või seda toodet, viib iga toote läbi oma valmistamisskeemide, säilitab toote optimaalse küpsetamisaja ja jälgib kõiki toiminguid toote üle.

Nii näeb välja tahvelarvuti ekraan jälgija "Rullimine" jaamas

Kust koormus tuleb?

Igas pitsarestoranis on umbes viis tahvelarvutit jälgimisega. 2016. aastal oli meil üle 100 pitsarestorani (nüüdseks aga enam kui 600). Iga tahvelarvuti saadab iga 10 sekundi järel päringu tagaplaanile ja kogub andmeid tellimuste tabelist (seotud kliendi ja aadressiga), tellimuse koostisosadest (seotud tootega ja koguse määramine) ning motivatsiooni tabelist (kus jälgitakse vajutamise aega). Kui pitsamees vajutab jälgimisrakenduses tootele, uuendatakse kõiki neid tabeleid. Tellimuste tabel on ühine, sinna tehakse samal ajal sissekandeid tellimuste vastuvõtmisel, uuendusi süsteemi teistest osadest ja arvukalt lugemisi, näiteks televisioonis, mis ripub pitsarestoranis ja näitab kliente valmislidordersid.

Koormuste vastu võitlemise perioodil, mil kõik ja kõike vahemäluti ja muudeti asünkroonseks andmebaasi kopeerimiseks, jätkasid need operatsioonid jälgijaga varem peaandmebaasi. Siin ei tohiks olla mingit viivitust, andmed peavad olema ajakohased, sünkroonsus on hädavajalik.

Samuti ei võimaldanud oma tabelite ja indeksite puudumine kirjutada spetsiifilisemaid päringuid, mis vastavad meie kasutusele. Näiteks võiks jälgijale olla tõhus omada indeksit pizzeriate kohta tellimuste tabelis. Me tõmbame alati jälgijast välja tellimused pizzeriate kohta. Samas pole tellimuse vastuvõtmisel oluline, millisesse pizzeriisse see langeb, olulisem on, milline klient selle tellimuse tegi. Seega on seal vajalik indeks kliendi järgi. Jälgijale ei ole ka tellimuse tabelis vajalik hoida trükitud tšeki ID-d või tellimusega seotud boonuspakkumisi. See teave ei huvitata meie jälgimisteenust. Üldises monoliitses andmebaasis võisid tabelid olla vaid kõikide kasutajate vahelise kompromissi variandiks. See oli üks algseid probleeme.

OLI. Alguses oli arhitektuur selline:

Isegi pärast eraldamist eraldi protsessides jäi enamik koodibaasist erinevatele teenustele ühiseks. Kõik, mis on allpool kontrolleritest, oli ühine ja elas ühes hoidlas. Kasutati ühiseid meetodeid teenustest, hoidlatest, ühine andmebaas, kus asusid ühised tabelid.

Vähendame Trackeri koormust.

Peamine probleem jälgimise süsteemis on see, et andmed peavad sünkroniseerima erinevate andmebaaside vahel. See on ka selle peamine erinevus Auth-teenuse eraldamisest, kui tellimus ja selle staatus võivad muutuda ning peavad olema erinevates teenustes nähtavad.

Me võtame tellimuse vastu Restoranikassas (see on teenus), see salvestatakse andmebaasi seisundis „Võetud”. Pärast seda peab see sattuma jälgimise süsteemi, kus selle staatus muutub veel mitu korda: „Köök” kuni „Pakitud”. Sellega seoses võivad tellimuse osas toimuda mõned välised mõjutused Kassast või Vahetusjuhi interfatsioonist. Toome tabelis välja tellimuse staatuste kirjeldused:

Tellimuse staatuste muutmise skeem näeb välja järgmiselt:

Staatused muutuvad erinevate süsteemide vahel. Ja siin pole jälgija lõpp-süsteem, kus andmed kogunevad. Oleme näinud mitmeid võimalikke lähenemisviise eraldamiseks sellistel juhtudel:

Koonde kõik tellimuse toimingud ühte teenusesse. Meie juhul nõuab see variant liiga suurt teenust tellimuse töötlemiseks. Kui me sellele jääksime, siis saaksime teise monoliidi. Probleeme me ei lahendaks.
Üks süsteem teeb kutsungi teisele. Teine variant on juba huvitavam. Ent selle puhul võivad esineda korduvad kutsed (kaskaadvead), komponentide sidusus on suurem, hallata seda on keerulisem.
Korrigeerime sündmusi, ja iga teenus vahetab nende kaudu teavet teiste teenustega. Lõpuks valiti just kolmas variant, milles kõik teenused hakkavad omavahel sündmusi vahetama.

See, et me valisime kolmanda variandi, tähendas, et jälgijal on oma andmebaas ja iga tellimuse muudatuse korral saadab ta selle kohta sündmuse, millele registreerivad teised teenused, ja mis jõuab ka põhivaramusse. Selleks vajasime mingit teenust, mis tagaks sõnumite edastamise teenuste vahel.

Sel ajal oli meil juba tehnoloogias RabbitMQ, sealt ka lõplik otsus kasutada seda sõnumite vahetamiseks. Skeemil on kujutatud tellimuse liikumist Restorani Kassast läbi Jälgija, kus see muudab oma staatuseid ja kuvab seda Halduse tellimustes. SAI:

Tellimuse teekond samm-sammult
Tellimuse teekond algab ühel tellimuste allika teenustest. Siin on see Restorani Kassas:

Kassas on tellimus täielikult valmis, ja on aeg see jälgimisele saata. Toimub sündmus, millele jälgija on registreeritud.
Jälgija, vastu võttes tellimuse, salvestab selle oma andmebaasi, luues samal ajal sündmuse «TellimusVõetudJälgija» ja saadab selle RMQ-sse.
Tellimuse sündmusele on juba registreeritud mitmed töötlejad. Meie jaoks on oluline see, mis teeb sünkroniseerimise monoliitse andmebaasiga.
Töötleja võtab sündmuse vastu, valib sellest enda jaoks olulised andmed: meie puhul tellimuse oleku «VõetudJälgija» ja värskendab oma tellimuse entiteeti põhijärjestuses.

Kui kellelegi on vajalik tellimus just monoliitsest orders tabelist, siis saab selle sealt lugeda. Näiteks on seda vaja Tellimuste liidesele Vahetuse Halduse süsteemis:

Kõik teised teenused saavad samuti registreeruda tellimuse sündmustele jälgijas, et neid enda jaoks kasutada.

Kui tellimus võetakse pärast teatud aega tööle, muutub selle staatus esmalt oma andmebaasis (Tracker'i andmebaasis) ja seejärel genereeritakse kohe sündmus „TELLIMUS_TÖÖS”. See jõuab ka RMQ-sse, kust sünkroniseeritakse monoliitses andmebaasis ja edastatakse teistele teenustele. Sellel teel võivad esineda erinevad probleemid, mille kohta saab rohkem teada Ženja Peškovi ettekandes. detalite teostusest Eventual Consistency Tracker'is.

Lõplik arhitektuur pärast muudatusi Authis ja Trackeris

Kokkuvõtteks: Alguses mõtlesin, et pakin Dodo IS süsteemi üheksa aastat kokku ühte artiklisse. Soovisin kiirelt ja lihtsalt rääkida arenguetappidest. Kuid kui ma materjali kallale asusin, mõistsin, et kõik on palju keerulisem ja huvitavam, kui esmapilgul tundub.

Mõeldes selle materjali kasule (või selle puudumisele), jõudsin järeldusele, et pidev areng pole võimalik ilma täielike sündmuste kroonikateta, laiaulatuslike retrospektiivide ja oma varasemate otsuste analüüsita.

Loodan, et teave meie teekonnast oli teile kasulik ja huvitav. Nüüd seisan silmitsi valikuga, millist Dodo IS süsteemi osa järgmises artiklis kirjeldada: kirjutage kommentaaridesse või hääletage.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.