🥇Dodo IS arhitektuuri ajalugu: back-office'i tee

Habr muuda maailma. Oleme juba üle aasta pidanud oma blogi. Kusagil pool aastat tagasi saime meilt täiesti loogilise tagasiside Habrilt: "Dodo, te räägite igal pool, et teil on oma süsteem. Mis süsteem see on? Ja miks see on vajalik pitsakettide jaoks?"

Me istusime, mõtlesime ja mõistsime, et teil on õigus. Proovime seletada kõike lihtsasti, kuid tulemus tuleb katkine ja kusagil pole täielikku süsteemi kirjeldust. Nii algas pikk teekond teabe kogumiseks, autorite leidmiseks ja seeria artiklite kirjutamiseks Dodo IS-ist. Hakkame pihta!

Tänud: aitäh, et jagate meiega oma tagasisidet. Tänu sellele oleme lõpuks suutnud süsteemi kirjeldada, koostada tehnoraadi ja peagi avaldame meie protsesside põhjaliku kirjelduse. Ilma teieta istuksime veel 5 aastat.

Artiklite sari "Mis on Dodo IS?" räägib:

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

Tagabüroo tee: eraldi andmebaasid ja buss. (Te olete siin)

Kliendi osa tee: fassaad andmebaasi kohal (2016-2017). (Töös...)

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

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

Autori arvamus kronoloogilisest kirjeldusest
Koran teeme uute töötajate jaoks kohtumise teemal "Süsteemi arhitektuur". Me nimetame seda "Intro to Dodo IS Architecture" ja see on osa uute arendajate onboardimisprotsessist. Rääkides meie arhitektuurist ja selle omadustest, tekkis mul teatud ajalooline lähenemine kirjeldamiseks.

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

Tegelikkus erineb sellest, mis paberil. Mitte kõik, mis on mõeldud, ei toimi. Ja meile on huvitav, kuidas kõik tegelikult välja näeb ja töötab.
Teabe järjestikune esitamine. Sisuliselt võib järgida kronoloogiliselt alates algusest kuni praeguse seisuni.
Lihtsast keeruliseni. See ei ole universaalne, kuid meie puhul just nii on. Lihtsatest lähenemisviisidest liikus arhitektuur keerulisema poole. Sageli lahendati keerulisuse kaudu rakendamise ja stabiilsuse probleeme ning ka kümnete teiste omaduste loetelu mittefunktsionaalsetest nõuetest (siin on hästi räägitud keerukuse vastandamisest teistele nõuetele).

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

2020. aastaks oli see veidi keerulisem ja sai selliseks:

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

Esimesed probleemid 2016. aastal: miks peavad teenused monoliidist lahkuma

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 alguses ning millega me pidime tegelema teenuste jagamisel.

Üks ühine MySql andmebaas, kuhu kõik toona Dodo IS-is eksisteerinud rakendused andmeid kirjutasid. Tagajärjed olid järgmised:

Suurem koormus (85% päringutest oli lugemiseks).
Andmebaas kasvas. Selle tõttu muutusid selle hooldamine ja hind probleemiks.
Üksik rikkepunkt. Kui mõni rakendus, mis andmebaasi andmeid kirjutas, hakkas äkki seda aktiivsemalt tegema, tundsid teised rakendused seda ka.
Ebaefektiivne andmete säilitamine ja päringud. Sageli olid andmed salvestatud mingis struktuuris, mis sobis mõnele stsenaariumile, kuid mitte teistele. Indekseerimine kiirendas ühte tegevust, kuid võis teised aeglustada.
Mõned probleemid lahendasid kiirustades tehtud vahemälud ja read-replikaandmebaasid (sellest kirjutatakse eraldi artiklis), kuid need lahendasid vaid ajutiselt probleemi ega lahendanud seda põhimõtteliselt.

Probleemiks oli monoliidi olemasolu. Tagajärjed olid järgmised:

Üksikud ja harvad väljalasked.
Paljude inimeste koostöö arendamise keerukus.
Uute tehnoloogiate, uute raamistikute ja teekide lisamise võimatust.

Andmebaasi ja monoliidi probleeme on korduvalt käsitletud, näiteks 2018. aasta alguses juhtunud kukkumiste kontekstis (Ole nagu Munk või paar sõna tehnilise võla kohta, Päev, mil Dodo IS peatus. Asünkroonne stsenaarium ja Lugu Dodo linnust, Feniksite sugukonnast. Dodo IS-i suur kukkumine), nii et ei jääks pikalt peatuma. Ütlen vaid, et soovisime teenuste arendamisel suuremat paindlikkust. Eelkõige kehtis see kõige koormatumate ja süsteemi põhielementide — Auth ja Tracker — kohta.

