Dodo IS arhitektuuri ajalugu: varajane monoliit

Iga ebaõnnelik ettevõte on ebaõnnelik omal moel.

Dodo IS süsteemi arendamine algas kohe, kui Dodo Pizza äri — 2011. aastal. Aluseks oli idee täiesti ja absoluutselt digitaliseerida äriprotsessid, oma jõududega, mis tekitas juba 2011. aastal palju küsimusi ja skeptitsismi. Kuid nüüdseks, 9 aastat hiljem, järgime seda teed — oma arendusega, mis algas monoliidist.

See artikkel on "vastus" küsimusele "Miks kirjutada arhitektuur ümber ja teha nii suured ja pikaajalised muudatused?" eelmisele artiklile "Dodo IS arhitektuuri ajalugu: back-office'i tee".Alustan sellega, kuidas Dodo IS arendus algas, milline oli algne arhitektuur, kuidas ilmusid uued moodulid ja milliste probleemide tõttu tuli teha ulatuslikke muudatusi.

Artiklite seeria „Mis on Dodo IS?” räägib:

1. Varane monoliit Dodo IS-is (2011-2015). (Oled siin)

2. Tagavarahalduri tee: eraldi andmebaasid ja buss..

3. Kliendiosakonna tee: fassaad andmebaasi kohal (2016-2017). (Töös…)

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

5. Monoliidi lõplik jagamine ja arhitektuuri stabiliseerimine. (Töös…)

Algne arhitektuur

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

Esimene moodul arhitektuuris — tellimuse vastuvõtt. Äri protsess oli järgmine:

• klient helistab pitsarestorani;

• toru võtab vastu juht;

• võtab telefoni teel tellimuse;

• samal ajal sisestatakse see tellimuste vastuvõtu liideses: arvesse võetakse kliendi teavet, tellimuse üksikasju ja kohaletoimetamise aadressi. 

Infotehnoloogia süsteem nägi välja umbes nii…

Esimene versioon oktoobrist 2011:

Veidi parendatud jaanuaris 2012

Dodo Pizza Kojuvedu Pizza Restoran infotehnoloogia süsteem

Esimese tellimuste vastuvõtu mooduli arendamiseks olid ressursid piiratud. Pidi kiiresti palju tegema ja väikese meeskonnaga. Väike meeskond — 2 arendajat, kes asetasid kogu tulevase süsteemi aluse.

Nende esimene lahendus määras tehnoloogia virna edasise saatuse:

• Backend ASP.NET MVC-s, keel C#. Arendajad olid .NET-i spetsialistid, see virn oli neile tuttav ja meeldiv.

• Frontend Bootstrap'i ja JQuery peal: kasutajaliidesed omatehtud stiilide ja skriptidega. 

• Andmebaas MySQL: ilma litsentsikuludeta, lihtne kasutada.

• Serverid Windows Serveril, kuna .NET-i sai tol ajal kasutada ainult Windowsi all (Mono arutelu jätame välja).

Füüsiliselt väljendus see "dedikeeritud serveris hostimisettevõttes". 

Tellimuste vastuvõtu rakenduse arhitektuur

Siis räägiti juba mikroteenustest, samas kui SOA-d on suurtel projektidel kasutatud umbes 5 aastat, näiteks WCF tuli välja 2006. aastal. Kuid siis valiti usaldusväärne ja tõestatud lahendus.

Siin see on.

Asp.Net MVC on Razor, mis genereerib serveri poolt värske HTML-lehe päringu alusel forma või kliendi poolelt. Kliendis kasutavad juba CSS ja JS-skriptid teabe kuvamiseks ning vajadusel teevad nad AJAX-päringuid läbi JQuery.

Päringud jõuavad serveris klassidesse *Controller, kus meetodis toimub töötlemine ja lõpp-HTML-lehe genereerimine. Kontrollereid kasutatakse loogikatasemele, mida nimetatakse *Services. Iga teenus vastas mõnele äri aspektile:

• Näiteks DepartmentStructureService pakkus teavet pitsakodade ja osakondade kohta. Osakond on grupp pitsakodasid, mida juhib üks frantsiisiomanik.

