Dodo IS arhitektuuri ajalugu: varajane monoliit

Või on iga õnnetu ettevõte monoliidiga oma moodi õnnetu.

Dodo IS süsteemi arendamine algas samal ajal, kui Dodo Pizza äri — 2011. aastal. Aluseks oli idee äri protsesside täielikust ja totaalsest digitaliseerimisest, ja oma jõududega, mis tekitas juba 2011. aastal palju küsimusi ja skeptitsismi. Kuid nüüd, juba 9 aastat, oleme liikunud sellistel radadel — oma tarkvara arendamisega, mis algas monoliidiga.

See artikkel on "vastus" küsimustele "Miks ümberehitada arhitektuuri ja teha selliseid ulatuslikke ja pikaajalisi muudatusi?" eelnevale artiklile "Dodo IS arhitektuuri ajalugu: back-office’i tee". Alustan sellest, kuidas Dodo IS-i arendamine algas, milline oli algne arhitektuur, kuidas uued moodulid ilmusid ja milliste probleemide tõttu tuli läbi viia ulatuslikud muudatused.

Artiklite sari "Mis on Dodo IS?" räägib:

1. Varajane monoliit Dodo IS-is (2011-2015). (Sa oled siin)

2. Back-office’i tee: eraldi andmebaasid ja buss.

3. Kliendi osa tee: fassaad andmebaasi kohal (2016-2017). (Töös...)

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

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

Algne arhitektuur

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

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

• klient helistab pitsarestorani;

• toru võtab vastu haldur;

• vastuvõtt tellimus telefonitsi;

• samal ajal sisestab selle tellimuse vastuvõtu liidesesse: arvesse võetakse kliendi teavet, tellimuse detailide andmeid ja kohaletoimetamise aadressi. 

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

Esimene versioon oktoobrist 2011:

Veidi parendatud jaanuaris 2012

Dodo Pizza Informatsioonisüsteem Delivery Pizza Restaurant

Esimese tellimuse vastuvõtu mooduli arendamise ressursid olid piiratud. Oli vaja teha palju, kiiresti ja väikeses koosseisus. Väike koosseis — 2 arendajat, kes panid aluse kogu edasisele süsteemile.

Nende esimene lahendus määras tehnoloogia stack’i edasise saatuse:

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

• Frontend Bootstrapil ja JQuery-l: kasutajaliideste loomine isekirjutatud stiilide ja skriptidega. 

• Andmebaas MySQL: ilma litsentsikuludeta, lihtne kasutada.

• Windows Serveri serverid, kuna .NET töötas ainult Windowsi all (Mono mehhanismist ei hakka rääkima).

Füüsiliselt väljendus see kõik hostimisettevõtte 'dedikes'. 

Tellimuse vastuvõtmise rakenduse arhitektuur

Tollal räägiti juba mikroteenustest, samas kui SOA-d on kasutatud suurtes projektides umbes 5 aastat, näiteks WCF ilmus 2006. aastal. Kuid toona valiti usaldusväärne ja testitud lahendus.

Siin see on.

Asp.Net MVC — see on Razor, mis vormi või kliendi päringu põhjal genereerib serveris HTML-lehe renderdamisega. Kliendis kuvatakse seejärel CSS ja JS skriptidest teave ning vajadusel tehakse AJAX-päringud läbi JQuery.

Päringud serveris jõuavad *Controller klassidesse, kus meetodis toimub töötlemine ja lõpliku HTML-lehe genereerimine. Kontrollerid teevad päringud loogika kihile, mida nimetatakse *Services. Iga teenus vastas mingile äri aspektile:

• Näiteks pakkus DepartmentStructureService teavet pitsakodade ja osakondade kohta. Osakond on grupi pitsakodade haldamine ühe frantsiisiga.

• ReceivingOrdersService võttis vastu ja arvutas tellimuste koostise.

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

