Habr megváltoztatja a világot. Már több mint egy éve írunk blogot. Körülbelül hat hónappal ezelőtt teljesen logikus visszajelzést kaptunk Khabrovitestől: „Dodo, mindenhol azt mondod, hogy saját rendszered van. És mi ez a rendszer? És miért kell egy pizzaláncnak?
Ültünk, gondolkodtunk és rájöttünk, hogy igazad van. Ujjunkra próbálunk mindent elmagyarázni, de darabokban jön ki és sehol nincs teljes leírás a rendszerről. Így kezdődött az információgyűjtés, a szerzők keresése és egy cikksorozat írása a Dodo IS-ről. Gyerünk!
Köszönetnyilvánítás: Köszönjük, hogy megosztotta velünk visszajelzését. Neki köszönhetően végre leírtuk a rendszert, összeállítottunk egy műszaki radart, és hamarosan bemutatjuk a folyamataink nagy leírását. Nélküled még 5 évig ott ülnénk.
Cikksorozat "Mi a Dodo IS?" erről mesél:
- Korai monolit a Dodo IS-ben (2011-2015). (Folyamatban...)
- A back office útvonal: külön bázisok és busz. (Ön itt van)
- Az ügyféloldali út: homlokzat az alap felett (2016-2017). (Folyamatban...)
- Az igazi mikroszolgáltatások története. (2018-2019). (Folyamatban…)
- A monolit fűrészelése és az építészet stabilizálása befejeződött. (Folyamatban...)
Ha érdekel valami mást - írd meg a megjegyzésekben.
Vélemény a kronologikus leírásról a szerzőtől
Rendszeresen tartok értekezletet az új munkatársaknak "Rendszerarchitektúra" témában. „Bevezetés a Dodo IS architektúrába” nevezzük, és az új fejlesztők bevezető folyamatának része. Egy-egy formában mesélve építészetünkről, annak jellemzőiről, egyfajta történeti megközelítést szültem a leíráshoz.
Hagyományosan úgy tekintünk a rendszerre, mint komponensek (műszaki vagy magasabb szintű), üzleti modulok halmazára, amelyek kölcsönhatásba lépnek egymással valamilyen cél elérése érdekében. És ha egy ilyen nézet indokolt a tervezéshez, akkor nem egészen alkalmas leírásra és megértésre. Itt több oka is van:
- A valóság más, mint a papíron. Nem minden úgy sikerül, ahogy elterveztük. És arra vagyunk kíváncsiak, hogy valójában hogyan alakult és működik.
- Az információk következetes bemutatása. Valójában kronologikusan lehet haladni az elejétől a jelenlegi állapotig.
- Az egyszerűtől a bonyolultig. Nem általánosan, de a mi esetünkben igen. Az architektúra az egyszerűbb megközelítésektől a bonyolultabbak felé mozdult el. Gyakran bonyodalmakon keresztül sikerült megoldani a megvalósítás sebességével és stabilitásával kapcsolatos problémákat, valamint tucatnyi egyéb tulajdonságot a nem funkcionális követelmények listájáról ( jól mondták a bonyolultság és más követelmények szembeállításáról).
2011-ben a Dodo IS architektúrája így nézett ki:
2020-ra ez egy kicsit bonyolultabbá vált, és így alakult:
Hogyan ment végbe ez az evolúció? Miért van szükség a rendszer különböző részeire? Milyen építészeti döntések születtek és miért? Ebből a cikksorozatból megtudjuk.
2016 első problémái: miért hagyják el a szolgáltatások a monolitot?
A ciklus első cikkei azokról a szolgáltatásokról fognak szólni, amelyek elsőként váltak le a monolitról. Kontextusba helyezve elmondom, hogy 2016 elejére milyen problémáink voltak a rendszerben, hogy meg kellett küzdenünk a szolgáltatások szétválasztásával.
Egyetlen MySql adatbázis, amelybe a Dodo IS-ben akkoriban létező összes alkalmazás írta a rekordját. A következmények a következők voltak:
- Nehéz terhelés (a kérések 85%-a az olvasást tette ki).
- Az alap megnőtt. Emiatt problémát jelentett a költsége és a támogatása.
- Egyetlen meghibásodási pont. Ha az egyik adatbázisba író alkalmazás hirtelen elkezdte aktívabban csinálni, akkor a többi alkalmazás ezt érezte magán.
- Hatékonyság a tárolásban és a lekérdezésekben. Az adatokat gyakran valamilyen struktúrában tárolták, amely bizonyos forgatókönyvekhez kényelmes volt, de más esetekben nem. Az indexek felgyorsítanak egyes műveleteket, de lelassíthatnak másokat.
- A problémák egy részét a sebtében elkészített gyorsítótárak és a bázisok olvasási-replikái eltávolították (ez egy külön cikk lesz), de csak időt nyerhettek, és alapvetően nem oldották meg a problémát.
A probléma maga a monolit jelenléte volt. A következmények a következők voltak:
- Egyedi és ritka kiadások.
- Nagyszámú ember közös fejlesztésének nehézségei.
- Képtelenség új technológiákat, új kereteket és könyvtárakat bevinni.
Az alappal és a monolittal kapcsolatos problémákat sokszor leírták, például a 2018 eleji összeomlásokkal összefüggésben (, и ), így nem fogok túl sokat időzni. Csak annyit mondok, hogy a szolgáltatások fejlesztésénél nagyobb rugalmasságot akartunk adni. Ez mindenekelőtt azokra vonatkozott, amelyek a legtöbbet betöltötték és a legrootosabbak voltak az egész rendszerben - Auth és Tracker.
A Back Office útvonal: Külön bázisok és busz
fejezet navigáció
Monolit program 2016
Itt vannak a Dodo IS 2016 monolit fő blokkjai, és csak lent található a fő feladataik átirata.
Pénztári kiszállítás. Futárok könyvelése, megrendelések kiadása futároknak.
Kapcsolattartó központ. Megrendelések átvétele az üzemeltetőn keresztül.
Weboldal. Weboldalaink (dodopizza.ru, dodopizza.co.uk, dodopizza.by stb.).
Auth. Engedélyezési és hitelesítési szolgáltatás a back office számára.
Трекер. Rendeléskövető a konyhában. Megrendelés elkészítésekor a készenléti állapotok megjelölésére szolgáló szolgáltatás.
Az étterem pénztára. Megrendelés felvétele étteremben, pénztáros felületek.
Export. Jelentések feltöltése 1C-ben könyvelés céljából.
Értesítések és számlák. Hangutasítások a konyhában (pl. „Új pizza érkezett”) + számlanyomtatás futároknak.
Műszakvezető. Interfészek a műszakvezető munkájához: rendelések listája, teljesítmény grafikonok, dolgozók műszakba áthelyezése.
Irodavezető. Interfészek a franchise átvevő és a vezető munkájához: alkalmazottak fogadása, beszámolók a pizzéria munkájáról.
Étterem eredménytábla. Menü megjelenítése a pizzériák tévéjén.
admin. Beállítások egy adott pizzériában: menü, árak, könyvelés, promóciós kódok, akciók, weboldal bannerek stb.
Az alkalmazott személyes fiókja. Az alkalmazottak munkabeosztása, az alkalmazottakkal kapcsolatos információk.
Konyhai motivációs tábla. Egy külön képernyő, amely a konyhában lóg, és a pizzakészítők sebességét mutatja.
közlés. SMS és email küldés.
FileStorage. Saját szolgáltatás statikus fájlok fogadására és kiadására.
Az első próbálkozások a problémák megoldására segítettek, de ezek csak átmeneti felüdülést jelentettek. Nem lett belőlük rendszermegoldás, így egyértelmű volt, hogy valamit tenni kell az alapokkal. Például az általános adatbázis felosztása több speciálisabb adatbázisra.
A Monolith eltávolításának megkezdése: Auth and Tracker Separation
A főbb szolgáltatások, amelyek ezután többet rögzítettek és olvastak az adatbázisból, mint mások:
- Auth. Engedélyezési és hitelesítési szolgáltatás a back office számára.
- Nyomozó. Rendeléskövető a konyhában. Megrendelés elkészítésekor a készenléti állapotok megjelölésére szolgáló szolgáltatás.
Mit csinál Auth?
Az Auth egy olyan szolgáltatás, amelyen keresztül a felhasználók bejelentkeznek a háttérirodába (az ügyféloldalon külön, független bejárat található). A kérelemben fel kell hívni arra is, hogy megbizonyosodjon arról, hogy a szükséges hozzáférési jogok megvannak, és ezek a jogosultságok nem változtak az utolsó bejelentkezés óta. Rajta keresztül jutnak be eszközök a pizzériába.
Például szeretnénk megnyitni egy kijelzőt a kész rendelések állapotával a folyosón függő tévén. Ezután megnyitjuk az auth.dodopizza.ru oldalt, válassza ki a "Bejelentkezés eszközként" lehetőséget, megjelenik egy kód, amelyet a műszakkezelő számítógépén egy speciális oldalon lehet megadni, jelezve az eszköz (eszköz) típusát. Maga a TV átvált pizzériájának kívánt felületére, és elkezdi megjeleníteni azon ügyfelek nevét, akiknek rendelése készen áll.
Honnan vannak a terhelések?
A back office minden bejelentkezett felhasználója minden kérésnél bemegy az adatbázisba, a felhasználói táblába, egy sql lekérdezéssel kihúzza a felhasználót, és ellenőrzi, hogy rendelkezik-e a szükséges hozzáféréssel és jogosultságokkal ehhez az oldalhoz.
Mindegyik eszköz ugyanezt csak az eszköztáblázattal teszi meg, ellenőrzi annak szerepét és hozzáférését. A fő adatbázishoz intézett nagyszámú kérés annak betöltéséhez és a közös adatbázis erőforrásainak pazarlásához vezet ezekhez a műveletekhez.
Unloading Auth
Az Auth-nak van egy elszigetelt tartománya, vagyis a felhasználókról, bejelentkezésekről vagy eszközökről szóló adatok belépnek a szolgáltatásba (egyelőre) és ott is maradnak. Ha valakinek szüksége van rájuk, akkor ehhez a szolgáltatáshoz megy adatokért.
EZ VOLT. A munka eredeti sémája a következő volt:
Szeretném egy kicsit elmagyarázni, hogyan működött:
- Külső kérés érkezik a háttérbe (van Asp.Net MVC), hoz magával egy session cookie-t, amivel a Redis(1) munkamenet-adatokat kapja meg. Vagy tartalmaz információkat a hozzáférésekről, és akkor a vezérlőhöz való hozzáférés nyitva van (3,4, XNUMX), vagy nem.
- Ha nincs hozzáférés, akkor át kell mennie az engedélyezési eljáráson. Itt az egyszerűség kedvéért az elérési út részeként jelenik meg ugyanabban az attribútumban, bár ez egy átmenet a bejelentkezési oldalra. Pozitív forgatókönyv esetén helyesen befejezett munkamenetet kapunk, és a Backoffice Controllerhez lépünk.
- Ha vannak adatok, akkor ellenőriznie kell azok relevanciáját a felhasználói bázisban. Változott a szerepe, most ne engedjék fel az oldalra? Ebben az esetben a munkamenet (1) fogadása után közvetlenül az adatbázisba kell lépnie, és a hitelesítési logikai réteg (2) segítségével ellenőriznie kell a felhasználó hozzáférését. Ezután lépjen a bejelentkezési oldalra, vagy lépjen a vezérlőre. Ilyen egyszerű rendszer, de nem egészen szabványos.
- Ha az összes eljárást átadtuk, akkor tovább ugrunk a logikában a vezérlőkben és a metódusokban.
A felhasználói adatok el vannak különítve az összes többi adattól, külön tagsági táblában tárolódnak, az AuthService logikai réteg függvényei api metódussá válhatnak. A tartományhatárok egyértelműen meghatározottak: felhasználók, szerepeik, hozzáférési adatok, hozzáférés megadása és visszavonása. Minden úgy néz ki, hogy külön szervizben kivehető.
VÁLIK. Így tették:
Ez a megközelítés számos problémával jár. Például egy metódus folyamaton belüli meghívása nem ugyanaz, mint egy külső szolgáltatás http-n keresztüli meghívása. Teljesen más a késleltetés, a megbízhatóság, a karbantarthatóság, a működés átláthatósága. Andrej Morevszkij részletesebben beszélt az ilyen problémákról jelentésében. .
A hitelesítési szolgáltatást és ezzel együtt az eszközszolgáltatást a háttérirodára, azaz a termelésben használt szolgáltatásokra, interfészekre használják. Az ügyfélszolgáltatások (például webhelyek vagy mobilalkalmazások) hitelesítése külön történik, Auth használata nélkül. A szétválás körülbelül egy évig tartott, és most ismét ezzel a témával foglalkozunk, új hitelesítési szolgáltatásokra (szabványos protokollokkal) helyezzük át a rendszert.
Miért tartott ilyen sokáig az elválás?
Sok probléma volt az út során, ami lelassított minket:
- Szerettük volna a felhasználói, eszköz- és hitelesítési adatokat országspecifikus adatbázisokból egybe helyezni. Ehhez le kellett fordítanunk az összes táblát és használatot az int azonosítóról a globális UUId azonosítóra (nemrég átdolgoztuk ezt a kódot és nyílt forráskódú projekt ). A felhasználói adatok tárolásának (mivel személyes adatokról van szó) megvannak a maga korlátai, és egyes országokban külön kell tárolni azokat. De a felhasználó globális azonosítójának kell lennie.
- Az adatbázisban található számos tábla rendelkezik ellenőrzési információkkal a műveletet végrehajtó felhasználóról. Ehhez egy további mechanizmusra volt szükség a következetesség érdekében.
- Az api-szolgáltatások létrehozása után hosszú és fokozatos átállás következett be egy másik rendszerre. A váltásnak zökkenőmentesnek kellett lennie a felhasználók számára, és kézi munkát igényelt.
Eszköz regisztrációs séma egy pizzériában:
Általános architektúra az Auth and Devices szolgáltatás kibontása után:
Megjegyzés. 2020-ra az Auth új verzióján dolgozunk, amely az OAuth 2.0 engedélyezési szabványon alapul. Ez a szabvány meglehetősen összetett, de hasznos átmenő hitelesítési szolgáltatás fejlesztéséhez. A cikkben "» mi, Alekszej Csernyajev igyekeztünk a lehető legegyszerűbben és legvilágosabban elmondani a szabványt, hogy időt takarítson meg a tanulmányozásával.
Mit csinál a Tracker?
Most a betöltött szolgáltatások közül a másodikról. A nyomkövető kettős szerepet tölt be:
- Egyrészt az a feladata, hogy megmutassa a konyhában dolgozóknak, hogy éppen milyen rendelések vannak folyamatban, milyen termékeket kell most megfőzni.
- Másrészt a konyhában zajló összes folyamat digitalizálására.
Amikor egy új termék jelenik meg a rendelésben (például pizza), az a Rolling out tracker állomásra kerül. Ezen az állomáson van egy pizzasütő, aki kivesz egy megfelelő méretű zsemlét és kinyújtja, majd feljegyzi a nyomkövető táblára, hogy teljesítette a feladatát, és átteszi a kigöngyölt tésztalapot a következő állomásra - „Beavatás” .
Ott a következő pizzasütő megtölti a pizzát, majd feljegyzi a táblagépre, hogy elvégezte a feladatát, és beteszi a pizzát a sütőbe (ez is egy külön állomás, amit fel kell jegyezni a táblára). Ez a rendszer a kezdetektől fogva a Dodoban és a Dodo IS létezésének kezdetétől fogva volt. Lehetővé teszi az összes tranzakció teljes nyomon követését és digitalizálását. Ezenkívül a nyomkövető javaslatot tesz egy adott termék főzésére, minden terméktípust a gyártási sémái szerint irányít, tárolja a termék optimális főzési idejét, és nyomon követi a terméken végzett összes műveletet.
Így néz ki a táblagép képernyője a "Raskatka" nyomkövető állomásán
Honnan vannak a terhelések?
Mindegyik pizzériában körülbelül öt tabletta van nyomkövetővel. 2016-ban több mint 100 pizzériánk volt (most pedig több mint 600). A tabletek mindegyike 10 másodpercenként kér egy kérést a backend felé, és adatokat kapar a rendelési táblázatból (kapcsolat az ügyféllel és cím), a rendelés összetételéről (termékhez való kapcsolódás és a mennyiség feltüntetése), a motivációs elszámolási táblázatból (a a préselés ideje nyomon követhető benne). Amikor egy pizzakészítő rákattint egy termékre a nyomkövetőn, a táblázatok bejegyzései frissülnek. A rendelési táblázat általános, tartalmazza a rendelés elfogadásakor betéteket, a rendszer más részeiről érkező frissítéseket és számos leolvasást, például egy pizzériában lógó tévén, amely a kész rendeléseket mutatja a vásárlóknak.
A terhelésekkel való küzdelem időszakában, amikor mindent és mindent gyorsítótárban tároltak és átvittek az alap aszinkron replikájára, ezek a műveletek a nyomkövetővel továbbra is a fő bázisra mentek. Ne legyen késés, az adatok legyenek naprakészek, a szinkrontúllépés elfogadhatatlan.
Emellett a saját táblák és indexek hiánya nem tette lehetővé a használatukra szabott konkrétabb lekérdezések írását. Például egy nyomkövető számára hatékony lehet egy pizzéria indexe a rendelési táblázaton. A pizzériarendeléseket mindig eltávolítjuk a tracker adatbázisból. Ugyanakkor a rendelés fogadásához nem annyira az a fontos, hogy melyik pizzériába kerül, hanem az, hogy melyik ügyfél rendelte meg. És azt jelenti, hogy szükség van az ügyfél indexére. Szintén nem szükséges a nyomkövetőnek a megrendeléshez kapcsolódó nyomtatott nyugta vagy bónusz akciók azonosítóját a rendelési táblázatban tárolni. Ez az információ nem érdekli nyomkövető szolgáltatásunkat. Egy közös monolitikus adatbázisban a táblák csak kompromisszumot jelenthetnek az összes felhasználó között. Ez volt az egyik eredeti probléma.
EZ VOLT. Az eredeti architektúra a következő volt:
Még azután is, hogy külön folyamatokra bontották, a kódbázis nagy része közös maradt a különböző szolgáltatásokhoz. A vezérlők alatt minden egyedülálló volt, és ugyanabban a tárolóban élt. A szolgáltatások közös módszereit használtuk, tárolókat, közös bázist, amelyben közös táblák helyezkedtek el.
Tracker kirakása
A tracker fő problémája, hogy az adatokat szinkronizálni kell a különböző adatbázisok között. Ez egyben a fő különbsége az Auth szolgáltatás szétválasztásától, a sorrend és az állapota változhat, és meg kell jeleníteni a különböző szolgáltatásokban.
Rendelést az Étterem Pénztárában fogadunk el (ez egy szolgáltatás), amely az adatbázisban „Elfogadva” státuszban kerül tárolásra. Ezt követően el kell jutnia a nyomkövetőhöz, ahol még többször módosítja az állapotát: „Konyha”-ról „Csomagolt”-ra. Ugyanakkor előfordulhat, hogy a megrendeléssel kapcsolatban külső hatások jelentkezhetnek a Pénztárból vagy a Műszakkezelő felületéről. A rendelési állapotokat leírásukkal együtt adom meg a táblázatban:
A rendelési állapotok megváltoztatásának sémája így néz ki:
Az állapotok a különböző rendszerek között változnak. És itt a tracker nem egy végleges rendszer, amelyben az adatok zárva vannak. Számos lehetséges megközelítést láttunk a particionálásra ilyen esetekben:
- Minden rendelési műveletet egyetlen szolgáltatásban koncentrálunk. Esetünkben ez az opció túl sok szolgáltatást igényel a rendeléssel való együttműködéshez. Ha megállnánk, megkapnánk a második monolitot. Nem oldanánk meg a problémát.
- Az egyik rendszer hívja a másikat. A második lehetőség már érdekesebb. De ezzel hívásláncok lehetségesek (), a komponensek összekapcsolhatósága magasabb, nehezebben kezelhető.
- Rendezvényeket szervezünk, és minden szolgáltatás ezeken keresztül kommunikál a másikkal. Ennek eredményeként a harmadik lehetőséget választották, amely szerint minden szolgáltatás megkezdi az események cseréjét egymással.
Az, hogy a harmadik opciót választottuk, azt jelentette, hogy a trackernek saját adatbázisa lesz, és minden rendelési változásnál erről küld egy eseményt, amelyre más szolgáltatások is előfizetnek, és ami szintén a törzsadatbázisba esik. Ehhez szükségünk volt valamilyen szolgáltatásra, amely biztosítja az üzenetek eljuttatását a szolgáltatások között.
Addigra már a veremben volt a RabbitMQ, ezért a végső döntés, hogy üzenetközvetítőként használjuk. A diagramon egy megrendelés átmenete látható az Étterem Pénztárából a Trackeren keresztül, ahol megváltozik az állapota és a Vezetői rendelések felületen való megjelenítése. VÁLIK:
Rendelési útvonal lépésről lépésre
A rendelési útvonal a rendelési forrás egyik szolgáltatásánál kezdődik. Íme az étterem pénztárosa:
- A pénztárnál a rendelés teljesen készen van, és ideje elküldeni a nyomkövetőnek. Az esemény, amelyre a tracker feliratkozott, dobásra kerül.
- A nyomkövető, elfogadva magának a megrendelést, elmenti azt a saját adatbázisába, így a „Rendelést a Tracker elfogadta” eseményt küldi el az RMQ-nak.
- Rendelésenként több kezelő is előfizetett az eseménybuszra. Számunkra az a fontos, amelyik monolitikus alappal szinkronizál.
- A kezelő fogad egy eseményt, kiválasztja belőle a számára lényeges adatokat: esetünkben ez a "Követő által elfogadva" megrendelés állapota, és frissíti a rendelési entitást a fő adatbázisban.
Ha valakinek rendelésre van szüksége a monolit asztali rendelésekből, akkor onnan is elolvashatja. Például a Műszakkezelő Megrendelések felületének szüksége van erre:
Az összes többi szolgáltatás is előfizethet események megrendelésére a nyomkövetőtől, hogy felhasználhassa azokat.
Ha egy idő után a megrendelés munkába áll, akkor először az adatbázisában (Tracker adatbázisban) változik az állapota, majd azonnal generálódik az "OrderIn Progress" esemény. Bekerül az RMQ-ba is, ahonnan egy monolitikus adatbázisba szinkronizálva továbbítják más szolgáltatásokhoz. Különféle problémák adódhatnak az úton, ezekről további részletek Zsenya Peshkov beszámolójában találhatók .
A végleges architektúra az Auth és a Tracker módosításai után
Összegezve a köztes eredményt: Kezdetben az az ötletem támadt, hogy a Dodo IS rendszer kilenc éves történetét egy cikkbe foglalom. Gyorsan és egyszerűen akartam beszélni az evolúció szakaszairól. Leülve azonban az anyaghoz, rájöttem, hogy minden sokkal bonyolultabb és érdekesebb, mint amilyennek látszik.
Az ilyen anyagok előnyeiről (vagy annak hiányáról) elmélkedve arra a következtetésre jutottam, hogy a folyamatos fejlődés nem lehetséges teljes körű eseménynaplók, részletes visszatekintések és korábbi döntéseim elemzése nélkül.
Remélem, hasznos és érdekes volt számodra megismerni utunkat. Most választás előtt állok, hogy a Dodo IS rendszer melyik részét írjam le a következő cikkben: írd meg kommentben vagy szavazz.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
A Dodo IS mely részéről szeretnél tudni a következő cikkben?
-
24,1%Korai monolit a Dodo IS-ben (2011-2015)14
-
24,1%Első problémák és megoldásaik (2015-2016)14
-
20,7%Az ügyféloldali út: homlokzat az alap felett (2016-2017)12
-
36,2%A valódi mikroszolgáltatások története (2018-2019)21
-
44,8%A monolit teljes fűrészelése és az építészet stabilizálása26
-
29,3%A rendszer fejlesztésének további terveiről17
-
19,0%Nem akarok tudni semmit a Dodo IS11-ről
58 felhasználó szavazott. 6 felhasználó tartózkodott.
Forrás: will.com