• ReceivingOrdersService võttis vastu ja arvestas tellimuste sisu.

• SmsService saatis SMS-e, kutsudes sms-saatmise API-teenuseid.

Teenused töötlesid andmeid andmebaasist, hoidsid äriloogikat. Igas teenuses oli üks või mitu *Repository vastava nimega. Neis olid juba päringud salvestatud protseduuridele andmebaasis ja maappeeringu kiht. Salvestatud protseduurides oli äriloogika, eriti palju neist, mis väljastasid aruandeandmeid. ORM-i ei kasutatud, kõik usaldasid käsitsi kirjutatud SQL-i. 

Veel oli olemas domeenimudeli ja üldiste abiklasside kiht, näiteks klass Order, mis hoidis tellimust. Samuti, selles kihis, oli abi teksti kuvamise muutmiseks valitud valuuta järgi.

Kogu seda saab esitada sellise mudelina:

Tellimuse tee

Vaatame lihtsustatud algset teed sellise tellimuse loomiseks.

Alguses oli sait staatiline. Seal olid hinnad, üleval oli telefoninumber ja üleskutse „Soovid pitsat — helista numbrile ja telli”. Tellimuse jaoks peame rakendama lihtsa voolu: 

• Klient siseneb staatilisele veebisaidile hindadega, valib tooted ja helistab numbrile, mis on saidil märgitud.

• Klient nimetab tooted, mida ta soovib tellimusele lisada.

• Nimetab oma aadressi ja nime.

• Operaator võtab tellimuse vastu.

• Tellimus kuvatakse vastuvõetud tellimuste liideses.

Kõik algab menüü kuvamisest. Sisselogitud operaator aktsepteerib samal ajal vaid ühte tellimust. Seetõttu võib eelnõukorv olla tema sessioonis (kasutaja seanss salvestatakse mällu). Seal on objekt Cart, mis sisaldab tooteid ja klientide teavet.

Klient nimetab tootega, operaator klõpsab + toote kõrval, ja serverile saadetakse päring. Toote kohta tõmmatakse andmed andmebaasist ja lisatakse tooteinfo korvi.

Märkus. Jah, siit ei ole tingimata vajalik toodet andmebaasist välja tõmmata, vaid seda võib edastada frontendist. Kuid selguse huvides näitasin just andmebaasist saadud teed. 

Seejärel sisestame kliendi aadressi ja nime. 

Nupu „Loo tellimus” vajutamisel:

• Saadame päringu OrderController.SaveOrder().

• Saame Cart sessioonist, seal on tooted soovitud koguses.

• Täiendame Cart'i kliendiinfoga ja edastame ReceiveOrderService klassi AddOrder meetodisse, kus see salvestatakse andmebaasi. 

• Andmebaasis on tabelid tellimuse, tellimuse koostisosade ja kliendi kohta ning need kõik on omavahel seotud.

• Tellimuse kuvamise liides käib ja tõmbab viimased tellimused välja ning kuvab need.

Uued moodulid

Tellimuste vastuvõtt oli oluline ja vajalik. Pizza müügiäri ei saa toimida, kui tellimuste vastuvõttu pole. Seetõttu hakkas süsteem funktsioone koguma — umbes aastatel 2012 kuni 2015. Selles ajavahemikus tekkis palju erinevaid süsteemi blokke, mida ma hakkan nimetama mooduliteks, vastandina teenuse või toote mõistele. 

Moodul on funktsioonide kogum, mis on ühendatud mingi ühise ärieesmärgiga. Samal ajal asuvad nad füüsiliselt ühes ja samas rakenduses.

Mooduleid võib nimetada süsteemi blokiks. Näiteks on olemas aruande moodul, haldustäidise liidese toiduainete jälgija köögis, autoriseerimine. Need kõik on erinevad kasutajaliidesed, mõnedel on isegi erinevad visuaalsed stiilid. Samas on need kõik ühe rakenduse ja ühe tööprotsessi raames. 