Teenused töötlesid andmeid andmebaasist ja hoidsid äri loogikat. Igas teenuses oli üks või mitu *Repository vastava nimetusega. Nendes sisaldusid päringud andmebaasi salvestatud protseduuride ja kaardistamiskihtide kohta. Salvestatud protseduurides oli äriloogikat, eriti palju neist, mis andsid välja aruande andmed. ORM-i ei kasutatud, kõik toetusid käsitsi kirjutatud SQL-ile. 

Samuti oli olemas domeenimudel ja üldised abiklassid, näiteks Order klass, mis hoidis tellimust. Seal oli samas ka abimees, mis muundas kuvamisteksti valitud valuuta alusel.

Kõike seda on võimalik kujutada järgmise mudelina:

Tellimuse tee

Käsitleme lihtsustatud esialgset tellimuse loomise teed.

Alguses oli sait staatiline. Seal olid hinnad, ja üleval oli telefoninumber koos tekstiga 'Tahad pitsat — helista numbrile ja telli.' Tellimuse jaoks on meil vaja rakendada lihtne voog: 

• Klient siseneb staatilisele saidile hindadega, valib tooted ja helistab numbrile, mis on veebilehel välja toodud.

• Klient nimetab tooted, mida ta soovib tellimusele lisada.

• Mainib oma aadressi ja nime.

• Operaator võtab tellimuse vastu.

• Tellimus kuvatakse vastuvõetud tellimuste liideses.

Kõik algab menüü kuvamisest. Sisse logitud operaator saab ühel hetkel vastu võtta ainult ühe tellimuse. Seetõttu võib mustand-korv salvestuda tema sessioonis (kasutaja sessioon salvestatakse mällu). Seal on objekt Cart, kuhu kuuluvad tooted ja kliendi teave.

Klient nimetab toodet, operaator vajutab + toote kõrval ja saadab serverisse päringu. Toote kohta tõmmatakse andmed andmebaasist ja toote teave lisatakse korvi.

Märkus. Jah, siin ei pea toodet andmebaasest tooma, vaid seda saab edastada front-endist. Kuid selguse huvides näitasin ma just teed andmebaasi. 

Seejärel sisestame kliendi aadressi ja nime. 

Nupu ‘Loo tellimus’ vajutamisel:

• Saadame päringu OrderController.SaveOrder().

• Saame Cart'i sessioonist, seal on tooted vajalikes kogustes.

• Täiendame Cart'i kliendi teabega ja edastame selle ReceivingOrderService klassi AddOrder meetodisse, kus see salvestatakse andmebaasi. 

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

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

Uued moodulid

Tellimuse vastuvõtt oli oluline ja vajalik. Pizza müümise äri ei saa toimida ilma tellimuste vastuvõtmiseta. Seetõttu hakkas süsteem ajavahemikul 2012–2015 funktsionaalsust arendama. Sel ajal ilmus palju erinevaid süsteemi komponente, mida nimetame mooduliteks, vastandina teenuse või toote mõistetele. 

Moodul on funktsioonide kogum, mis on ühendatud mingi ühise äri eesmärgiga. Samuti asuvad nad füüsiliselt ühes rakenduses.

Mooduleid võib nimetada süsteemi plokkideks. Näiteks võivad need olla aruande moodul, administreerimise liidese rakendus, toodete jälgija köögis, autoriseerimine. Need on kõik erinevad liidesed kasutaja jaoks, mõnedel on isegi erinevad visuaalsed stiilid. Kõik see jääb ühe rakenduse, ühe töötava protsessi raamidesse. 

Tehniliselt olid moodulid vormistatud kui Area (see idee on isegi jäänud asp.net core). Seal olid eraldi failid front-endi, mudelite ja ka oma kontrollereid. Lõpuks töötas süsteem välja nii...

...niimoodi:

Mõned moodulid on realiseeritud eraldi veebisaitidena (täidetav projekt), täielikult erilise funktsionaalsuse tõttu ja osaliselt osaliselt, kuna arendustöö oli eraldatud ja rohkem keskendunud. Need on:

• Veebisait — esimene versioon veebisaidist dodopizza.ru.

• Export: raportide eksportimine Dodo IS-ist 1C-le. 

• Isiklik — töötaja isiklik kabinet. See on eraldi arendatud ning sellel on oma sisenemispunkt ja eraldi disain.

• fs — projekt staatilise sisu majutamiseks. Hiljem sellega lõpetati ja kogu staatika viidud Akamai CDN-ile. 

Ülejäänud plokid asusid BackOffice rakenduses. 

Nimede selgitus:

• Cashier — restorani kassasüsteem.

• ShiftManager — liideseid rollile 'Vahtkonna juht': operatiivne statistika pitsarestorani müükidest, võimalus lisada tooteid musta nimekirja, muuta tellimust.

• OfficeManager — liideseid rollidele 'Pitsarestorani juht' ja 'Frantsiisi andja'. Siin on koondatud funktsioonid pitsarestorani seadistamiseks, boonuskampaaniate haldamiseks, töötajate vastuvõtmiseks ja töötamiseks, aruandeks.

• PublicScreens — liideseid televisioonidele ja tahvelarvutitele, mis asuvad pitsarestoranides. Televisioonidel kuvatakse menüü, reklaamiteave, tellimuse staatus väljakuulutamise hetkel. 

Nad kasutasid üldist teenuste kihti, üldist domeeniklasside plokki Dodo.Core, samuti ühist andmebaasi. Mõnikord viidi nad suunamiste kaudu üksteisega kokku. Sealhulgas pääsesid ühistele teenustele ka eraldi veebisaidid, nagu dodopizza.ru või personal.dodopizza.ru.

Uute moodulite ilmnemisel püüti maksimaalselt taaskasutada juba loodud teenuste, salvestatud protseduuride ja andmebaasi tabelite koodi. 

Et paremini mõista süsteemis loodud moodulite ulatust, on siin 2012. aasta arengukava skeem:

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

• Tellimuse vastuvõtt kasvas eraldi Kontaktikeskuseks, kus tellimust võtab vastu operaator.

• Ilmusid avalikud ekraanid menüü ja teabe kuvamiseks, mis asusid pitsarestoranides.

• Köögis on moodul, mis automaatselt esitab häälsõnumi 'Uus pitsal' uue tellimuse saabumisel ja printib kauba saadetise kullerile. See lihtsustab köögiprotsesse oluliselt, võimaldades töötajatel mitte hajuda paljude lihtsate toimingute peale.

• Kohaletoimetamise plokk muutus eraldi Kohaletoimetamise Kassaks, kus tellimus anti kullerile, kes oli eelnevalt vahetusse läinud. Tema tööaeg arvestati palga määramiseks. 

Aastatel 2012 kuni 2015 tekkis rohkem kui 10 arendajat, avati 35 pitsarestorani, levis süsteem Rumeenias ning valmistati ette kohtade avamine Ameerikas. Arendajad ei tegele enam kõigi ülesannetega, vaid jagunevad meeskondadesse, millest igaüks spetsialiseerub oma süsteemi osale. 

Probleemid

Sealhulgas arhitektuuri tõttu (kuid mitte ainult).

Kaos andmebaasis

Üks andmebaas – see on mugav. Sellega saab saavutada ühtsuse, kasutades relatsiooniliste andmebaasidega integreeritud tööriistu. Töö selle kallal on tuttav ja mugav, eriti kui seal on vähe tabeleid ja andmeid.

Kuid nelja aasta jooksul arenduses oli andmebaasis umbes 600 tabelit, 1500 salvestatud protseduuri, milles paljus oli ka loogika. Kahjuks ei too salvestatud protseduurid MySQL-i kasutamisel eriliselt eeliseid. Need ei ole andmebaasi poolt vahemälus hoitud ning loogika salvestamine keerustab arendust ja silumist. Koodi taaskasutamine on samuti keeruline.