Back-office’i tee: eraldi andmebaasid ja buss

Navigatsioon peatükis

Monoliidi skeem 2016. aastal

Alustame monoliidi koormuse vähendamist: Auth ja Tracker eraldamine

Millega tegeleb Auth

Kust koormus tuleb?

Vähendame Authi koormust

Millega tegeleb Tracker

Kust koormus tuleb?

Vähendame Trackeri koormust

Monoliidi skeem 2016. aastal

Ees on Dodo IS 2016. aasta põhiblokid, ja natuke allpool on nende põhifunktsioonide seletus.

Kohaletoimetamise kassa. Kullerite registreerimine, tellimuste üleandmine kulleritele.
Kontaktikeskus. Tellimuste vastuvõtt operaatori kaudu.
Veebisait. Meie veebisaidid (dodopizza.ru, dodopizza.co.uk, dodopizza.by jne).
Auth. Autoriseerimise ja autentimise teenus back-office jaoks.
Tracker. Tellimuste jälgimine köögis. Teenus tellimuste valmiduse staatuste märkimiseks ettevalmistamise ajal.
Restoranikassa. Tellimuste vastuvõtt restoranis, kassapidaja liidesed.
Export. Aruannete eksport 1C raamatupidamise jaoks.
Teavitused ja saatedokumendid. Häälekäsklused köögis (näiteks „Uus pitsasaatmine“) + saatedokumentide printimine kulleritele.
Vahetuse juht. Liidesed vahetuse juhi tööks: tellimuste nimekiri, tootlikkuse graafikud, töötajate väljakutsumine vahetusse.
Kontori juht. Fransiiside ja juhendajate tööliidesed: töötajate vastuvõtt, pitsarestorani töö aruanded.
Restorani ekraan. Menüü kuvamine restoranide televiisorites.
Adminpaneel. Spetsiifilised seaded konkreetsele pitsarestoranile: menüü, hinnad, arvestus, sooduskoodid, kampaaniad, veebisaidi reklaamid jne.
Töötaja kasutajaruum. Töötajate töö graafikud, töötajate teave.
Köögimotivatsiooni ekraan. Eraldi ekraan, mis ripub köögis ja kuvab pitsameistrite töötamise kiirus.
Suhtlemine. SMS ja emailide saatmine.
FileStorage. Omandatud teenus staatiliste failide vastuvõtmiseks ja andmiseks.

Esimesed katsed probleemide lahendamiseks aitasid meid, kuid olid vaid ajutine hingetõmme. Need ei kujunenud süsteemseteks lahendusteks, seetõttu oli selge, et andmebaasidega tuleb midagi ette võtta. Näiteks jagada üldine andmebaas mitmeks spetsialiseeritud.

Alustame monoliidi koormuse vähendamist: Auth ja Tracker eraldamine

Põhiteenused, mis siis enim andmebaasist andmeid lugesid ja kirjutasid:

Auth. Autoriseerimise ja autentimise teenus back-office jaoks.
Tracker. Tellimuste jälgimine köögis. Teenus tellimuste valmiduse staatuste märkimiseks ettevalmistamise ajal.

Millega tegeleb Auth

Auth on teenus, mille kaudu kasutajad logivad back-office'i (klientide osas eraldi sõltumatu sisselogimine). Samuti pöördutakse selle poole, et veenduda, et olemas on vajalikud juurdepääsud ja et need õigused pole alates viimast sisselogimist muutunud. Just selle kaudu toimub seadmete sisenemine pitsarestoranides.

Näiteks tahame avada elutoa seinal rippuval teleril valmis tellimuste staatuste tabelit. Siis avame auth.dodopizza.ru, valime "Logi sisse seadmena", ilmub kood, mille saab sisestada vahetuse juhataja arvuti spetsiaalsesse lehekülge, märkides seadme tüübi. Teler suundub ise oma pizzeriasse vajaliku liidese juurde ja hakkab seal kuvama klantide nimesid, kelle tellimused on valmis.

Kust koormus tuleb?

Iga sisse logitud kasutaja tagab iga päringu puhul andmebaasi, kasutajate tabelisse, kasutades SQL-päringut, ja tõmbab sealt kasutaja, kontrollides, kas tal on vajalikud õigused ja juurdepääs sellele leheküljele.

Iga seade teeb samu toiminguid ainult seadmete tabeliga, kontrollides oma rolli ja õigusi. Suur hulk päringuid meistrandmebaasi põhjustab selle koormuse ja ressursside kulu ühises andmebaasis nende operatsioonide tõttu.