Tehniliselt kujundati moodulid kui Area (selline idee on isegi säilinud asp.net core). Seal olid eraldi failid frontend'i, mudelite ja ka oma kontrollklassi jaoks. Tulemuseks oli süsteemi muutumine sellisest…

…selliseks:

Mõned moodulid on ellu viidud eraldi saitidega (executable project), kuna need täidavad väga erilisi funktsioone ja osaliselt seetõttu, et nende arendamine oli paar korda eraldi, enamasti fookustatud. Need on:

• Veebileht. — esimene versioon dodobizza.ru saidist.

• Export: raportite eksportimine Dodo IS-st 1C-le. 

• Isiklik — töötaja isiklik konto. See on arendatud eraldi ning omab oma sisenemispunkti ja eraldi disaini.

• fs — projekt staatika hostimiseks. Hiljem loobusime sellest, viies kogu staatika CDN Akamai-le. 

Ülejäänud plokid olid rakenduses BackOffice. 

Selgitus nimede kohta:

• Cashier — restorani kassasüsteem.

• ShiftManager — liideseid rollile "Vahtkonnamanager": operatiivne statistika pitsarestorani müükidest, võimalus tooteid musta nimekirja lisada, tellimuse muutmine.

• OfficeManager — liideseid rollile "Pitsarestorani juht" ja "Frantsiisi valdaja". Siin on koondatud funktsioonid pitsarestorani seadistamiseks, selle lojaalsusprogrammide korraldamiseks, töötajate vastuvõtmiseks ja nendega töötamiseks, aruannete haldamiseks.

• PublicScreens — liideseid televiisoritele ja tahvelarvutitele, mis on paigaldatud pitsarestoranides. Televisioonidel kuvatakse menüü, reklaamteave ja tellimuse staatus väljastamisel. 

Nad kasutasid ühist teenuste kihti, ühte domeenide klasside plokki Dodo.Core ning ka ühist andmebaasi. Mõnikord võisid nad vahetada teavet üksteisega, sealhulgas kasutasid eraldi saidid, nagu dodopizza.ru või personal.dodopizza.ru, ka ühiseid teenuseid.

Uute moodulite ilmumise korral püüdsime maksimaalselt taaskasutada juba loodud teenuste koodi, salvestatud protseduure ja andmebaasi tabeleid. 

Moodulite ulatuse paremaks mõistmiseks on siin 2012. aasta plaanide arenguskeem:

Aastaks 2015 oli kõik skeemil ja isegi rohkem tootmises.

• Tellimise vastuvõtt on kasvanud eraldi Kontaktikeskuse plokiks, kus tellimust võtab vastu operaator.

• Ilmusid avalikud ekraanid menüü ja teabega, mis ripuvad pitsakohvikutes.

• Köögis on moodul, mis automaatselt edastab häälsõnumi 'Uus pitsa', kui uus tellimus saabub, ning printib saatjale saatekirja. See lihtsustab oluliselt köögi protsesse, võimaldades töötajatel mitte häirida end lihtsate toimingutega.

• Transportiblokk muutus eraldi transportkassaks, kus tellimus üle anti kullerile, kes eelnevalt vahetusse asus. Tema tööaeg arvestati palga määramiseks. 

Ajavahemikul 2012–2015 tuli juurde üle 10 arendaja, avati 35 pitsakohvikut, süsteem laiendati Rumeeniasse ja valmistati ette avamiseks USA-s. Arendajad ei tegelenud enam kõigi ülesannetega, vaid jagunesid meeskondadesse, kus igaüks spetsialiseerus oma süsteemi osale. 

Probleemid

Sealhulgas arhitektuuri tõttu (aga mitte ainult).

Kaos andmebaasis

Üks andmebaas on mugav. Seal saab saavutada ühtsust, kasutades relatsiooniliste andmebaaside sisse ehitatud vahendeid. Töö sellega on tuttav ja mugav, eriti kui andmebaasis on vähe tabeleid ja andmeid.