Paljudel tabelitel puudusid sobivad indeksid, kuid mõnes oli vastupidi liiga palju indekseid, mis raskendas lisamist. Ümber tuli teha umbes 20 tabelit – tellimuse loomise tehing võis võtta aega umbes 3-5 sekundit. 

Andmed tabelites ei olnud alati kõige sobivamas vormis. Mõnes kohas tuli teha denormaliseerimist. Üks osa regulaarselt saadud andmetest oli veerul XML-struktuuri kujul, see pikendas täitmise aega, venitas päringuid ja keerustas arendust.

Üksikutele tabelitele tehti väga mitmekesiseid päringuid. Eriti kannatasid populaarsed tabelid, nagu eelmainitud tabel orders või tabel pizzeria. Neid kasutati köögis operatiivsete liideste ja analüüsi esitamiseks. Sellest pöördus ka veebileht (dodopizza.ru), kuhu võis igal ajal ootamatult tulla palju päringuid. 

Andmed ei olnud agaratiivsed ja palju arvutusi toimus jooksvalt andmebaasi vahendusel. See põhjustas tarbetuid arvutusi ja lisakoormust. 

Tihti liikus kood andmebaasi siis, kui tal ei oleks seda teha tohtinud. Kusagil puudusid bulk-tegevused, kusagil oleks pidanud ühe päringu jagama mitmeks läbi koodi, et kiirus ja usaldusväärsus tõusta. 

Seotuse ja segaduse allikad koodis

Moodulid, mis pidid vastutama oma ärivaldkonna eest, ei täitnud seda õigesti.. Mõnedel neist olid rollide funktsioonide dubleerimised. Näiteks kohalik turundaja, kes vastutas oma linna turundustegevuse eest, pidi kasutama nii „Admini” liidest (aktsiate seadistamiseks) kui ka „Kontori Juhi” liidest (aktsiate mõju jälgimiseks äritegevusele). Loomulikult kasutasid mõlemad moodulid sama teenust, mis töötas boonuskampaaniatega.

Teenuseid (klassi ühes suures monoliitses projektis) võidi omavahel kutsuda, et oma andmeid rikastada.

Mudelklassidega, mis andmeid salvestavad, tööd tehti erineval viisil. Kusagil olid konstruktoreid, mille kaudu sai märkida kohustuslikud väljad. Kusagil tehti seda avalike omaduste kaudu. Loomulikult oli andmete saamine ja töötlemine andmebaasist mitmekesine. 

Loogika oli kas kontrollerites või teenuseklassides. 

Need tunduvad väikesed probleemid, kuid need aeglustasid arendust ja vähendasid kvaliteeti, mis viis ebastabiilsuse ja vigade tekkimiseni. 

Suure arenduse keerukus

Tõsised raskused tekkisid ka arenduse endaga. Oli vaja teha erinevaid süsteemi komponente, ning seda paralleelselt. Iga komponendi vajaduste mahutamine ühte koodi muutus üha raskemaks. Ei olnud lihtne kokku leppida ja rahuldada kõiki komponente üheaegselt. Lisaks sellele tulid tehnoloogilistele piirangutele, eriti andmebaasi ja frontendi osas. Pidi loobuma JQueryst kõrgema taseme raamistikute poole, eriti klienditeenuste (veebisaidi) osas.

Mõnes süsteemi osas võiksid olla kasutusel andmebaasid, mis sobivad selleks paremini. Näiteks hiljem oli meil pretsedent üleminek Rediselt CosmosDBle tellimiskorvi salvestamiseks. 

Komandod ja arendajad, kes tegelesid oma valdkonnaga, soovisid selgelt suuremat iseseisvust oma teenustes, nii arenduse kui ka välja laskmise osas. Ühendamisprobleemid, probleemid väljaannetes. Kui 5 arendaja jaoks ei ole see probleem eriti oluline, siis 10 puhul, ja veelgi enam oodatava kasvu korral, oleks kõik tõsisemaks muutunud. Ja ees oli oodata mobiilirakenduse arendust (see käivitus 2017. aastal, ja 2018. aastal toimus suure languse). 