Vähendame Authi koormust

Auth'il on isoleeritud domeen, st kasutajate, sisse logimiste või seadmete andmed lähevad teenusesse (praegu veel tulevikus) ja jäävad sinna. Kui kellelgi neid vajatakse, siis läheb ta selle teenuse poole andmete saamiseks.

OLI. Tööskeem algselt oli selline:

Tahaksin veidi selgitada, kuidas see töötas:

Päring väljast tuleb tagasi (seal on Asp.Net MVC), tuues endaga kaasa sessiooniküpsise, mida kasutatakse sessiooniteabe saamiseks Redis'ist (1). Sel on kas õiguste teave ja siis on juurdepääs kontrollerisse avatud (3,4), või mitte.
Kui juurdepääsu pole, tuleb läbida autentimise protseduur. Siin on lihtsustamiseks see näidatud sama atribuudina teel, kuigi see on üleminek sisselogimise lehele. Positiivse stsenaariumi korral saame õigesti täidetud sessiooni ja liikumme Backoffice Controller'i.
Kui andmed on olemas, tuleb kontrollida nende ajakohasust kasutajate andmebaasis. Kas tema roll on muutunud, kas teda tuleb nüüd sellele lehele lubamata jätta. Sel juhul peab sessiooni saamise järel (1) minema otse andmebaasi ja kontrollima kasutaja õigusi autentimise loogika kihi (2) abil. Edasi kas sisselogimise lehele või liikuda kontrollerisse. Selline lihtne süsteem, kuid mitte päris standardne.
Kui kõik protseduurid on läbitud, siis laseme edasi kontrollerite ja meetodite loogikas.

Kasutajate andmed on eraldatud kõikidest teistest andmetest, need hoitakse eraldi membership tabelis, AuthService loogikakihi funktsioonid võivad täiesti vabalt muutuda API meetoditeks. Domeeni piirid on üsna selgelt määratletud: kasutajad, nende rollid, juurdepääsuandmed, juurdepääsu väljastamine ja tagasivõtmine. Kõik näeb välja nagu võiksime selle viia eraldi teenusesse.

OLEMAS. Nii ka tehti:

Sellel lähenemisel on mitmeid probleeme. Näiteks, meetodi kutsumine protsessi sees ei ole sama, mis välist teenust HTTP kaudu kutsuda. Latentsus, usaldusväärsus, hooldatavus, operatsiooni läbipaistvus on täiesti erinevad. Üksikasjalikult sellistest probleemidest rääkis Andrei Morevski oma ettekandes „50 varjundit mikroteenustest“.

Autentimise teenust ja seonduvat seadmete teenust kasutatakse back-office'is, st teenuste ja liideste jaoks, mida kasutatakse tootmises. Klientide teenuste (näiteks veebilehe või mobiilirakenduse) autentimine toimub eraldi, kasutamata Auth'i. Eraldamine kestis umbes aasta, ja nüüd tegeleme selle teemaga taas, viies süsteemi üle uutele autentimise teenustele (tavapäraste protokollidega).

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

Soovisime viia kasutajate, seadmete ja autentimise andmed riikide andmebaasidest ühte. Selleks tuli liikuda kõigi tabelite ja int tuvastamise kasutamiselt globaalse ID UUId'ni (oleme hiljuti seda koodi üle töötanud) Roman Bukin „Uuid — suur lugu väikesest struktuurist“ ja open-source projekt Primitives). Kasutajate andmete säilitamisel (arvestades, et tegu on isikuandmetega) on oma piirangud ja teatud riikides tuleb neid hoida eraldi. Kuid kasutaja globaalne identifikaator peab olema.
Paljud tabelid andmebaasis sisaldavad auditi teavet selle kasutaja kohta, kes tegi operatsiooni. See nõudis täiendavat mehhanismi, et tagada järjepidevus.
Pärast API teenuste loomist oli pikk ja järkjärguline üleminekuperiood teisele süsteemile. Üleminekud pidid toimuma kasutajatele sujuvalt ja nõudsid käsitööd.

Seadme registreerimise skeem pizzeria:

Üldine arhitektuur pärast Auth ja Devices teenuste eraldamist:

Märkus. Aastal 2020 töötame uue Auth versiooni kallal, mis põhineb OAuth 2.0 autoriseerimisstandardil. See standard on üsna keeruline, kuid on vajalik lõppautentimisteenuse arendamiseks. Artiklis „Autoriseerimise nüansid: OAuth 2.0 tehnoloogia ülevaade“ on Aleksei Tšernjaev püüdnud standardit esitada võimalikult lihtsalt ja arusaadavalt, et te saaksite aega selle õppimise pealt kokku hoida.