Kuid 4 aastaga arendamisel oli andmebaasis umbes 600 tabelit, 1500 salvestatud protseduuri, milles paljudel oli ka loogika. Kahjuks ei paku salvestatud protseduurid MySQL-iga töötamisel erilisi eeliseid. Need ei salvestu andmebaasi vahemällu ja loogika hoidmine neis keerustab arendust ja tõrkeotsingut. Koodi taaskasutamine on samuti keeruline.

Paljudes tabelites ei olnud sobivaid indekseid., kus oli liiga palju indekseid, mis raskendas lisamist. Oli vaja modifitseerida umbes 20 tabelit — tellimuse loomise tehing võis kesta umbes 3-5 sekundit. 

Andmed tabelites ei olnud alati kõige sobivamas vormis.. Kusagil oli vaja teha denormaliseerimist. Osa regulaarselt saadud andmeid oli veergudes XML-struktuurina, mis pikendas täitmise aega, pidas pikemaid päringuid ja raskendas arendust.

Üksikutele tabelitele tehti väga ebahomoogeenseid päringuid.. Eriti kannatasid populaarsed tabelid, nagu eelmainitud tabel orders või tabel pizzeria. Neid kasutati köögis operatiivsete liideste väljundiks, analüütikaks. Veel pöördus nende poole veebisait (dodopizza.ru), kuhu võis igal ajal peale tulla ootamatult palju päringuid. 

Andmed ei olnud aggregeeritud ja palju arvutusi toimus lennu peal andmebaasi vahenditega. See tekitas liigseid arvutusi ja lisakoormust. 

Kood käis tihti andmebaasis siis, kui tal ei oleks olnud seda teha. Kusagil puudusid bulk-operatsioonid, kusagil tuli üks päring jagada mitmeks, et kiirus ja usaldusväärsus tõuseksid. 

Seotust ja segadust koodis

Modulid, mis pidanuks vastutama oma äriosa eest, ei täitnud oma ülesandeid õigesti. Mõned neist dubleerivad funktsioone rollide osas. Näiteks kohalik turundaja, kes vastutab oma linna võrgustiku turundustegevuse eest, pidi kasutama nii "Admini" liidest (kampaaniate seadistamiseks) kui ka "Kontori Juhi" liidest (kampaaniate mõju jälgimiseks äri jaoks). Loomulikult kasutasid mõlemad moodulid seesama teenus, mis töötas boonuste kampaaniatega.

Teenused (klassid ühe monoliitse suurprojekti raames) võisid üksteist kutsuda, et rikastada oma andmeid.

Klassidega mudelid, mis andmeid salvestavad, koodis töötamine käis erinevalt. Kusagil olid konstruktorid, mille kaudu sai määrata nõutavad väljad. Mõnes kohas tehti seda avalike omaduste kaudu. Loomulikult oli andmete saamine ja töötlemine andmebaasist mitmekesine. 

Loogika oli kas kontrollerites või teenuseklassides. 

Need võivad tunduda ebaolulised probleemid, kuid need takistasid arendust oluliselt ja halvasid kvaliteeti, mis tõi kaasa ebastabiilsuse ja vead. 

Suurte arenduste keerukus

Raskused tekkisid ka arenduse enda juures. Oli vaja luua erinevaid süsteemiblokke ja veel parelleelselt. Iga komponendi vajaduste mahutamine ühte koodi muutus üha keerulisemaks. Ei olnud lihtsalt kokku leppida ja kõigile komponentidele üheaegselt meeldida. Sellele lisandusid tehnoloogilised piirangud, eriti andmebaasi ja frontendi osas. Oli vaja loobuda JQuery'st kõrgematasemelistest raamistikest, eriti kliendiserviidest (veebileht).

Mõnes süsteemi osas oleks pidanud kasutama andmebaase, mis sobivad sellele paremini. Näiteks hiljem oli meil pretsedent, kus üleminekul Rediselt CosmosDB'le tellimuse korvi hoidmiseks. 

Arendajad ja arendajad, kes töötavad oma valdkonnas, soovisid selgelt suuremat iseseisvust oma teenuste osas, nii arendamise kui ka väljalaskmise osas. Ühendamise konfliktid, probleemid väljalaskmise ajal. Kui 5 arendaja jaoks ei ole see probleem oluline, siis 10 puhul, rääkimata plaanitud kasvust, muutub kõik tõsisemaks. Ja ees ootas mobiilirakenduse arendamine (see algas 2017. aastal ja 2018. aastal oli suur langus). 