Erinevad süsteemi osad vajavad erinevaid stabiilsuse näitajaid., kuid süsteemi tugeva seotuse tõttu ei suutnud me seda tagada. Uue funktsiooni väljatöötamise viga adminpaneelis võis tõepoolest mõjutada veebis tellimise protsessi, kuna kood on ühine ja taaskasutatav, andmebaas ja andmed samuti ühtsed.

Tõenäoliselt oleks sellise monoliitse-modulaarse arhitektuuri raames saanud vältida neid vigu ja probleeme: vastutuse jagamine, koodi ja andmebaasi refaktoreerimine, kihtide selge eristamine, kvaliteedi jälgimine iga päev. Kuid valitud arhitektuurilised lahendused ja fookus süsteemi funktsionaalsuse kiirel laiendamisel viisid probleemideni stabiilsuse osas.

Kuidas blogi Vaimu vägi viis kassade tõusule restoranides

Kui pitsarestoranide (ja koormuse) kasv oleks jätkunud samas tempos, oleks mõne aja pärast langused olnud nii suured, et süsteem ei tõuseks enam. Hästi illustreerib probleeme, millega hakkasime silmitsi seisma 2015. aastal, üks selline lugu. 

Blogis “Vaimu vägi” oli vidin, mis näitas kogu ketti aastaseid tulude andmeid. Vidin pöördus avaliku API Dodo poole, mis pakub neid andmeid. Praegu on see statistika saadaval http://dodopizzastory.com/. Vidin kuvati igal lehel ja tegi päringuid iga 20 sekundi tagant. Päring suundus api.dodopizza.ru-le ja küsis:

• pitsarestoranide arvu kettis;

• kogu keti tulu aasta algusest;

• tulu täna.

Tulu statistika päring suundus otse andmebaasi ja hakkas küsima tellimuste andmeid, agregatsioon toimus reaalajas ja esitati summa. 

Sama tellimuste tabeli läbisid ka restoranide kassad, laadides alla täna võetud tellimuste loendi ja lisades sellesse uusi tellimusi. Kassad tegid päringuid iga 5 sekundi tagant või siis, kui lehte uuendati.

Skeem nägi välja selline:

Üks sügis, Fedor Ovčinnikov kirjutas oma blogis pika ja populaarse artikli. Blogisse tuli väga palju inimesi ja nad hakkasid kõike hoolikalt lugema. Seni, kuni iga külastaja luges artiklit, töötas tulu vidin korralikult ja küsis API-lt iga 20 sekundi järel.

API kutsus salvestatud protseduuri, et arvutada kõigi selle aasta tellimuste kogusumma kõigis ketis olevates pitsakodades. Agregeerimine toimus orders tabelis, mis on väga populaarne. Kõik avatud restoranide kassad kasutasid seda. Kassad lakkasid töötamast, tellimusi ei võetud vastu. Samuti ei võetud tellimusi vastu veebisaidilt, need ei ilmunud jälgimisüsteemis, vahetuse juht ei saanud neid oma liideses näha. 

See pole ainus lugu. 2015. aasta sügisel oli igal reedel süsteemile kriitiline koormus. Korduvalt sulgesime avaliku API, ja korra pidime isegi veebisaidi välja lülitama, kuna ei aidanud enam miski. Oli isegi teenuste nimekiri, millises järjekorras teenuseid korraliku koormuse korral välja lülitada.

Sellest ajast algab meie võitlus koormustega ja süsteemi stabiliseerimine (2015. aasta sügisest kuni 2018. aasta sügiseni). Just siis juhtus "Suure kummardus". Edasi juhtus mõnikord vaid ebaõnnestumisi, mõned olid piisavalt tundlikud, kuid üldiselt on praegu ebastabiilsuse perioodi võimalik pidada möödunuks.

Äri kiire kasv

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