Millega tegeleb Tracker

Nüüd räägime teisest ülekoormatud teenusest. Jälgija täidab kaht erinevat rolli:

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

Kui tellimuses ilmub uus toode (nt pizza), satub see jälgija jaama „Rullimine“. Selles jaamas on pizzameister, kes võtab vajamineva suurusega tükikese ja rullib selle lahti, seejärel märgib ta jälgija tahvlil, et on oma ülesande täitnud, ja edastab rullitud põhjuse järgmisse jaama - „Täiendamine“.

Seal täidab järgmine pizzameister pitsa, seejärel märgib ta jälgija tahvlil, et on oma ülesande täitnud ja paneb pitsa ahju (see on samuti eraldi jaam, mille tuleb tahvlil märkida). Selline süsteem oli algusest peale Dodo's ja Dodo IS-i esialgsest olemisest peale. See võimaldab täielikult jälgida ja digitaliseerida kõiki operatsioone. Lisaks annab jälgija näpunäiteid, kuidas valmistada erinevaid tooteid, viib iga toote oma valmistamisprotseduuride järgi, talletab toote optimaalse küpsetamise aja ja jälgib kõiki operatsioone toote üle.

Nii näeb jälgija „Rullimine“ jaamas tahvli ekraan välja

Kust koormus tuleb?

Igas pizzakettis on umbes viis tahvelarvutit, mis on varustatud jälgijatega. 2016. aastal oli meil üle 100 pizzeria (ja nüüd üle 600). Iga tahvelarvuti teeb igal 10 sekundi järel päringu tagaplaanile ja tõmbab andmeid tellimuste tabelist (seos kliendi ja aadressiga), tellimuse koostisest (seos toote ja koguse näiduga), motiveerimise arvestuse tabelist (kus jälgitakse vajutamise aega). Kui pizzameister aktiveerib toote jälgijal, värskendatakse kirjeid kõigis nendes tabelites. Tellimuste tabel on ühine ja sinna tehakse samal ajal sisestusi tellimuse vastuvõtmisel, süsteemi teistest osadest uuendusi ja rohkelt lugemisi, näiteks telekas, mis on pizzarias ja näitab valmis tellimusi klientidele.

Koormustega võitlemise ajal, kui kõik mida ainult sai vahemälus hoida ja viia asynchronous replika andmebaasi, jätkasid need toimingud jälgijaga peandmebaasi suunamist. Siin ei peaks olema mingit viivitust, andmed peavad olema ajakohased, desünkroniseerimine on lubamatu.

Samuti ei võimaldanud omade tabelite ja indeksite puudumine kirjutada spetsiifilisemaid päringuid, mis oleksid kohandatud meie kasutamiseks. Näiteks peab jälgijatel olema efektiivne indeks pizzeria tellimuste tabelis. Me tõmbame alati jälgijast tellimusi pizzeria kaupa. Tellimuse vastuvõtmisel ei ole tähtis, millisesse pizzarisse see langeb, oluline on, milline klient selle tellimuse tegi. Seega peab seal olema indeks kliendi järgi. Samuti pole jälgijale tellimuste tabelis vajalik salvestada printimise tšeki id-d või seotud tellimuse boonuspakkumisi. See teave ei huvita meie jälgimisteenust. Ühises monoliitses andmebaasis võisid tabelid olla ainult kõigi kasutajate vahel lepitavate kompromisside variant. See oli üks algseid probleeme.

OLI. Algne arhitektuur oli selline:

Isegi pärast eraldamist eraldi protsessidesse jäi enamik koodibaasist erinevate teenuste jaoks ühine. Kõik, mis oli kontrolleritest madalamal, oli ühtne ja elas ühes hoidlas. Kasutati ühiseid teenuse meetodeid, hoidlaid, ühist andmebaasi, kus olid ühised tabelid.

Vähendame Trackeri koormust

Peamine probleem jälgijas seisneb selles, et andmed peavad olema sünkroniseeritud erinevate andmebaaside vahel. See on ka peamine erinevus autoriseerimisteenuse jagamisest, kus tellimus ja selle staatus võivad muutuda ja peavad olema nähtavad erinevates teenustes.

