Habr mení svet. Blogu sa venujeme už vyše roka. Asi pred šiestimi mesiacmi sme od Khabrovites dostali úplne logickú spätnú väzbu: „Dodo, všade hovoríš, že máš vlastný systém. A čo je to za systém? A prečo to reťazec pizze potrebuje?
Sedeli sme, premýšľali a uvedomili sme si, že máte pravdu. Snažíme sa všetko vysvetliť na prstoch, no vychádza to roztrhané a nikde nie je úplný popis systému. Začala sa tak dlhá cesta zbierania informácií, hľadania autorov a písania série článkov o Dodo IS. Poďme!
Poďakovanie: Ďakujeme, že ste sa s nami podelili o spätnú väzbu. Vďaka nemu sme konečne opísali systém, zostavili technický radar a čoskoro spustíme rozsiahly popis našich procesov. Bez vás by sme tam sedeli ďalších 5 rokov.
Séria článkov "Čo je Dodo IS?" hovorí o:
- Raný monolit v Dodo IS (2011-2015). (Prebieha...)
- Cesta back office: samostatné základne a autobus. (ste tu)
- Cesta na strane klienta: fasáda nad základňou (2016-2017). (Prebieha...)
- História skutočných mikroslužieb. (2018-2019). (Prebieha...)
- Hotové pílenie monolitu a stabilizácia architektúry. (Prebieha...)
Ak máte záujem dozvedieť sa niečo iné - napíšte do komentárov.
Názor na chronologický popis od autora
Pravidelne robím stretnutie pre nových zamestnancov na tému „Systémová architektúra“. Nazývame to „Intro to Dodo IS Architecture“ a je súčasťou procesu registrácie pre nových vývojárov. Rozprávať v tej či onej forme o našej architektúre, o jej črtách, som si vrodený určitým historickým prístupom k opisu.
Tradične sa na systém pozeráme ako na súbor komponentov (technických alebo vyšších), obchodných modulov, ktoré sa navzájom ovplyvňujú, aby dosiahli nejaký cieľ. A ak je takýto pohľad opodstatnený pre dizajn, potom nie je celkom vhodný na popis a pochopenie. Dôvodov je tu niekoľko:
- Realita je iná ako na papieri. Nie všetko vychádza podľa predstáv. A nás zaujíma, ako to vlastne dopadlo a funguje.
- Konzistentná prezentácia informácií. V podstate môžete ísť chronologicky od začiatku až po aktuálny stav.
- Od jednoduchých po zložité. Nie univerzálne, ale v našom prípade áno. Architektúra sa posunula od jednoduchších prístupov k zložitejším. Často cez komplikácie boli vyriešené problémy s rýchlosťou a stabilitou implementácie, ako aj desiatky ďalších vlastností zo zoznamu nefunkčných požiadaviek ( dobre povedané o kontraste zložitosti s inými požiadavkami).
V roku 2011 vyzerala architektúra Dodo IS takto:
Do roku 2020 sa to trochu skomplikovalo a stalo sa takto:
Ako k tejto evolúcii došlo? Prečo sú potrebné rôzne časti systému? Aké architektonické rozhodnutia boli prijaté a prečo? Dozvieme sa v tejto sérii článkov.
Prvé problémy roku 2016: prečo by služby mali opustiť monolit
Prvé články z cyklu budú o službách, ktoré sa ako prvé oddelili od monolitu. Aby som vás uviedol do súvislostí, poviem vám, aké problémy sme mali v systéme do začiatku roka 2016, že sme sa museli vysporiadať s oddelením služieb.
Jedna MySql databáza, do ktorej si zapisovali svoje záznamy všetky aplikácie, ktoré v tom čase existovali v Dodo IS. Následky boli:
- Veľké zaťaženie (85 % žiadostí predstavovalo čítanie).
- Základňa sa rozrástla. Z tohto dôvodu sa jej náklady a podpora stali problémom.
- Jediný bod zlyhania. Ak to zrazu začala aktívnejšie robiť jedna aplikácia zapisujúca do databázy, tak to na sebe pocítili ostatné aplikácie.
- Neefektívnosť pri skladovaní a dopytoch. Údaje boli často uložené v nejakej štruktúre, ktorá bola vhodná pre niektoré scenáre, ale nevhodná pre iné. Indexy urýchľujú niektoré operácie, no iné môžu spomaliť.
- Niektoré problémy odstránili narýchlo urobené kešky a read-repliky do základní (to bude na samostatný článok), ale umožnili im len získať čas a problém zásadne nevyriešili.
Problémom bola prítomnosť samotného monolitu. Následky boli:
- Jednotlivé a vzácne vydania.
- Ťažkosti so spoločným vývojom veľkého počtu ľudí.
- Neschopnosť priniesť nové technológie, nové rámce a knižnice.
Problémy so základňou a monolitom boli opísané mnohokrát, napríklad v súvislosti s haváriami začiatkom roka 2018 (, и ), takže sa nebudem príliš zdržiavať. Dovoľte mi povedať, že sme chceli poskytnúť väčšiu flexibilitu pri vývoji služieb. V prvom rade sa to týkalo tých, ktoré boli najviac zaťažované a root v celom systéme – Auth a Tracker.
Cesta Back Office: Oddelené základne a autobus
Navigácia v kapitole
Schéma monolitu 2016
Tu sú hlavné bloky monolitu Dodo IS 2016 a nižšie je prepis ich hlavných úloh.
Doručenie do pokladne. Účtovanie pre kuriérov, vystavovanie objednávok kuriérom.
Kontaktné centrum. Prijímanie objednávok cez operátora.
Miesto. Naše webové stránky (dodopizza.ru, dodopizza.co.uk, dodopizza.by atď.).
auth. Služba autorizácie a autentifikácie pre back office.
tracker. Sledovač objednávok v kuchyni. Služba pre označenie stavov pripravenosti pri príprave objednávky.
Pokladňa reštaurácie. Prijímanie objednávok v reštaurácii, pokladničné rozhrania.
export. Nahrávanie správ v 1C pre účtovníctvo.
Oznámenia a faktúry. Hlasové povely v kuchyni (napríklad „Prišla nová pizza“) + tlač faktúr pre kuriérov.
Vedúci smeny. Rozhrania pre prácu vedúceho zmeny: zoznam zákaziek, grafy výkonov, presun zamestnancov na zmenu.
Office Manager. Rozhrania pre prácu franchisanta a manažéra: príjem zamestnancov, správy o práci pizzerie.
Hodnotiaca tabuľka reštaurácie. Zobrazenie menu na televízoroch v pizzeriách.
admin. Nastavenia v konkrétnej pizzerii: menu, ceny, účtovníctvo, promo kódy, akcie, bannery na webe atď.
Osobný účet zamestnanca. Pracovné plány zamestnancov, informácie o zamestnancoch.
Kuchynská motivačná tabuľa. Samostatná obrazovka, ktorá visí v kuchyni a zobrazuje rýchlosť výrobcov pizze.
Komunikácia. Posielanie sms a emailov.
Úložisko súborov. Vlastná služba pre príjem a vydávanie statických súborov.
Prvé pokusy o riešenie problémov nám pomohli, no boli len dočasným oddychom. Nestali sa systémovými riešeniami, takže bolo jasné, že so základňami treba niečo urobiť. Napríklad rozdeliť všeobecnú databázu na niekoľko špecializovanejších.
Začína sa vykladanie monolitu: Oddelenie autorizácie a sledovania
Hlavné služby, ktoré potom zaznamenávali a čítali z databázy viac ako ostatné:
- Auth. Služba autorizácie a autentifikácie pre back office.
- Sledovač. Sledovač objednávok v kuchyni. Služba pre označenie stavov pripravenosti pri príprave objednávky.
Čo robí Auth?
Auth je služba, prostredníctvom ktorej sa užívatelia prihlasujú do back office (na strane klienta je samostatný nezávislý vchod). V žiadosti je tiež vyzvaný, aby sa uistil, že požadované prístupové práva existujú a že sa tieto práva od posledného prihlásenia nezmenili. Cez ňu vstupujú do pizzérie zariadenia.
Chceme napríklad otvoriť displej so stavmi hotových zákaziek na televízore, ktorý visí v predsieni. Potom otvoríme auth.dodopizza.ru, vyberieme „Prihlásiť sa ako zariadenie“, zobrazí sa kód, ktorý je možné zadať na špeciálnej stránke v počítači vedúceho smeny s uvedením typu zariadenia (zariadenia). Televízor sa sám prepne do požadovaného rozhrania svojej pizzérie a začne zobrazovať mená zákazníkov, ktorých objednávky sú tam pripravené.
Odkiaľ sú náklady?
Každý prihlásený používateľ back office ide do databázy, do tabuľky používateľov pri každej požiadavke, vytiahne používateľa cez sql dotaz a skontroluje, či má potrebný prístup a práva na túto stránku.
Každé zo zariadení robí to isté iba s tabuľkou zariadení, pričom kontroluje svoju úlohu a prístup. Veľký počet požiadaviek na master databázu vedie k jej načítavaniu a plytvaniu zdrojmi spoločnej databázy na tieto operácie.
Prebieha uvoľnenie Auth
Auth má izolovanú doménu, to znamená, že údaje o používateľoch, prihláseniach alebo zariadeniach vstupujú do služby (zatiaľ) a zostávajú tam. Ak ich niekto potrebuje, tak si po dáta pôjde do tejto služby.
BOLA. Pôvodná schéma práce bola nasledovná:
Chcel by som trochu vysvetliť, ako to fungovalo:
- Požiadavka zvonku prichádza na backend (tam je Asp.Net MVC), prináša so sebou súbor cookie relácie, ktorý sa používa na získanie údajov relácie z Redis(1). Buď obsahuje informácie o prístupoch a potom je prístup k ovládaču otvorený (3,4), alebo nie.
- Ak nie je prístup, musíte prejsť postupom autorizácie. Tu sa pre zjednodušenie zobrazuje ako súčasť cesty v rovnakom atribúte, hoci ide o prechod na prihlasovaciu stránku. V prípade pozitívneho scenára získame správne dokončenú reláciu a prejdeme do Backoffice Controller.
- Ak existujú údaje, musíte ich skontrolovať z hľadiska relevantnosti v databáze používateľov. Zmenila sa jeho úloha, nemal by byť teraz vpustený na stránku? V tomto prípade musíte po prijatí relácie (1) prejsť priamo do databázy a skontrolovať prístup používateľa pomocou vrstvy logickej autentifikácie (2). Ďalej buď na prihlasovaciu stránku, alebo prejdite na ovládač. Taký jednoduchý systém, ale nie celkom štandardný.
- Ak prejdú všetky procedúry, potom preskočíme ďalej v logike v ovládačoch a metódach.
Údaje používateľa sú oddelené od všetkých ostatných údajov, sú uložené v samostatnej tabuľke členstva, funkcie z logickej vrstvy AuthService sa môžu stať metódami API. Hranice domény sú definované celkom jasne: používatelia, ich roly, prístupové údaje, udeľovanie a zrušenie prístupu. Všetko vyzerá tak, že sa dá vytiahnuť v samostatnej službe.
STAŤ SA. Tak urobili:
Tento prístup má množstvo problémov. Napríklad volanie metódy vnútri procesu nie je to isté ako volanie externej služby cez http. Latencia, spoľahlivosť, udržiavateľnosť, transparentnosť prevádzky sú úplne iné. Podrobnejšie o takýchto problémoch hovoril vo svojej správe Andrey Morevskiy. .
Autentifikačná služba a s ňou aj služba zariadenia sa používa pre back office, teda pre služby a rozhrania používané vo výrobe. Autentifikácia pre klientske služby (ako sú webové stránky alebo mobilná aplikácia) prebieha samostatne bez použitia Auth. Rozdelenie trvalo približne rok a teraz sa opäť venujeme tejto téme, pričom systém presúvame na nové autentifikačné služby (so štandardnými protokolmi).
Prečo odlúčenie trvalo tak dlho?
Na ceste bolo veľa problémov, ktoré nás spomalili:
- Chceli sme presunúť údaje o používateľoch, zariadeniach a autentifikácii z databáz špecifických pre jednotlivé krajiny do jednej. Aby sme to urobili, museli sme preložiť všetky tabuľky a použitie z identifikátora int na globálny identifikátor UUId (tento kód sme nedávno prepracovali a open source projekt ). Uchovávanie používateľských údajov (keďže ide o osobné údaje) má svoje obmedzenia a pre niektoré krajiny je potrebné ich uchovávať oddelene. Globálne ID používateľa však musí byť.
- Mnohé tabuľky v databáze obsahujú informácie o audite o používateľovi, ktorý vykonal operáciu. To si vyžadovalo dodatočný mechanizmus pre konzistentnosť.
- Po vytvorení api-služieb nastalo dlhé a postupné obdobie prechodu na iný systém. Prepínanie muselo byť pre používateľov bezproblémové a vyžadovalo si manuálnu prácu.
Schéma registrácie zariadenia v pizzerii:
Všeobecná architektúra po extrakcii služby Auth and Devices:
Poznámka. Pre rok 2020 pracujeme na novej verzii Auth, ktorá je založená na autorizačnom štandarde OAuth 2.0. Tento štandard je pomerne zložitý, ale je užitočný pri vývoji služby overovania totožnosti. V článku "» my, Alexey Chernyaev, sme sa pokúsili povedať o štandarde čo najjednoduchšie a najzrozumiteľnejšie, aby ste ušetrili čas na jeho štúdium.
Čo robí Tracker?
Teraz asi druhá z načítaných služieb. Sledovač plní dvojakú úlohu:
- Na jednej strane má za úlohu ukázať zamestnancom v kuchyni, aké zákazky sú momentálne v práci, aké produkty treba teraz uvariť.
- Na druhej strane digitalizovať všetky procesy v kuchyni.
Keď sa v objednávke objaví nový produkt (napríklad pizza), ide do stanice Rolling out tracker. Na tejto stanici je výrobca pizze, ktorý vezme žemľu požadovanej veľkosti a rozvaľká ju, potom na sledovacom tablete zaznamená, že dokončil svoju úlohu a presunie základňu vyvaľkaného cesta na ďalšiu stanicu - „Zasvätenie“ .
Tam ďalší výrobca pizze naplní pizzu, potom zaznamená na tablet, že dokončil svoju úlohu a vloží pizzu do pece (toto je tiež samostatná stanica, ktorú je potrebné poznačiť na tablet). Takýto systém bol od samého začiatku v Dodo a od samého začiatku existencie Dodo IS. Umožňuje vám plne sledovať a digitalizovať všetky transakcie. Okrem toho sledovač navrhuje, ako variť konkrétny produkt, vedie každý typ produktu podľa jeho výrobných schém, ukladá optimálny čas varenia pre produkt a sleduje všetky operácie na produkte.
Takto vyzerá obrazovka tabletu na stanici sledovača "Raskatka"
Odkiaľ sú náklady?
Každá z pizzerií má asi päť tabletov s trackerom. V roku 2016 sme mali viac ako 100 pizzerií (a teraz viac ako 600). Každý z tabletov robí požiadavku na backend každých 10 sekúnd a zoškrabáva údaje z tabuľky objednávok (spojenie s klientom a adresou), zloženia objednávky (spojenie s produktom a údaj o množstve), motivačnej účtovnej tabuľky (tzv. je v ňom sledovaný čas lisovania). Keď výrobca pizze klikne na produkt na sledovači, položky vo všetkých týchto tabuľkách sa aktualizujú. Tabuľka objednávok je všeobecná, obsahuje aj vložky pri prijímaní objednávky, aktualizácie z iných častí systému a početné čítania napríklad na televízore, ktorý visí v pizzerii a ukazuje zákazníkom hotové objednávky.
Počas obdobia boja s nákladmi, keď sa všetko a všetko uložilo do vyrovnávacej pamäte a prenieslo do asynchrónnej repliky základne, tieto operácie so sledovačom naďalej smerovali do hlavnej základne. Nemalo by dôjsť k oneskoreniu, údaje by mali byť aktuálne, nesynchronizované je neprijateľné.
Taktiež nedostatok vlastných tabuliek a indexov na nich neumožňoval písať konkrétnejšie dotazy prispôsobené ich použitiu. Napríklad pre sledovač môže byť efektívne mať index pre pizzeriu na stole objednávok. Objednávky pizzérie vždy odstraňujeme z databázy trackerov. Zároveň pre prijatie objednávky nie je až také dôležité, do ktorej pizzérie spadá, dôležitejšie je, ktorý klient túto objednávku zadal. A to znamená, že index na klientovi je potrebný. Tiež nie je potrebné, aby sledovač ukladal ID vytlačeného účtenky alebo bonusových akcií spojených s objednávkou v tabuľke objednávok. Tieto informácie nie sú zaujímavé pre našu službu sledovania. V spoločnej monolitickej databáze môžu byť tabuľky iba kompromisom medzi všetkými používateľmi. Toto bol jeden z pôvodných problémov.
BOLA. Pôvodná architektúra bola:
Dokonca aj po rozdelení do samostatných procesov zostala väčšina kódovej základne spoločná pre rôzne služby. Všetko pod ovládačmi bolo jediné a žilo v rovnakom úložisku. Použili sme bežné metódy služieb, úložiská, spoločnú bázu, v ktorej ležali spoločné tabuľky.
Sledovanie vykládky
Hlavným problémom sledovača je, že údaje musia byť synchronizované medzi rôznymi databázami. To je tiež jeho hlavný rozdiel oproti oddeleniu služby Auth, objednávka a jej stav sa môžu meniť a mali by sa zobrazovať v rôznych službách.
Objednávku prijímame na Pokladni reštaurácie (ide o službu), v databáze je uložená v stave "Prijaté". Potom by sa mal dostať do sledovača, kde ešte niekoľkokrát zmení svoj stav: z „Kuchyňa“ na „Zabalené“. Zároveň sa pri objednávke môžu vyskytovať niektoré vonkajšie vplyvy z rozhrania Pokladňa alebo manažér zmeny. Stavy objednávok s popisom uvediem v tabuľke:
Schéma zmeny stavu objednávky vyzerá takto:
Stavy sa menia medzi rôznymi systémami. A tu sledovač nie je konečný systém, v ktorom sú dáta uzavreté. V takomto prípade sme videli niekoľko možných prístupov k rozdeleniu:
- Všetky úkony objednávky sústreďujeme do jednej služby. V našom prípade táto možnosť vyžaduje príliš veľa služieb na prácu s objednávkou. Ak by sme sa pri ňom zastavili, dostali by sme druhý monolit. Problém by sme neriešili.
- Jeden systém zavolá druhému. Druhá možnosť je už zaujímavejšia. Ale s ním sú možné reťazce hovorov (), konektivita komponentov je vyššia, je náročnejšia na správu.
- Organizujeme akcie a každá služba prostredníctvom týchto akcií komunikuje s inou. V dôsledku toho bola zvolená tretia možnosť, podľa ktorej si všetky služby začnú navzájom vymieňať udalosti.
To, že sme zvolili tretiu možnosť, znamenalo, že tracker bude mať vlastnú databázu a pri každej zmene v objednávke o tom pošle udalosť, ku ktorej sa prihlasujú ďalšie služby a ktorá spadá aj do hlavnej databázy. Na to sme potrebovali nejakú službu, ktorá by zabezpečovala doručovanie správ medzi službami.
V tom čase sme už mali RabbitMQ v zásobníku, a preto sme sa rozhodli použiť ho ako sprostredkovateľa správ. Diagram znázorňuje prechod objednávky z Pokladne reštaurácie cez Sledovačku, kde sa mení jej stav a jej zobrazenie v rozhraní Objednávky manažéra. STAŤ SA:
Objednajte si cestu krok za krokom
Cesta objednávky začína v jednej zo služieb zdroja objednávky. Tu je pokladník reštaurácie:
- Pri pokladni je objednávka úplne pripravená a je čas ju odoslať do sledovača. Vyhodí sa udalosť, na ktorú je sledovač prihlásený.
- Sledovač, ktorý pre seba prijme objednávku, ju uloží do svojej vlastnej databázy, čím urobí udalosť „Objednávka prijatá sledovačom“ a odošle ju do RMQ.
- Na odber zbernice udalostí na objednávku je už prihlásených niekoľko handlerov. Pre nás je dôležitý ten, ktorý robí synchronizáciu s monolitickou základňou.
- Handler prijme udalosť, vyberie z nej údaje, ktoré sú pre ňu významné: v našom prípade je to stav objednávky "Prijaté trackerom" a aktualizuje svoju entitu objednávky v hlavnej databáze.
Ak niekto potrebuje objednávku z tabuľky monolitických objednávok, môžete si ju prečítať aj odtiaľ. Napríklad rozhranie príkazov v Správcovi zmien potrebuje toto:
Všetky ostatné služby sa tiež môžu prihlásiť na odber udalostí zo sledovača, aby ich mohli používať pre seba.
Ak sa objednávka po chvíli prevezme do prevádzky, najskôr sa jej stav zmení v databáze (databáza Tracker) a potom sa okamžite vygeneruje udalosť „OrderIn Progress“. Dostáva sa aj do RMQ, odkiaľ je synchronizovaný v monolitickej databáze a dodávaný ďalším službám. Cestou sa môžu vyskytnúť rôzne problémy, viac podrobností o nich nájdete v správe Zhenya Peshkov .
Finálna architektúra po zmenách v Auth a Tracker
Zhrnutie priebežného výsledku: Pôvodne som mal nápad zbaliť deväťročnú históriu systému Dodo IS do jedného článku. Chcel som rýchlo a jednoducho hovoriť o fázach evolúcie. Keď som si však sadol za materiál, uvedomil som si, že všetko je oveľa komplikovanejšie a zaujímavejšie, ako sa zdá.
Uvažujúc o výhodách (alebo ich nedostatku) takéhoto materiálu som dospel k záveru, že nepretržitý vývoj nie je možný bez plnohodnotných análov udalostí, podrobných retrospektív a analýzy mojich minulých rozhodnutí.
Dúfam, že bolo pre vás užitočné a zaujímavé dozvedieť sa o našej ceste. Teraz stojím pred voľbou, ktorú časť systému Dodo IS popísať v ďalšom článku: píšte do komentárov alebo hlasujte.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
O ktorej časti Dodo IS by ste sa chceli dozvedieť v ďalšom článku?
-
24,1%Skorý monolit v Dodo IS (2011-2015)14
-
24,1%Prvé problémy a ich riešenia (2015-2016)14
-
20,7%Cesta na strane klienta: fasáda nad základňou (2016-2017)12
-
36,2%História skutočných mikroslužieb (2018-2019)21
-
44,8%Kompletné pílenie monolitu a stabilizácia architektúry26
-
29,3%O ďalších plánoch rozvoja systému17
-
19,0%Nechcem nič vedieť o Dodo IS11
Hlasovalo 58 užívateľov. 6 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com