Samuti avati 2014-2015 Rumeenias ja valmistuti avama Ameerikas.

Ketas kasvas väga kiiresti, uusi riike avati, uusi pitsakohta vorme ilmus, näiteks avati pitsakoda toiduturgudel. Kõik see nõudis erilist tähelepanu Dodo IS funktsioonide laiendamisele. Ilma nende funktsioonideta, köögis jälgimist, toiduainete ja kadude arvestuseta süsteemis, tellimuste esitamine toiduturu saalis, ei arutaks me praegu „õige“ arhitektuuri ja „õige“ lähenemise üle arenduses.

Samuti oli 2014. aasta kriis takistuseks arhitektuuri õigeaegsel läbivaatamisel ja tehniliste probleemide tähelepanu juhtimisel. Sellised asjad õõnestavad meeskondade kasvuvõimet, eriti noore äri, nagu Dodo Pizza.

Kiired lahendused, mis aitasid

Probleemid nõudsid lahendust. Üldiselt võib lahendused jagada kahte rühma:

• Kiired, mis kustutavad tule ja annavad natuke turvavarustust ning kasu meie ajale muudatuste tegemiseks.

• Süsteemsed ja seetõttu pikad. Mitmete moodulite ümberkujundamine, monoliitsete arhitektuuride jagamine eraldi teenusteks (enamik neist on pigem makroteenused kui mikroteenused ja sellest on juba Andrei Morevsky raport). 

Kiirete muudatuste kuiv loend on järgmine:

Mastaabi suurendamise meistribaas

Muidugi on esimene samm koormuste vastu võitlemisel serveri võimsuse suurendamine. Seda tehti meistribaasi ja veebiserverite jaoks. Kahjuks on see võimalik ainult teatud piirini, pärast mida muutub see liiga kulukaks.

Alates 2014. aastast kolisime Azure'i, sellest rääkisime ka siis artiklis „Kuidas Dodo Pizza toimetab pitsat Microsoft Azure'i pilve abil”. Kuid pärast serverite suurendamise seeriat jõesüsteemi puhul jõudsime kuludesse. 

Lugemise replikad

Replikad loodi kahte tüüpi:

ReadReplica päringute jaoks teabelehtedele. See on mõeldud lugemiseks, mis puudutab teabeallikaid, nagu linnad, tänavad, pitsakohad, tooted (aeglaselt muutuva domeeniga), ning nendes liidestes, kus on lubatud väike viivitus. Neid replikasid oli 2 ja me tagasime nende kättesaadavuse samamoodi nagu meistrit.

ReadReplica raportite päringute jaoks. Sellel andmebaasil oli madalam kättesaadavus, kuid see sisaldas kõiki aruandeid. Olgu, neil on rasked päringud tohutute andmete ülekalkuluste jaoks, kuid need ei mõjuta põhivaramu ja operatiivseid liideseid. 

Kaasid koodis

Koodis ei olnud kuhugi kaasu (üldse). See põhjustas täiendavaid, mitte alati vajalikke päringuid koormatud andmebaasi. Käesolevalt olid kaasu nii mälus kui ka välikausiteenuses, see oli Redis. Kõik aegunud seadmed olid ajaliselt, seaded määrati koodis.

Mitu serverit tahkete süsteemide jaoks

Rakenduse tahke süsteemi läks ka mastaapimiseks, et taluda suurenenud koormusi. Üks IIS-server tuli muutuda klastriks. Me viisime rakenduste seansi mälust üle RedisCache'i, mis võimaldas luua mitu serverit, mis seisavad tavalise koormuse tasakaalustaja taga, kasutades round robin'i. Alguses kasutati sama Redis, mis oli kaausideks, hiljem jagati see mitmeks. 

Kokkuvõttes muutus arhitektuur keerulisemaks…

…kuid osa pingest õnnestus leevendada.

Ja siis tuli üle vaadata koormatud komponente, millega me ka tegelesime. Sellest räägime järgmises osas.

Allikas: habr.com