Süsteemi erinevad osad nõudsid erinevaid stabiilsuse näitajaid, kuid süsteemi tugeva seotuse tõttu ei suutnud me seda tagada. Uue funktsiooni arendamise viga administraatori paneelis võis täiesti halba mõju avaldada veebisaidi tellimuste vastuvõtmisel, kuna kood on ühine ja taaskasutatav, andmebaas ja andmed on samuti ühtsed.

Tõenäoliselt oleks ka sellise monoliitne-moodulaarse arhitektuuri raames neid vigu ja probleeme vältida: vastutuse jagamine, nii koodi kui ka andmebaasi refaktooring, kihtide selge eraldamine, iga päev kvaliteedi jälgimine. Kuid valitud arhitektuuriotsused ja keskendumine süsteemi funktsionaalsuse kiirele laienemisele viisid stabiilsuse probleemideni.

Kuidas blogi Silla jõud pani restoranidesse kassad

Kui pitsakett (ja koormus) oleks kasvanud sama tempoga, siis mõne aja pärast oleks kukkumised olnud sellised, et süsteem ei tõusenud enam üles. Hea illustratsioon problematikast, millega me 2015. aastal alguse saime, on selline lugu. 

Blogis „Silla jõud“ oli vidin, mis näitas kogu võrgu aastakäibe andmeid. Vidin pöördus avaliku API poole, mille Dodo need andmed pakub. Nüüd on see statistika saadaval http://dodopizzastory.com/. Vidin kuvati igal lehel ja tegi taotlusi igal 20 sekundi järel. Taotlus läks aadressile api.dodopizza.ru ja küsis:

• pitsakettide arv võrkus;

• kogu võrgu käive alates aastast;

• käive täna.

Tuludestatistikate päring läks otse andmebaasi, alustades tellimuste andmete kogumist reaalajas ja arvutades kokku. 

Sama tellimuste tabelisse said ka restoranide kassad, mis laadisid üles tänaseks päevaks vastu võetud tellimuste loendi ning sinna lisandusid uued tellimused. Kassad tegid päringuid iga 5 sekundi tagant või lehe värskendamisel.

Schema nägi välja selline:

Üks sügis, Fëdor Ovčinnikov kirjutas oma blogisse pika ja populaarse artikli. Blogisse tuli palju inimesi, kes hakkasid seda tähelepanelikult lugema. Kui iga külaline artiklit luges, töötas tulude vidin korralikult ja küsis API-d iga 20 sekundi tagant.

API kutsus välja salvestatud protseduuri, et arvutada välja kõikide tellimuste summa aasta algusest kõigis ketipitsakohvikutes. Agregatsioon toimus tellimuste tabelis, mis oli väga populaarne. Sellesse laadisid kõik avatud restoranide kassad selle aja jooksul. Kassad lakkasid vastamast, tellimusi ei võetud vastu. Samuti ei võetud tellimusi vastu veebilehelt, need ei ilmunud jälgijasse, vahetuse juhataja ei näinud neid oma liideses. 

See ei ole ainus lugu. 2015. aasta sügiseks oli iga reede süsteemile kriitiline koormus. Mitmel korral pidime avaliku API välja lülitama, ja korra pidime isegi saidi välja lülitama, sest mitte miski ei aidanud. Oli isegi teenuste nimekiri, kus oli kirjas väljalülitamise kord tõsiste koormuste korral.

Sellest ajast alates algas meie võitlus koormustega ja süsteemi stabiliseerimise nimel (2015. aasta sügisest kuni 2018. aasta sügiseni). Just siis juhtus "Suure langus". Edasi liikudes toimusid mõnikord veel tõrked, mõned olid üsna tunded, kuid üldiselt saab nüüd seda ebastabiilsuse perioodi pidada möödundiks.

Ärimahtude tormiline kasv

Miks ei saanud "kõike kohe hästi teha"? Piisab, kui vaadata järgmisi graafikuid.

