Habr mění svět. Blogujeme už přes rok. Asi před půl rokem jsme od Khabrovites dostali naprosto logickou zpětnou vazbu: „Dodo, všude říkáš, že máš svůj systém. A co je to za systém? A proč to řetězec pizzy potřebuje?
Seděli jsme, přemýšleli a uvědomili jsme si, že máte pravdu. Snažíme se vše vysvětlit na prstech, ale vychází to na roztrhané kusy a nikde není kompletní popis systému. Začala tak dlouhá cesta sbírání informací, hledání autorů a psaní série článků o Dodo IS. Pojďme!
Poděkování: Děkujeme, že jste se s námi podělili o zpětnou vazbu. Díky němu jsme konečně popsali systém, sestavili technický radar a brzy spustíme velký popis našich procesů. Bez vás bychom tam seděli dalších 5 let.
Série článků "Co je Dodo IS?" vypráví o:
- Raný monolit v Dodo IS (2011-2015). (Probíhá...)
- Cesta back office: samostatné základny a autobus. (jsi tady)
- Cesta na straně klienta: fasáda nad základnou (2016-2017). (Probíhá...)
- Historie skutečných mikroslužeb. (2018-2019). (Probíhá...)
- Hotové pilování monolitu a stabilizace architektury. (Probíhá...)
Pokud vás zajímá něco dalšího - napište do komentářů.
Názor na chronologický popis od autora
Pravidelně pořádám setkání pro nové zaměstnance na téma „Systémová architektura“. Říkáme tomu „Intro to Dodo IS Architecture“ a je součástí procesu začleňování nových vývojářů. Vyprávět v té či oné formě o naší architektuře, o jejích rysech, jsem si zrodil jistý historický přístup k popisu.
Tradičně se na systém díváme jako na soubor komponent (technických nebo vyšších), obchodních modulů, které se vzájemně ovlivňují za účelem dosažení nějakého cíle. A pokud je takový pohled oprávněný pro design, pak není docela vhodný pro popis a pochopení. Důvodů je zde několik:
- Realita je jiná než na papíře. Ne všechno se daří podle představ. A nás zajímá, jak to vlastně dopadlo a funguje.
- Důsledná prezentace informací. Vlastně můžete jít chronologicky od začátku až po aktuální stav.
- Od jednoduchých po složité. Ne univerzálně, ale v našem případě ano. Architektura se posunula od jednodušších přístupů ke složitějším. Často komplikovaně byly vyřešeny problémy s rychlostí a stabilitou implementace, ale i desítky dalších vlastností ze seznamu nefunkčních požadavků ( dobře řečeno o kontrastu složitosti s jinými požadavky).
V roce 2011 vypadala architektura Dodo IS takto:
Do roku 2020 se to trochu zkomplikovalo a stalo se to takto:
Jak tento vývoj probíhal? Proč jsou potřeba různé části systému? Jaká architektonická rozhodnutí byla přijata a proč? Pojďme to zjistit v této sérii článků.
První problémy roku 2016: proč by služby měly opustit monolit
První články z cyklu budou o službách, které se jako první oddělily od monolitu. Pro uvedení do souvislostí vám řeknu, jaké problémy jsme měli v systému do začátku roku 2016, že jsme se museli vypořádat s oddělením služeb.
Jediná databáze MySql, do které zapisovaly své záznamy všechny aplikace, které v té době v IS Dodo existovaly. Následky byly:
- Velké zatížení (85 % požadavků představovalo čtení).
- Základna se rozrostla. Z tohoto důvodu se jeho náklady a podpora staly problémem.
- Jediný bod selhání. Pokud to najednou začala dělat aktivněji jedna aplikace zapisující do databáze, ostatní aplikace to pocítily na sobě.
- Neefektivita při skladování a dotazech. Data byla často uložena v nějaké struktuře, která byla vhodná pro některé scénáře, ale nevhodná pro jiné. Indexy některé operace urychlují, jiné mohou zpomalit.
- Některé problémy odstranily narychlo vyrobené keše a read-repliky do základen (to bude na samostatný článek), ale umožnily jim získat pouze čas a problém zásadně nevyřešily.
Problémem byla přítomnost samotného monolitu. Následky byly:
- Jednotlivá a vzácná vydání.
- Obtížnost společného rozvoje velkého počtu lidí.
- Neschopnost přinášet nové technologie, nové rámce a knihovny.
Problémy se základnou a monolitem byly popsány mnohokrát, například v souvislosti s haváriemi na začátku roku 2018 (, и ), takže se nebudu moc zdržovat. Dovolte mi jen říci, že jsme chtěli poskytnout větší flexibilitu při vývoji služeb. Především se to týkalo těch, které byly nejvíce zatěžované a root v celém systému – Auth a Tracker.
Cesta Back Office: Oddělené základny a autobus
Navigace po kapitolách
Schéma monolitu 2016
Zde jsou hlavní bloky monolitu Dodo IS 2016 a hned níže je přepis jejich hlavních úkolů.
Pokladní doručení. Účetnictví pro kurýry, vystavování objednávek kurýrům.
Kontaktní centrum. Příjem objednávek přes operátora.
Site. Naše webové stránky (dodopizza.ru, dodopizza.co.uk, dodopizza.by atd.).
Autor. Autorizační a autentizační služba pro back office.
Tracker. Objednejte tracker v kuchyni. Služba pro označení stavů připravenosti při přípravě objednávky.
Pokladna restaurace. Příjem objednávek v restauraci, pokladní rozhraní.
Vývoz. Nahrávání sestav v 1C pro účetnictví.
Oznámení a faktury. Hlasové příkazy v kuchyni (například „Dorazila nová pizza“) + tisk faktur pro kurýry.
Vedoucí směny. Rozhraní pro práci vedoucího směny: seznam zakázek, grafy výkonu, přesun zaměstnanců na směnu.
Vedoucí kanceláře. Rozhraní pro práci franšízanta a vedoucího: příjem zaměstnanců, reporty o práci pizzerie.
Hodnocení restaurace. Zobrazení menu na televizorech v pizzeriích.
admin. Nastavení v konkrétní pizzerii: menu, ceny, účetnictví, promo kódy, akce, bannery na webu atd.
Osobní účet zaměstnance. Pracovní řády zaměstnanců, informace o zaměstnancích.
Kuchyňská motivační deska. Samostatná obrazovka, která visí v kuchyni a zobrazuje rychlost výrobců pizzy.
Komunikace. Zasílání sms a emailů.
Úložiště souborů. Vlastní služba pro příjem a vydávání statických souborů.
První pokusy o řešení problémů nám pomohly, ale byly jen dočasným oddechem. Nestaly se systémovými řešeními, takže bylo jasné, že se základnami se musí něco udělat. Například rozdělit obecnou databázi na několik specializovanějších.
Začíná vykládání Monolith: Auth a Tracker Separation
Hlavní služby, které pak zaznamenávaly a četly z databáze více než jiné:
- Auth. Autorizační a autentizační služba pro back office.
- Stopař. Objednejte tracker v kuchyni. Služba pro označení stavů připravenosti při přípravě objednávky.
Co dělá Auth?
Auth je služba, pomocí které se uživatelé přihlašují do back office (na straně klienta je samostatný nezávislý vchod). V žádosti je také vyzván, aby se ujistil, že jsou přítomna požadovaná přístupová práva a že se tato práva od posledního přihlášení nezměnila. Přes něj vstupují zařízení do pizzerie.
Chceme například otevřít displej se stavy hotových zakázek na televizi visící v předsíni. Poté otevřeme auth.dodopizza.ru, vybereme „Přihlásit se jako zařízení“, objeví se kód, který lze zadat na speciální stránce v počítači vedoucího směny s uvedením typu zařízení (zařízení). Televize se sama přepne do požadovaného rozhraní své pizzerie a začne zobrazovat jména zákazníků, jejichž objednávky jsou tam připraveny.
Odkud jsou zátěže?
Každý přihlášený uživatel back office jde u každého požadavku do databáze, do tabulky uživatelů, přes sql dotaz vytáhne uživatele a zkontroluje, zda má na tuto stránku potřebný přístup a práva.
Každé ze zařízení dělá totéž pouze s tabulkou zařízení, přičemž kontroluje svou roli a svůj přístup. Velké množství požadavků na hlavní databázi vede k jejímu načítání a plýtvání zdroji společné databáze pro tyto operace.
Uvolnění Auth
Auth má izolovanou doménu, to znamená, že data o uživatelích, přihlášeních nebo zařízeních vstupují do služby (prozatím) a zůstávají tam. Pokud je někdo potřebuje, pak si pro data půjde do této služby.
TO BYLO. Původní schéma práce bylo následující:
Chtěl bych trochu vysvětlit, jak to fungovalo:
- Požadavek zvenčí přichází na backend (tam je Asp.Net MVC), přináší s sebou cookie relace, který se používá k získávání dat relace z Redis(1). Buď obsahuje informace o přístupech, a pak je přístup k ovladači otevřený (3,4), nebo ne.
- Pokud není přístup, musíte projít autorizačním postupem. Zde je pro zjednodušení zobrazen jako součást cesty ve stejném atributu, ačkoli se jedná o přechod na přihlašovací stránku. V případě pozitivního scénáře získáme správně dokončenou relaci a přejdeme do Backoffice Controller.
- Pokud existují data, musíte je zkontrolovat, zda jsou relevantní v databázi uživatelů. Změnila se jeho role, neměl by být nyní na stránku vpuštěn? V tomto případě musíte po přijetí relace (1) přejít přímo do databáze a zkontrolovat přístup uživatele pomocí vrstvy autentizační logiky (2). Dále buď na přihlašovací stránku, nebo na ovladač. Takový jednoduchý systém, ale ne úplně standardní.
- Pokud projdou všechny procedury, přeskočíme dále v logice v kontrolérech a metodách.
Uživatelská data jsou oddělena od všech ostatních dat, jsou uložena v samostatné tabulce členství, funkce z logické vrstvy AuthService se mohou dobře stát metodami API. Hranice domény jsou definovány poměrně jasně: uživatelé, jejich role, přístupové údaje, udělování a odebírání přístupu. Vše vypadá tak, že se to dá vyndat v samostatné službě.
STÁT SE. Tak to udělali:
Tento přístup má řadu problémů. Například volání metody uvnitř procesu není totéž jako volání externí služby přes http. Zcela jiná je latence, spolehlivost, udržovatelnost, transparentnost provozu. Podrobněji o takových problémech hovořil ve své zprávě Andrey Morevskiy. .
Autentizační služba a s ní i služba zařízení slouží pro back office, tedy pro služby a rozhraní používaná v produkci. Autentizace pro klientské služby (jako jsou webové stránky nebo mobilní aplikace) probíhá samostatně bez použití Auth. Oddělení trvalo zhruba rok a nyní se tímto tématem opět zabýváme a převádíme systém na nové autentizační služby (se standardními protokoly).
Proč odloučení trvalo tak dlouho?
Na cestě bylo mnoho problémů, které nás zpomalily:
- Chtěli jsme přesunout data o uživatelích, zařízeních a autentizačních údajích z databází specifických pro jednotlivé země do jedné. Abychom to udělali, museli jsme přeložit všechny tabulky a použití z identifikátoru int na globální identifikátor UUId (tento kód jsme nedávno přepracovali a open source projekt ). Ukládání uživatelských dat (jelikož se jedná o osobní údaje) má svá omezení a pro některé země je nutné je uchovávat odděleně. Ale globální ID uživatele musí být.
- Mnoho tabulek v databázi obsahuje auditní informace o uživateli, který operaci provedl. To vyžadovalo další mechanismus pro konzistenci.
- Po vytvoření api-služeb následovalo dlouhé a postupné období přechodu na jiný systém. Přepínání muselo být pro uživatele bezproblémové a vyžadovalo manuální práci.
Schéma registrace zařízení v pizzerii:
Obecná architektura po extrakci služby Auth and Devices:
Poznámka. Pro rok 2020 pracujeme na nové verzi Auth, která je založena na autorizačním standardu OAuth 2.0. Tento standard je poměrně složitý, ale je užitečný pro vývoj služby průchozí autentizace. V článku "» my jsme se Alexey Chernyaev snažili o standardu vyprávět co nejjednodušeji a nejjasněji, abyste ušetřili čas na jeho studium.
Co dělá Tracker?
Nyní asi druhá z načtených služeb. Sledovač plní dvojí roli:
- Na jedné straně má za úkol ukázat zaměstnancům v kuchyni, jaké zakázky právě fungují, jaké produkty je nyní potřeba uvařit.
- Na druhou stranu digitalizovat všechny procesy v kuchyni.
Když se v objednávce objeví nový produkt (například pizza), jde do stanice Rolling out tracker. Na tomto stanovišti je výrobce pizzy, který vezme housku požadované velikosti a vyválí ji, načež si na sledovací tablet poznamená, že dokončil svůj úkol, a přenese vyválený základ těsta na další stanoviště – „Zasvěcení“ .
Tam další výrobce pizzy naplní pizzu, pak si na tablet poznamená, že splnil svůj úkol, a vloží pizzu do pece (toto je také samostatná stanice, kterou je třeba poznamenat na tabletu). Takový systém byl od samého počátku v Dodo a od samého počátku existence Dodo IS. Umožňuje vám plně sledovat a digitalizovat všechny transakce. Kromě toho sledovač navrhuje, jak vařit konkrétní produkt, vede každý typ produktu podle jeho výrobních schémat, ukládá optimální dobu vaření pro produkt a sleduje všechny operace na produktu.
Takto vypadá obrazovka tabletu na stanici stopaře "Raskatka"
Odkud jsou zátěže?
Každá z pizzerií má asi pět tabletů s trackerem. V roce 2016 jsme měli více než 100 pizzerií (a nyní více než 600). Každý z tabletů každých 10 sekund zadá požadavek na backend a seškrábe data z tabulky objednávek (spojení s klientem a adresou), složení objednávky (spojení s produktem a údaj o množství), motivační účetní tabulky (tzv. je v něm sledován čas lisování). Když výrobce pizzy klikne na produkt na trackeru, záznamy ve všech těchto tabulkách se aktualizují. Tabulka objednávek je obecná, obsahuje i inserty při přijímání objednávky, aktualizace z jiných částí systému a četné odečty např. na televizi, která visí v pizzerii a zákazníkům ukazuje hotové objednávky.
V období boje se zátěžemi, kdy se vše a vše ukládalo do mezipaměti a přenášelo do asynchronní repliky základny, tyto operace s trackerem nadále směřovaly na hlavní základnu. Nemělo by docházet k žádnému zpoždění, data by měla být aktuální, nesynchronizované je nepřijatelné.
Také nedostatek vlastních tabulek a indexů na nich neumožňoval psát konkrétnější dotazy přizpůsobené jejich použití. Například pro sledovač může být efektivní mít index pro pizzerii na tabulce objednávek. Objednávky pizzerie vždy odstraníme z databáze trackeru. Pro příjem objednávky přitom není až tak důležité, do které pizzerie spadá, důležitější je, který klient tuto objednávku provedl. A znamená to, že index na klientovi je nezbytný. Rovněž není nutné, aby sledovač ukládal ID vytištěné účtenky nebo bonusových akcí spojených s objednávkou v tabulce objednávek. Tyto informace nejsou pro naši sledovací službu zajímavé. Ve společné monolitické databázi mohou být tabulky pouze kompromisem mezi všemi uživateli. To byl jeden z původních problémů.
TO BYLO. Původní architektura byla:
I po rozdělení do samostatných procesů zůstala většina kódové základny společná pro různé služby. Vše pod ovladači bylo jediné a žilo ve stejném úložišti. Použili jsme běžné metody služeb, repozitáře, společný základ, ve kterém ležely společné tabulky.
Vykládání Tracker
Hlavním problémem trackeru je, že data musí být synchronizována mezi různými databázemi. To je také její hlavní rozdíl oproti oddělení služby Auth, objednávka a její stav se mohou měnit a měly by se zobrazovat v různých službách.
Objednávku přijímáme na Pokladně Restaurace (jedná se o službu), v databázi je uložena ve stavu "Přijato". Poté by se měl dostat do sledovače, kde ještě několikrát změní svůj stav: z „Kuchyně“ na „Zabaleno“. Zároveň se u objednávky mohou vyskytovat některé vnější vlivy z rozhraní Pokladna nebo Správce směn. Stavy objednávek s popisem uvedu v tabulce:
Schéma změny stavu objednávky vypadá takto:
Stavy se mezi různými systémy mění. A zde tracker není konečným systémem, ve kterém jsou data uzavřena. Viděli jsme několik možných přístupů k rozdělení v takovém případě:
- Všechny zakázkové akce soustředíme do jedné služby. V našem případě tato možnost vyžaduje příliš mnoho služeb pro práci s objednávkou. Kdybychom se u toho zastavili, dostali bychom druhý monolit. Problém bychom nevyřešili.
- Jeden systém zavolá druhému. Druhá možnost je již zajímavější. Ale s ním jsou možné řetězce hovorů (), konektivita komponent je vyšší, je náročnější na správu.
- Pořádáme akce a každá služba prostřednictvím těchto akcí komunikuje s jinou. Ve výsledku byla zvolena třetí možnost, podle níž si všechny služby začnou vyměňovat události mezi sebou.
To, že jsme zvolili třetí možnost, znamenalo, že tracker bude mít vlastní databázi a při každé změně v objednávce o tom odešle událost, ke které se ostatní služby přihlašují a která také spadá do hlavní databáze. K tomu jsme potřebovali nějakou službu, která by zajistila doručování zpráv mezi službami.
V té době jsme již měli RabbitMQ v zásobníku, takže konečné rozhodnutí použít jej jako zprostředkovatele zpráv. Diagram znázorňuje přechod objednávky z Pokladny restaurace přes Tracker, kde se změní její stav a její zobrazení na rozhraní Příkazy vedoucího. STÁT SE:
Objednejte si cestu krok za krokem
Cesta objednávky začíná u jedné ze služeb zdroje objednávky. Zde je pokladní restaurace:
- U pokladny je objednávka kompletně připravena a je čas ji odeslat do trackeru. Vyvolá se událost, ke které je sledovač přihlášen.
- Sledovač, který pro sebe přijme objednávku, ji uloží do své vlastní databáze, provede událost „Objednávka přijata stopařem“ a odešle ji do RMQ.
- K odběru sběrnice událostí na objednávku je již přihlášeno několik obslužných rutin. Pro nás je důležitý ten, který dělá synchronizaci s monolitickou základnou.
- Handler obdrží událost, vybere z ní data, která jsou pro něj významná: v našem případě je to stav objednávky "Přijato Trackerem" a aktualizuje její entitu objednávky v hlavní databázi.
Pokud někdo potřebuje objednávku z objednávky monolitického stolu, můžete si ji přečíst i odtud. Například rozhraní Objednávky ve Správci směn potřebuje toto:
Všechny ostatní služby se také mohou přihlásit k objednání událostí z trackeru, aby je mohly využívat pro sebe.
Pokud je po chvíli objednávka uvedena do provozu, pak se její stav nejprve změní v její databázi (databáze Tracker) a poté je okamžitě vygenerována událost "OrderIn Progress". Dostává se také do RMQ, odkud je synchronizován v monolitické databázi a dodáván dalším službám. Cestou mohou nastat různé problémy, více podrobností o nich lze nalézt ve zprávě Zhenyi Peshkov .
Finální architektura po změnách v Auth a Tracker
Shrnutí průběžného výsledku: Původně jsem měl nápad sbalit devítiletou historii systému Dodo IS do jednoho článku. Chtěl jsem rychle a jednoduše mluvit o fázích evoluce. Když jsem si však sednul k materiálu, uvědomil jsem si, že vše je mnohem složitější a zajímavější, než se zdá.
Přemýšlením o výhodách (nebo jejich nedostatku) takového materiálu jsem došel k závěru, že nepřetržitý vývoj není možný bez plnohodnotných análů událostí, detailních retrospektiv a analýzy mých minulých rozhodnutí.
Doufám, že pro vás bylo užitečné a zajímavé dozvědět se o naší cestě. Nyní stojím před volbou, kterou část systému Dodo IS popsat v dalším článku: pište do komentářů nebo hlasujte.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
O jaké části Dodo IS byste se chtěli dozvědět v dalším článku?
-
24,1%Raný monolit v Dodo IS (2011-2015)14
-
24,1%První problémy a jejich řešení (2015-2016)14
-
20,7%Cesta na straně klienta: fasáda nad základnou (2016-2017)12
-
36,2%Historie skutečných mikroslužeb (2018-2019)21
-
44,8%Kompletní rozřezání monolitu a stabilizace architektury26
-
29,3%O dalších plánech rozvoje systému17
-
19,0%O Dodo IS11 nechci nic vědět
Hlasovalo 58 uživatelů. 6 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com