Me aktsepteerime tellimusi Restorani Kassas (see on teenus), see salvestatakse andmebaasi staatusega „Vastu võetud“. Pärast seda peab see jõudma jälgijasse, kus see muudab oma staatust veel mitu korda: alates „Köök“ kuni „Pakitud“. Sel ajal võivad tellimusele avaldada mingit välismõju Kassas või vahetuse juhtimise liideses. Esitan tellimuse staatuste ja nende kirjelduste tabelis:

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

Staatused muutuvad erinevate süsteemide vahel. Ja siin ei ole jälgija lõpp-süsteem, kus andmed suletakse. Oleme näinud mitu võimalikku lähenemist eraldamiseks sellisel juhul:

Keskendame kõik tellimuse toimingud ühes teenuses. Meie puhul nõuab see variant tellimuse haldamiseks liiga suurt teenust. Kui me oleksime sellega piirdunud, oleksime saanud teise monoliidi. Probleeme me ei lahendanud.
Üks süsteem kutsub teist. Teine variant on juba huvitavam. Kuid selle puhul on võimalikud kutsumise ahelad (kaskaadsed tõrked), komponentide seotuse tase on kõrgem, seda on raskem hallata.
Korraldame sündmused ja iga teenus vahetab nende sündmuste kaudu teavet üksteisega. Lõppkokkuvõttes valiti tõepoolest kolmas variant, mille kohaselt kõik teenused hakkavad omavahel sündmusi vahetama.

See, et valisime kolmanda variandi, tähendas, et jälgijal on oma andmebaas ja iga tellimuse muutuse korral saadab ta sellest sündmuse, millele teised teenused liituvad ja mis jõuab ka põhivaramusse. Selleks oli meil vaja mingit teenust, mis tagaks sõnumite edastamise teenuste vahel.

Sel ajal oli meil stacks juba RabbitMQ, seega otsustasime kasutada seda sõnumite vahendajana. Skeemil on näidatud tellimuse liikumine Restorani Kassast läbi Jälgija, kus see muudab oma staatusi ja kuvatakse juhi Tellimustes. MUUTUS:

Tellimuse teekond samm-sammult
Tellimuse teekond algab ühes tellimuse allikasüsteemis. Siin on see Restorani Kassas:

Kassas on tellimus täielikult valmis ja on aeg see jälgimisse saata. Üritus, millele jälgija on registreeritud, käivitatakse.
Jälgija, vastu võttes tellimust, salvestab selle oma andmebaasi, tehes sellega ürituse „TellimusVastuvõetudJälgija“ ja saates selle RMQ-sse.
Tellimuse üritusel on juba mitu töötlejat registreeritud. Meile on oluline see, mis teeb sünkroonimise monoliitsete andmetega.
Töötleja võtab ürituse vastu, valib sellest endast olulised andmed: meie puhul tellimuse staatus „VastuvõetudJälgija“ ja uuendab oma tellimuse entiteeti põhivaatlemise andmebaasis.

Kui kellelgi on vaja tellimust just monoliitsest orders tabelist, siis saab seda sealt lugeda. Näiteks on see vajalik tellimuste liidese jaoks Vahetuse Halduris:

Kõik teised teenused saavad samuti tellimuse üritustele jälgijast registreeruda, et neid enda jaoks kasutada.

Kui tellimus võetakse mõne aja pärast tööle, siis muudab selle staatus esmalt oma andmebaasis (Jälgija andmebaasis) ja siis genereeritakse kohe üritus „TellimusTöös“. See jõuab samuti RMQ-sse, kust sünkroonitakse monoliitsesse andmebaasi ja edastatakse teistele teenustele. Sellel teel võivad esineda erinevad probleemid, millega saab tutvuda Ženja Peškovi ettekandes. detailide rakendamise kohta Eventual Consistency Jälgijas.

Lõplik arhitektuur pärast muudatusi Authis ja Jälgijas

Kokkuvõtlikult: alguses soovisin kokku panna ühe artikli Dodo IS süsteemi üheksa-aastasest ajaloost. Olin taheline kiiresti ja lihtsalt rääkida evolutsiooni etappidest. Kuid materjali kirjutades mõistsin, et kõik on palju keerulisem ja huvitavam, kui tundub.

Mõeldes selle materjali kasule (või puudumisele), jõudsin järeldusele, et pidev areng ei ole võimalik ilma põhjalike sündmuste kroonikuteta, ulatuslike retrospektiivide ja oma varasemate otsuste analüüsita.

Loodan, et teile oli kasulik ja huvitav tutvuda meie teekonnaga. Praegu olen silmitsi valikuga, millise osa Dodo IS-st järgmises artiklis kirja panna: kirjutage kommentaarides või hääletage.

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