Samuti avati 2014-2015 Rumeenias ning valmistuti avamiseks Ameerika Ühendriikides.

Võrk kasvas väga kiiresti, avanesid uued riigid, ilmusid uued pitsarestoranide vormid, näiteks avati pitsarestoran toidutänaval. Kõik see nõudis Dodo IS funktsionaalsuse laienemisele märkimisväärset tähelepanu. Ilma nende funktsioonideta, ilma köögis jälgimiseta, toidu ja kahjude arvestamiseta süsteemis, tellimuse esituse kuvamiseta toidutänaviga, ei arutaks me nüüd "õige" arhitektuuri ja "õige" lähenemise üle arendusele.

Teiseks takistuseks arhitektuuri õigeaegsele ülevaatamisele ja tehnilistele probleemidele oli 2014. aasta kriis. Sellised asjad mõjutavad valusalt tiimide kasvuvõimalusi, eriti noore äri puhul, nagu Dodo Pizza.

Kiired lahendused, mis aitasid

Probleemid nõudsid lahendust. Üldiselt võib lahendused jagada kaheks grupiks:

• Kiired, mis kustutavad tule ja annavad meile väikese vastupidavuse ning võidavad aega muudatuste tegemiseks.

• Süsteemsed ja seetõttu pikaajalised. Mitmete moodulite ümberkujundamine, monoliitse arhitektuuri jagamine eraldi teenusteks (enamiku neist ei ole mikro, vaid pigem makroteenused ja selle kohta on Andrei Morevski ettekanne). 

Kiirete muudatuste kuiv nimekiri on järgmine:

Mastaabi suurendamine meistribaasi jaoks

Muidugi, esimesena suurendatakse serveri võimsust, et võidelda koormustega. Seda tehti meistribaasi ja veebiserverite jaoks. Kahjuks on see võimalik ainult teatud piirini, edasi muutub see liiga kulukaks.

Alates 2014. aastast oleme läinud Azure'i, sellest kirjutasime ka toona artiklis „Kuidas Dodo Pizza toimetab pitsat Microsoft Azure'i pilve abil“. Aga pärast serveri võimsuse järkjärgulist suurendamist lõppesime kuludega. 

Lugemiseks mõeldud andmebaasi koopiad

Andmebaasist tehti kaks koopiat:

ReadReplica andmebaasi päringute jaoks. Seda kasutatakse näiteks linnade, tänavate, pitsade ja toidu (aeglaselt muudetud domeen) loetelude lugemiseks, ning seal, kus on lubatud väike viivitus. Neid koopiaid oli kaks ja tagasime nende kättesaadavuse sama hästi kui meistribaasi.

ReadReplica aruannete päringute jaoks. Sellel andmebaasil oli madalam kättesaadavus, kuid sinna said kõik aruanded. Olgu, et neil on rasked päringud suurte andmete ümberarvutamiseks, kuid need ei mõjuta peamist andmebaasi ja operatiivliideseid. 

Kohandatud vahemälud koodis

Koodis ei olnud kuhugi vahemälusid (üldse). See tõi kaasa täiendavad, mitte alati vajalikud, päringud koormatud andmebaasi. Vahemälud olid alguses nii mälus kui ka välises vahemäles, milleks oli Redis. Kõik kehtivuse aegunud ajaga, seaded määrati koodis.

Mõned serverid tagaplaaniks

Ka rakenduse tagaplaan tuli suurendada, et taluda suurenenud koormust. Ühe iis-serveri põhjal tuli luua klaster. Ümber kolisime rakenduste sessiooni RedisCache'i, mis võimaldas luua mitu serverit, mis seisavad lihtsa koormuse tasakaalustaja taga round robin süsteemis. Alguses kasutati sama Redis'i, mis vahemälude jaoks, hiljem jagati see mitme peale. 

Lõpptulemusena arhitektuur komplikeerus...

…aga osa pinget õnnestus leevendada.

Järgmine samm oli koormatud komponente ümber teha, millega me ka tegeleme. Sellest räägime järgmises osas.

Allikas: habr.com