Vagy minden boldogtalan cég egy monolittal boldogtalan a maga módján.
A Dodo IS rendszer fejlesztése azonnal megkezdődött, akárcsak a Dodo Pizza üzlet – 2011-ben. Az üzleti folyamatok teljes és teljes digitalizálásának elgondolásán alapult, ill , ami már akkor 2011-ben is sok kérdést és szkepticizmust vetett fel. De immár 9 éve ezt az utat követjük - saját fejlesztésünkkel, ami egy monolittal kezdődött.
Ez a cikk a „válasz” a „Miért kell átírni az architektúrát és végrehajtani ilyen nagyszabású és hosszú távú változtatásokat?” kérdésekre. az előző cikkhez . Kezdem azzal, hogyan kezdődött a Dodo IS fejlesztése, hogyan nézett ki a kezdeti architektúra, hogyan jelentek meg az új modulok, és milyen problémák miatt kellett nagyszabású változtatásokat végrehajtani.
Cikksorozat "Mi a Dodo IS?" erről mesél:
-
Korai monolit a Dodo IS-ben (2011-2015). (Ö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...)
Eredeti építészet
2011-ben a Dodo IS architektúrája így nézett ki:
Az architektúra első modulja a rendelés elfogadása. Az üzleti folyamat a következő volt:
-
egy ügyfél felhívja a pizzériát;
-
A menedzser felveszi a telefont;
-
telefonon vesz fel rendeléseket;
-
Egyúttal kitölti a rendelés elfogadó felületén: figyelembe veszi az ügyfélre vonatkozó információkat, a rendelési adatokra vonatkozó adatokat és a szállítási címet.
Az információs rendszer felülete valahogy így nézett ki...
Első verzió 2011 októberéből:
Az első rendelésfelvételi modul fejlesztéséhez rendelkezésre álló erőforrások korlátozottak voltak. Sokat kellett tenni, gyorsan és kis csapattal. A kis csapat 2 fejlesztőből áll, akik megalapozták a teljes jövőbeli rendszert.
Első döntésük meghatározta a technológiai halom jövőbeli sorsát:
-
Háttér ASP.NET MVC, C# nyelven. A fejlesztők ponthálósok voltak, ez a verem ismerős és kellemes volt számukra.
-
Frontend Bootstrap és JQuery rendszeren: egyéni stílusokon és szkripteken alapuló felhasználói felületek.
-
MySQL adatbázis: nincs licencköltség, könnyen használható.
-
Szerverek Windows Serveren, mert a .NET akkor csak Windowson lehetett (a monoról nem fogunk beszélni).
Fizikailag mindezt a „házigazda asztalában” fejezték ki.
A megrendelés elfogadó alkalmazás felépítése
Ekkor már mindenki a mikroszolgáltatásokról beszélt, a SOA-t pedig nagyjából 5 éve használták nagy projektekben, 2006-ban például megjelent a WCF. De aztán egy megbízható és bevált megoldást választottak.
Itt van.
Az Asp.Net MVC a Razor, amely egy űrlap vagy egy kliens kérésére egy HTML oldalt készít a szerveren való megjelenítéssel. A kliensen a CSS és JS szkriptek már megjelenítenek információkat, és szükség esetén AJAX kéréseket hajtanak végre a JQueryn keresztül.
A szerveren lévő kérések a *Controller osztályokba tartoznak, ahol a metódus feldolgozza és előállítja a végső HTML oldalt. A vezérlők kéréseket küldenek a *Services nevű logikai réteghez. Mindegyik szolgáltatás megfelelt az üzlet bizonyos aspektusainak:
-
Például a DepartmentStructureService pizzériákról és részlegekről adott információkat. A részleg pizzériacsoport, amelyet egy franchise-vevő kezel.
-
A ReceivingOrdersService fogadta és kiszámolta a megrendelés tartalmát.
-
Az SmsService pedig SMS-t küldött az API-szolgáltatások SMS-küldéséhez hívásával.
A szolgáltatások az adatbázisból származó adatokat dolgozták fel, és üzleti logikát tároltak. Minden szolgáltatásnak volt egy vagy több *lerakatok a megfelelő névvel. Már tartalmaztak lekérdezéseket az adatbázisban tárolt eljárásokhoz és egy réteg leképezőt. Az adattárak üzleti logikával rendelkeztek, különösen sok olyan, amely jelentési adatokat készített. ORM nem volt használva, mindenki a kézzel írott sql-re hagyatkozott.
A tartománymodellnek és az általános segítő osztályoknak is volt egy rétege, például a Rend osztály, amely a sorrendet tárolta. Ott a rétegben volt egy segítő a kijelző szövegének a kiválasztott pénznem szerinti konvertálásához.
Mindezt ezzel a modellel ábrázolhatjuk:
Rendelés módja
Tekintsünk egy egyszerűsített kezdeti módot egy ilyen sorrend létrehozására.
Kezdetben a helyszín statikus volt. Árak voltak rajta, a tetején pedig egy telefonszám és a „Ha pizzát akarsz, hívd a számot és rendeld meg” felirat. A megrendeléshez egy egyszerű folyamatot kell végrehajtanunk:
-
Az ügyfél felmegy egy statikus weboldalra az árakkal, kiválasztja a termékeket és felhívja a weboldalon feltüntetett telefonszámot.
-
A vásárló megnevezi azokat a termékeket, amelyeket hozzá szeretne adni a rendeléséhez.
-
Megadja a címét és a nevét.
-
Az üzemeltető a megrendelést elfogadja.
-
A megrendelés az elfogadott rendelések felületén jelenik meg.
Minden a menü megjelenítésével kezdődik. Egy bejelentkezett operátor felhasználó egyszerre csak egy rendelést fogad el. Ezért a kosárvázlat a munkamenetében tárolható (a felhasználó munkamenete a memóriában tárolódik). Van egy Kosár objektum, amely termékeket és vásárlói információkat tartalmaz.
Az ügyfél elnevezi a terméket, a kezelő rákattint + a termék mellett, és egy kérés érkezik a szerverre. A termékkel kapcsolatos információk kikerülnek az adatbázisból, és a termékkel kapcsolatos információk a kosárba kerülnek.
Megjegyzés. Igen, itt nem ki kell húzni a terméket az adatbázisból, hanem át kell vinni az előtérből. De az egyértelműség kedvéért pontosan megmutattam az utat az alaptól kezdve.
Ezután adja meg az ügyfél címét és nevét.
Ha a „Megrendelés létrehozása” gombra kattint:
-
A kérelmet a OrderController.SaveOrder() címre küldjük.
-
Kosarat kapunk a foglalkozásról, a szükséges mennyiségben vannak termékek.
-
A Kosarat kiegészítjük az ügyfélre vonatkozó információkkal, és átadjuk a ReceivingOrderService osztály AddOrder metódusának, ahol az adatbázisba kerül.
-
Az adatbázisban vannak táblázatok a megbízással, a megbízás tartalmával, az ügyféllel, és ezek mind össze vannak kötve.
-
A megrendelések megjelenítési felülete kiveszi a legfrissebb rendeléseket és megjeleníti azokat.
Új modulok
A megrendelés átvétele fontos és szükséges volt. Nem vezethetsz pizza üzletet, ha nincs eladási megbízásod. Ezért a rendszer megkezdte a funkcionalitás megszerzését - körülbelül 2012 és 2015 között. Ezalatt az idő alatt a rendszer számos különböző blokkja jelent meg, amelyeket hívni fogok modulok, szemben a szolgáltatás vagy termék fogalmával.
A modul olyan funkciók összessége, amelyeket valamilyen közös üzleti cél egyesít. Ráadásul fizikailag ugyanabban az alkalmazásban találhatók.
A modulokat rendszerblokknak nevezhetjük. Ez például egy jelentéskészítő modul, adminisztrátori felületek, , felhatalmazás. Ezek mind különböző felhasználói felületek, némelyiknek még a vizuális stílusa is eltérő. Ráadásul minden egy alkalmazáson belül, egy futó folyamaton belül van.
Technikailag a modulokat Area néven tervezték (ez az ötlet még benne is maradt ). Külön fájlok voltak a frontendhez, a modellekhez, valamint a saját vezérlőosztályaikhoz. Ennek eredményeként a rendszer átalakult olyan...
...ehhez:
Egyes modulok külön telephelyeken valósulnak meg (végrehajtható projekt), teljesen különálló funkcionalitás, részben pedig némileg különálló, célzottabb fejlesztés miatt. Ez:
-
Weboldal - a dodopizza.ru webhely.
-
Export: jelentések letöltése a Dodo IS-ről 1C-hez.
-
Személyes - az alkalmazott személyes fiókja. Külön fejlesztették, és saját belépési ponttal és különálló kialakítással rendelkezik.
-
fs — statikus hosting projekt. Később eltávolodtunk tőle, és minden statikus tartalmat áthelyeztünk az Akamai CDN-re.
A fennmaradó blokkok a BackOffice alkalmazásban találhatók.
A nevek magyarázata:
-
Pénztáros - Éttermi pénztárgép.
-
ShiftManager - interfészek a „Shift Manager” szerepkörhöz: működési statisztikák a pizzéria eladásairól, a termékek stoplistára helyezése, rendelés módosítása.
-
OfficeManager – felületek a „Pizzéria Manager” és a „Franchisee” szerepkörökhöz. Itt megtalálhatja a pizzéria felállításához, bónuszakcióihoz, a munkavállalók fogadásához és a velük való együttműködéshez, valamint a jelentésekhez kapcsolódó funkciókat.
-
PublicScreens - pizzériákban lógó tévék és táblagépek felületei. A tévék kiszállításkor megjelenítik a menüt, a hirdetési információkat és a rendelés állapotát.
Közös szolgáltatási réteget, Dodo.Core tartományosztályok közös blokkját és közös alapot használtak. Néha még mindig át tudtak vezetni egymáshoz. Ezenkívül az egyes webhelyek, például a dodopizza.ru vagy a personal.dodopizza.ru is hozzáfértek a közös szolgáltatásokhoz.
Amikor új modulok jelentek meg, igyekeztünk a már létrehozott kódot a lehető legnagyobb mértékben újra felhasználni a szolgáltatásokhoz, az adatbázisban tárolt eljárásokhoz és táblákhoz.
A rendszerben készült modulok méretarányának jobb megértése érdekében álljon itt egy diagram 2012-ből a fejlesztési tervekkel:
2015-re minden a pályára állt, és még több volt gyártásban.
-
A rendelésfelvétel a Contact Center külön blokkjává nőtte ki magát, ahol a rendelést az üzemeltető fogadja.
-
A pizzériákban nyilvános képernyők jelentek meg menükkel és információkkal.
-
A konyhában van egy modul, amely automatikusan lejátssza az „Új pizza” hangüzenetet, ha új rendelés érkezik, és számlát is nyomtat a futárnak. Ez nagymértékben leegyszerűsíti a konyhában zajló folyamatokat, és lehetővé teszi, hogy az alkalmazottakat ne vonják el a nagyszámú egyszerű művelettől.
-
A kézbesítési blokkból külön kézbesítő pénztár lett, ahol a megbízást a korábban műszakot átvevő futárnak adták ki. A munkaidejét vették figyelembe a fizetése kiszámításánál.
Ezzel párhuzamosan 2012-től 2015-ig több mint 10 fejlesztő jelent meg, 35 pizzéria nyílt meg, a rendszert Romániába telepítették, és felkészültek az USA-beli pontok megnyitására. A fejlesztőket már nem vonták be minden feladatba, hanem csapatokra osztották őket. mindegyik a rendszer saját részére szakosodott.
Problémák
Többek között az építészet miatt (de nem csak).
Káosz a bázisban
Egy alap kényelmes. Konzisztencia érhető el, mégpedig a relációs adatbázisokba épített eszközök rovására. A vele való munka ismerős és kényelmes, különösen, ha kevés a tábla és kevés az adat.
De a 4 éves fejlesztés során az adatbázis körülbelül 600 táblát, 1500 tárolt eljárást tartalmazott, amelyek közül sok logikát is tartalmazott. Sajnos a tárolt eljárások nem nyújtanak sok előnyt a MySQL-lel való munka során. Az adatbázis nem gyorsítótárazza őket, és a logika tárolása bennük bonyolítja a fejlesztést és a hibakeresést. A kód újrafelhasználása is nehézkes.
Sok táblának nem volt megfelelő indexe, valahol éppen ellenkezőleg, sok index volt, ami megnehezítette a beillesztést. Körülbelül 20 táblát kellett módosítani – a rendelés létrehozásához szükséges tranzakció körülbelül 3-5 másodpercig tarthat.
A táblázatokban szereplő adatok nem mindig voltak a legmegfelelőbb formában. Valahol denormalizálást kellett végezni. A rendszeresen kapott adatok egy része XML-struktúra formájában egy oszlopban volt, ami megnövelte a végrehajtási időt, meghosszabbította a lekérdezéseket és bonyolult fejlesztést.
Ugyanazok a táblázatok vonatkoztak nagyon heterogén kérések. Különösen érintettek a népszerű asztalok, mint például a fent említett táblázat rendelés vagy táblázatok pizzéria. A konyhai működési felületek és az analitika megjelenítésére szolgáltak. Az oldal fel is vette velük a kapcsolatot (), ahol hirtelen sok kérés érkezhet egy adott időpontban.
Az adatok nem voltak összesítve és sok számítás menet közben történt az alap segítségével. Ez szükségtelen számításokat és további terhelést eredményezett.
A kód gyakran akkor került be az adatbázisba, amikor nem tudta volna megtenni. Valahol hiányoztak a tömeges műveletek, valahol egy kérést több kódra kellett felosztani a gyorsítás és a megbízhatóság növelése érdekében.
Kohézió és zűrzavar a kódban
Azok a modulok, amelyeknek a maguk üzletrészéért kellett volna felelniük, nem tették ezt becsületesen. Némelyikük a szerepek megkettőzésével rendelkezett. Például egy helyi marketingesnek, aki a városában egy hálózat marketingtevékenységéért felelős, mind az „Adminisztrációs” felületet (promóciók beállításához), mind az „Office Manager” felületet (a promóciók üzleti). Természetesen mindkét modulon belül ugyanazt a szolgáltatást használtuk, ami bónuszpromóciókkal működött.
A szolgáltatások (egy monolitikus nagy projekten belüli osztályok) felhívhatják egymást, hogy gazdagítsák adataikat.
Magukkal az adatokat tároló modellosztályokkal, a kódban végzett munka másként történt. Valahol voltak olyan konstruktorok, amelyeken keresztül meg lehetett adni a kötelező mezőket. Valahol ez nyilvános ingatlanokon keresztül történt. Természetesen az adatbázisból való adatok beszerzése és átalakítása változatos volt.
A logika vagy a vezérlőkben vagy a szolgáltatási osztályokban volt.
Ezek apróbb problémáknak tűnnek, de nagymértékben lelassították a fejlesztést és csökkentették a minőséget, ami instabilitáshoz és hibákhoz vezetett.
A nagy fejlesztés összetettsége
Magában a fejlesztésben adódnak nehézségek. A rendszer különböző blokkjait kellett létrehozni, és párhuzamosan. Egyre nehezebbé vált az egyes komponensek igényeinek egyetlen kódba illesztése. Nem volt könnyű megállapodni, és egyszerre minden alkotóelemnek tetszett. Ehhez járultak a technológiai korlátok, különösen az alap és az előlap tekintetében. Fel kellett hagyni a JQuery-vel a magas szintű keretrendszerek javára, különösen az ügyfélszolgáltatások (weboldal) tekintetében.
A rendszer egyes részei használhatnak erre alkalmasabb adatbázisokat. Például később volt rá példa, hogy Redisről CosmosDB-re váltottunk a rendelési kosár tárolására.
A szakterületükön dolgozó csapatok és fejlesztők egyértelműen nagyobb függetlenséget kívántak szolgáltatásaik számára, mind a fejlesztés, mind a bevezetés tekintetében. Konfliktusok egyesítéskor, problémák kiadások során. Ha 5 fejlesztő számára ez a probléma jelentéktelen, akkor 10-nél, és még inkább a tervezett növekedéssel minden komolyabbá válna. És ami következett, az egy mobilalkalmazás fejlesztése volt (2017-ben kezdődött, 2018-ban pedig ).
A rendszer különböző részei eltérő stabilitásjelzőket igényeltek, de a rendszer erős csatlakoztathatósága miatt ezt nem tudtuk biztosítani. Egy hiba az adminisztrációs panelen egy új funkció fejlesztésekor akár megrendelés elfogadást is eredményezhetett volna az oldalon, mert a kód közös és újrafelhasználható, az adatbázis és az adatok is ugyanazok.
Valószínűleg el lehetne kerülni ezeket a hibákat és problémákat egy ilyen monolitikus-moduláris architektúra keretein belül: a felelősségi körök szétválasztását, a kód és az adatbázis refaktorálását, a rétegek világos elkülönítését egymástól, és a minőség mindennapi monitorozását. A választott építészeti megoldások és a rendszer funkcionalitásának gyors bővítésére való összpontosítás azonban stabilitási problémákhoz vezetett.
Hogyan helyezte el a Power of Mind blog a pénztárgépeket az éttermekben
Ha a pizzériahálózat (és a terhelés) növekedése ugyanilyen ütemben folytatódna, akkor egy idő után olyan mértékűek lennének a visszaesések, hogy nem áll helyre a rendszer. A következő történet jól szemlélteti azokat a problémákat, amelyekkel 2015-re szembesülni kezdtünk.
A blogban""Volt egy widget, amely az év bevételi adatait jelenítette meg a teljes hálózatra vonatkozóan. A widget hozzáfért a nyilvános Dodo API-hoz, amely ezeket az adatokat szolgáltatja. Ezek a statisztikák már elérhetők a következő helyen: . A widget minden oldalon látható volt, és 20 másodpercenként kért egy időzítőt. A kérés az api.dodopizza.ru oldalra ment, és megkérdezte:
-
pizzériák száma a hálózatban;
-
teljes hálózati bevétel az év eleje óta;
-
a mai bevétel.
A bevételi statisztikák iránti kérés egyenesen az adatbázisba érkezett, és elkezdett adatokat kérni a rendelésekről, közvetlenül összesíteni az adatokat, és kiadni az összeget.
Az éttermek pénztárgépei ugyanabba a rendelési táblázatba kerültek, feltöltötték a mára elfogadott rendelések listáját, és új rendelések kerültek rá. A pénztárak 5 másodpercenként, vagy az oldal frissítésekor adták le kéréseiket.
A diagram így nézett ki:
Egy őszi napon Fjodor Ovcsinnyikov hosszú és népszerű cikket írt a blogján. Sokan felkeresték a blogot, és elkezdtek mindent figyelmesen elolvasni. Amíg a megjelentek mindegyike olvasta a cikket, a bevételi widget megfelelően működött, és 20 másodpercenként kérte az API-t.
Az API tárolt eljárást hívott be, hogy kiszámítsa az év eleje óta a hálózat összes pizzériájára vonatkozó összes rendelés összegét. Az összesítés a rendelési táblázat alapján történt, amely nagyon népszerű. Az összes akkoriban nyitva tartó étterem összes pénztárgépe oda megy. A pénztárgépek nem válaszoltak, a rendeléseket nem fogadták el. Az oldalról sem vették át, nem jelentek meg a nyomkövetőn, és a műszakvezető sem láthatta őket a felületén.
Nem ez az egyetlen történet. 2015 őszén minden pénteken kritikus volt a rendszer terhelése. Többször kikapcsoltuk a nyilvános API-t, egyszer pedig még az oldalt is ki kellett kapcsolnunk, mert semmi sem segített. Még a szolgáltatások listája is szerepelt, nagy terhelés esetén a leállítás sorrendjében.
Ettől kezdve megkezdődik a harcunk a terhelésekkel és a rendszer stabilizálásáért (2015 őszétől 2018 őszéig). Ekkor történt"" Ezen túlmenően időnként meghibásodások is előfordultak, amelyek közül néhány nagyon érzékeny volt, de az általános instabilitás immár lezárultnak tekinthető.
Gyors üzleti növekedés
Miért ne lehetne „azonnal jól csinálni”? Csak nézze meg a következő grafikonokat.
Szintén 2014-2015-ben volt egy romániai nyitás, és egy USA-beli nyitás is készült.
A lánc nagyon gyorsan növekedett, új országok nyíltak, új pizzériák jelentek meg, például pizzéria nyílt az étteremben. Mindez jelentős figyelmet igényelt kifejezetten a Dodo IS funkcióinak bővítésére. Mindezen funkciók nélkül, a konyhában történő nyomon követés, a termékek és veszteségek rendszerben történő elszámolása, a rendelések kiszállításának az élelmiszerbírósági csarnokban való megjelenítése nélkül nem valószínű, hogy most a „helyes” architektúráról és a „helyesről” beszélnénk. ” fejlesztési megközelítés.
Az architektúra időben történő felülvizsgálatának és a műszaki problémák általános figyelemének másik akadálya a 2014-es válság volt. Az ilyen dolgok rontják a csapatok növekedési lehetőségeit, különösen egy olyan fiatal vállalkozás esetében, mint a Dodo Pizza.
Gyors megoldások, amik segítettek
A problémák megoldást igényelnek. Hagyományosan a megoldások 2 csoportra oszthatók:
-
Gyorsak, amelyek eloltják a tüzet, és egy kis biztonságot adnak nekünk, és időt nyerünk az átöltözésre.
-
Szisztémás és ezért hosszú. Számos modul újratervezése, a monolitikus architektúra külön szolgáltatásokra osztása (legtöbbjük nem mikro, hanem makroszolgáltatás, és erről van még szó ).
A gyors változtatások száraz listája a következő:
Bázismester felnagyítása
Természetesen a terhelés elleni küzdelem első lépése a szerver teljesítményének növelése. Ez a fő adatbázis és a webszerverek esetében történt. Sajnos ez csak egy bizonyos határig lehetséges, azon túl már túl drágává válik.
2014 óta az Azure-ba költöztünk, erről a témáról is írtunk akkor a „" A szerveremelések sorozata után azonban az alap költsége elérte a határt.
Adatbázis replikák olvasáshoz
Két replikát készítettünk az alaphoz:
Replika olvasása címtárkérésekhez. Könyvtárak olvasására használják, mint város, utca, pizzéria, termékek (lassan változott domain), illetve azokon a felületeken, ahol kis késés is elfogadható. Ebből 2 replika volt, ezek elérhetőségét ugyanúgy biztosítottuk, mint a master.
ReadReplica jelentéskéréshez. Ennek az adatbázisnak gyengébb volt az elérhetősége, de minden jelentés hozzá ment. Előfordulhat, hogy hatalmas adat-újraszámításokat igényelnek, de ezek nem érintik a fő adatbázist és a működési felületeket.
Gyorsítótárak a kódban
Sehol nem volt gyorsítótár a kódban (egyáltalán). Ez további, nem mindig szükséges kérésekhez vezetett a betöltött adatbázishoz. Eleinte a gyorsítótárak a memóriában és egy külső gyorsítótár szolgáltatásban is voltak, ez volt a Redis. Minden időérvénytelen volt, a beállításokat megadták a kódban.
Több szerver háttérrendszerhez
Az alkalmazás hátterét is méretezni kellett, hogy ellenálljon a megnövekedett terhelésnek. Egy IIS szerverből kellett fürtöt készíteni. Költöztünk a RedisCache memóriájából, ami lehetővé tette több szerver létrehozását egy egyszerű terheléselosztó mögé. Eleinte ugyanazt a Redis-t használták, mint a gyorsítótáraknál, majd több részre osztották őket.
Ennek eredményeként az építészet összetettebbé vált...
...de a feszültség egy része enyhült.
Utána pedig újra kellett csinálni a betöltött komponenseket, amit mi vállaltunk. A következő részben erről fogunk beszélni.
Forrás: will.com