Arba kiekviena nelaiminga įmonė, turinti monolitą, yra nelaiminga savaip.
Dodo IS sistemos kūrimas prasidėjo iš karto, kaip ir Dodo Pizza verslas, 2011 m. Jis buvo pagrįstas visiško ir visiško verslo procesų skaitmeninimo idėja , kuri jau tada 2011 metais sukėlė daug klausimų ir skepticizmo. Bet jau 9 metus einame šiuo keliu – su savo plėtra, kuri prasidėjo nuo monolito.
Šis straipsnis yra „atsakymas“ į klausimus „Kodėl perrašyti architektūrą ir daryti tokius plataus masto ir ilgalaikius pakeitimus? atgal į ankstesnį straipsnį . Pradėsiu nuo to, kaip prasidėjo Dodo IS kūrimas, kaip atrodė originali architektūra, kaip atsirado nauji moduliai ir dėl kokių problemų teko daryti didelius pakeitimus.
Straipsnių ciklas "Kas yra Dodo IS?" pasakoja apie:
-
Ankstyvasis monolitas Dodo IS (2011-2015). (tu esi čia)
-
.
-
Kliento pusės takas: fasadas virš pagrindo (2016-2017). (Vykdoma...)
-
Tikrų mikropaslaugų istorija. (2018–2019 m.). (Vykdoma...)
-
Baigtas monolito pjovimas ir architektūros stabilizavimas. (Vykdoma...)
Pradinė architektūra
2011 m. Dodo IS architektūra atrodė taip:
Pirmasis architektūros modulis yra užsakymų priėmimas. Verslo procesas buvo toks:
-
klientas skambina į piceriją;
-
vadovas pakelia ragelį;
-
priima užsakymą telefonu;
-
lygiagrečiai užpildo užsakymo priėmimo sąsajoje: atsižvelgiama į informaciją apie klientą, duomenis apie užsakymo detales, pristatymo adresą.
Informacinės sistemos sąsaja atrodė maždaug taip ...
Pirmoji 2011 m. spalio versija:
Ištekliai pirmojo užsakymų priėmimo modulio kūrimui buvo riboti. Teko daug nuveikti, greitai ir su nedidele komanda. Nedidelę komandą sudaro 2 kūrėjai, padėję pamatus visai būsimai sistemai.
Pirmasis jų sprendimas nulėmė technologijų kamino likimą:
-
Backend ASP.NET MVC, C# kalba. Kūrėjai buvo dotnetchiki, šis krūvas jiems buvo pažįstamas ir malonus.
-
„Bootstrap“ ir „JQuery“ sąsaja: vartotojo sąsajos su savarankiškai parašytais stiliais ir scenarijais.
-
MySQL duomenų bazė: be licencijos mokesčių, paprasta naudoti.
-
Serveriai „Windows Server“, nes .NET tada galėjo būti tik „Windows“ operacinėje sistemoje (mono neaptarsime).
Fiziškai visa tai buvo išreikšta „atsidavimu šeimininke“.
Užsakymo priėmimo programų architektūra
Tada jau visi kalbėjo apie mikropaslaugas, o 5 metus dideliuose projektuose buvo naudojamas SOA, pavyzdžiui, WCF buvo išleistas 2006 m. Bet tada jie pasirinko patikimą ir patikrintą sprendimą.
Štai jis.
Asp.Net MVC yra „Razor“, kuris, paprašius formos arba kliento, pateikia HTML puslapį su serverio atvaizdavimu. Kliente CSS ir JS scenarijai jau rodo informaciją ir, jei reikia, atlieka AJAX užklausas per JQuery.
Užklausos serveryje patenka į *Controller klases, kur metodu vyksta galutinio HTML puslapio apdorojimas ir generavimas. Valdikliai pateikia užklausas logikos sluoksniui, vadinamam *Paslaugos. Kiekviena iš paslaugų atitiko tam tikrą verslo aspektą:
-
Pavyzdžiui, DepartmentStructureService teikė informaciją apie picerijas, apie skyrius. Skyrius yra picerijų grupė, valdoma vieno franšizės gavėjo.
-
ReceivingOrdersService priėmė ir apskaičiavo užsakymo sudėtį.
-
O „SmsService“ išsiuntė SMS, skambindama API tarnyboms, kad išsiųstų SMS.
Paslaugos apdorojo duomenis iš duomenų bazės, saugojo verslo logiką. Kiekviena paslauga turėjo vieną ar daugiau *saugyklų su atitinkamu pavadinimu. Juose jau buvo užklausos dėl duomenų bazėje saugomų procedūrų ir žemėlapių sluoksnio. Saugyklose buvo verslo logika, ypač tose, kurios išdavė ataskaitų duomenis. ORM nebuvo naudojamas, visi rėmėsi ranka rašytu sql.
Taip pat buvo domeno modelio sluoksnis ir bendros pagalbinės klasės, pavyzdžiui, užsakymo klasė, kurioje saugomas užsakymas. Toje pačioje vietoje, sluoksnyje, buvo rodomo teksto konvertavimo pagal pasirinktą valiutą pagalbininkas.
Visa tai galima pavaizduoti tokiu modeliu:
Užsakymo būdas
Apsvarstykite supaprastintą pradinį tokios tvarkos kūrimo būdą.
Iš pradžių svetainė buvo statiška. Ant jo buvo nurodytos kainos, o viršuje – telefono numeris ir užrašas „Jei nori picos – skambink numeriu ir užsisakyk“. Norėdami užsisakyti, turime įgyvendinti paprastą eigą:
-
Klientas apsilanko statinėje svetainėje su kainomis, išsirenka prekes ir paskambina svetainėje nurodytu numeriu.
-
Klientas įvardija prekes, kurias nori įtraukti į užsakymą.
-
Nurodo savo adresą ir vardą.
-
Operatorius priima užsakymą.
-
Užsakymas rodomas priimtų užsakymų sąsajoje.
Viskas prasideda nuo meniu rodymo. Prisijungęs vartotojas-operatorius vienu metu priima tik vieną užsakymą. Todėl krepšelio juodraštis gali būti saugomas jo sesijoje (vartotojo sesija išsaugoma atmintyje). Yra krepšelio objektas, kuriame yra produktai ir klientų informacija.
Klientas įvardija prekę, operatorius paspaudžia + šalia gaminio, ir serveriui siunčiama užklausa. Informacija apie prekę ištraukiama iš duomenų bazės ir informacija apie prekę įdedama į krepšelį.
Atkreipti dėmesį. Taip, čia jūs negalite ištraukti produkto iš duomenų bazės, o perkelti jį iš priekinės dalies. Bet aiškumo dėlei tiksliai parodžiau kelią iš duomenų bazės.
Tada įveskite kliento adresą ir vardą.
Kai paspausite "Sukurti užsakymą":
-
Užklausa siunčiama OrderController.SaveOrder().
-
Krepšelį gauname iš seanso, yra produktų tiek, kiek mums reikia.
-
Krepšelį papildome informacija apie klientą ir perduodame į ReceivingOrderService klasės AddOrder metodą, kur išsaugoma duomenų bazėje.
-
Duomenų bazėje yra lentelės su užsakymu, užsakymo sudėtimi, klientu ir visos jos yra sujungtos.
-
Užsakymų rodymo sąsaja ištraukia naujausius užsakymus ir juos parodo.
Nauji moduliai
Priimti užsakymą buvo svarbu ir būtina. Negalite užsiimti picų verslu, jei neturite užsakymo parduoti. Todėl sistema pradėjo įgyti funkcionalumą – maždaug nuo 2012 iki 2015 m. Per tą laiką atsirado daug įvairių sistemos blokų, kuriuos vadinsiu moduliai, priešingai nei paslaugos ar produkto samprata.
Modulis – tai rinkinys funkcijų, kurias vienija kažkoks bendras verslo tikslas. Tuo pačiu metu jie fiziškai yra toje pačioje programoje.
Moduliai gali būti vadinami sistemos blokais. Pavyzdžiui, tai yra ataskaitų teikimo modulis, administratoriaus sąsajos, , įgaliojimas. Tai visos skirtingos vartotojo sąsajos, kai kurios netgi turi skirtingus vizualinius stilius. Tuo pačiu metu viskas yra vienos programos, vieno veikiančio proceso ribose.
Techniškai moduliai buvo sukurti kaip Area (tokia idėja net išliko ). Buvo atskiri failai priekiniam įrenginiui, modeliams, taip pat jų pačių valdiklių klasėms. Dėl to sistema buvo pakeista iš šio ...
...į tai:
Kai kurie moduliai yra įgyvendinami atskirose svetainėse (vykdomasis projektas), dėl visiškai atskiro funkcionalumo ir iš dalies dėl šiek tiek atskiro, labiau orientuoto kūrimo. Tai:
-
vieta - svetainė dodopizza.ru.
-
Eksportuoti: ataskaitų įkėlimas iš Dodo IS, skirtas 1C.
-
Asmeninis - asmeninė darbuotojo sąskaita. Jis buvo sukurtas atskirai ir turi savo įėjimo tašką bei atskirą dizainą.
-
fs — statikos talpinimo projektas. Vėliau mes nuo jo atsitraukėme, visą statiką perkeldami į Akamai CDN.
Likę blokai buvo „BackOffice“ programoje.
Pavadinimo paaiškinimas:
-
Kasininkė – restorano kasininkė.
-
„ShiftManager“ – „Shift Manager“ vaidmens sąsajos: picerijų pardavimo veiklos statistika, galimybė įtraukti produktus į sustojimo sąrašą, keisti užsakymą.
-
OfficeManager – sąsajos, skirtos „Picerijos vadovo“ ir „Franšizės gavėjo“ vaidmenims. Čia surinktos picerijos įkūrimo, jos premijų akcijos, darbuotojų priėmimo ir darbo su jais funkcijos, ataskaitos.
-
PublicScreens – picerijose kabančių televizorių ir planšetinių kompiuterių sąsajos. Televizoriai rodo meniu, reklaminę informaciją, užsakymo būseną pristatymo metu.
Jie naudojo bendrą paslaugų sluoksnį, bendrą Dodo.Core domeno klasės bloką ir bendrą bazę. Kartais jie vis tiek galėjo vesti perėjimus vienas į kitą. Įskaitant atskiras svetaines, tokias kaip dodopizza.ru arba personal.dodopizza.ru, buvo skirtos bendrosios paslaugos.
Atsiradus naujiems moduliams stengėmės maksimaliai pakartotinai panaudoti jau sukurtą paslaugų kodą, saugomas procedūras ir lenteles duomenų bazėje.
Norėdami geriau suprasti sistemoje sukurtų modulių mastą, pateikiame 2012 m. diagramą su plėtros planais:
Iki 2015 m. viskas buvo žemėlapyje ir dar daugiau buvo gaminama.
-
Užsakymų priėmimas išaugo į atskirą Kontaktų centro bloką, kuriame užsakymą priima operatorė.
-
Picerijose kabėjo vieši ekranai su meniu ir informacija.
-
Virtuvėje yra modulis, kuris atėjus naujam užsakymui automatiškai atkuria balso pranešimą „Nauja pica“, taip pat atspausdina sąskaitą kurjeriui. Tai labai supaprastina procesus virtuvėje, leidžia darbuotojams nesiblaškyti nuo daugybės paprastų operacijų.
-
Pristatymo padalinys tapo atskira Pristatymo kasa, kurioje užsakymas buvo išduodamas kurjeriui, kuris prieš tai buvo pamainą. Apskaičiuojant darbo užmokestį buvo atsižvelgta į jo darbo laiką.
Lygiagrečiai, 2012–2015 m., atsirado daugiau nei 10 kūrėjų, atsidarė 35 picerijos, įdiegė sistemą Rumunijoje ir ruošėsi prekybos vietų atidarymui JAV. Kūrėjai jau nesusitvarkė su visomis užduotimis, o buvo suskirstyti į komandas. kiekvienas specializuojasi savo sistemos dalyje.
Problemos
Įskaitant dėl architektūros (bet ne tik).
Chaosas bazėje
Vienas pagrindas yra patogus. Jame galima pasiekti nuoseklumą ir reliacinėse duomenų bazėse įmontuotų įrankių sąskaita. Darbas su juo yra pažįstamas ir patogus, ypač jei yra mažai lentelių ir mažai duomenų.
Tačiau per 4 kūrimo metus paaiškėjo, kad duomenų bazėje yra apie 600 lentelių, 1500 saugomų procedūrų, iš kurių daugelis taip pat turėjo logiką. Deja, saugomos procedūros neduoda daug naudos dirbant su MySQL. Bazė jų nesaugo talpykloje, o logikos saugojimas juose apsunkina kūrimą ir derinimą. Pakartotinis kodo naudojimas taip pat yra sudėtingas.
Daugelis lentelių neturėjo tinkamų indeksų, kai kur, atvirkščiai, buvo daug indeksų, todėl sunku buvo įterpti. Reikėjo modifikuoti apie 20 lentelių – sandoris užsakymui sukurti galėjo užtrukti apie 3-5 sekundes.
Duomenys lentelėse ne visada buvo tinkamiausios formos. Kažkur reikėjo daryti denormalizaciją. Dalis reguliariai gaunamų duomenų buvo XML struktūros formos stulpelyje, tai padidino vykdymo laiką, pailgino užklausas ir apsunkino kūrimą.
Prie tų pačių lentelių buvo gaminama labai nevienalyčių prašymų. Ypač nukentėjo populiarios lentelės, kaip ir aukščiau minėta lentelė. užsakymai arba lenteles picerija. Jie buvo naudojami operacinėms sąsajoms virtuvėje atvaizduoti, analitikai. Kita svetainė susisiekė su jais (), kur bet kuriuo metu staiga gali sulaukti daug užklausų.
Duomenys nebuvo apibendrinti ir daugelis skaičiavimų vyko skrendant naudojant bazę. Dėl to atsirado nereikalingų skaičiavimų ir papildomos apkrovos.
Dažnai kodas patekdavo į duomenų bazę, kai to negalėjo padaryti. Kai kur nepakako masinių operacijų, kai kur reikėtų per kodą vieną užklausą paskirstyti į kelias, kad paspartėtų ir padidėtų patikimumas.
Sanglauda ir užmaskavimas kode
Moduliai, kurie turėjo būti atsakingi už savo verslo dalį, to nepadarė sąžiningai. Kai kurie iš jų turėjo dubliavimo funkcijas. Pavyzdžiui, vietinis rinkodaros specialistas, atsakingas už tinklo rinkodaros veiklą savo mieste, turėjo naudoti ir sąsają „Administratorius“ (kurti reklamas), ir „Office Manager“ sąsają (norėdamas peržiūrėti reklamų poveikį verslui). Žinoma, abiejuose moduliuose buvo naudojama ta pati paslauga, kuri veikė su premijomis.
Paslaugos (vieno monolitinio didelio projekto klasės) galėtų skambinti viena kitai, kad praturtintų savo duomenis.
Su pačiomis modelių klasėmis, kuriose saugomi duomenys, darbas su kodu buvo atliktas kitaip. Kai kur buvo konstruktoriai, per kuriuos buvo galima nurodyti privalomus laukus. Kai kur tai buvo daroma per viešąsias nuosavybes. Žinoma, duomenų gavimas ir transformavimas iš duomenų bazės buvo įvairus.
Logika buvo arba valdikliuose, arba aptarnavimo klasėse.
Atrodo, kad tai nedidelės problemos, tačiau jos labai sulėtino plėtrą ir sumažino kokybę, todėl atsirado nestabilumo ir klaidų.
Didelės plėtros sudėtingumas
Sunkumai kilo pačiame kūrime. Reikėjo daryti skirtingus sistemos blokus ir lygiagrečiai. Suderinti kiekvieno komponento poreikius į vieną kodą tapo vis sunkiau. Nebuvo lengva susitarti ir patikti visiems komponentams vienu metu. Be to, buvo taikomi technologijų apribojimai, ypač dėl pagrindo ir priekinės dalies. Reikėjo atsisakyti „jQuery“ link aukšto lygio karkasų, ypač kalbant apie klientų paslaugas (svetainę).
Kai kuriose sistemos dalyse galėtų būti naudojamos tam tinkamesnės duomenų bazės.. Pavyzdžiui, vėliau turėjome naudoti atvejį, kai iš Redis persikėlėme į CosmosDB, kad saugotume užsakymų krepšelį.
Komandos ir kūrėjai, dalyvaujantys savo srityje, aiškiai norėjo daugiau savarankiškumo savo paslaugoms tiek plėtojant, tiek diegiant. Sujunkite konfliktus, atleiskite problemas. Jei 5 kūrėjams ši problema yra nereikšminga, tai su 10, o juo labiau su planuojamu augimu, viskas taptų rimtesnė. O priekyje turėjo būti mobiliosios aplikacijos kūrimas (jis prasidėjo 2017 m., o 2018 m. ).
Skirtingoms sistemos dalims reikėjo skirtingo stabilumo lygio, tačiau dėl stipraus sistemos ryšio negalėjome to suteikti. Klaida kuriant naują funkciją administratoriaus skydelyje galėjo įvykti priimant užsakymą svetainėje, nes kodas yra bendras ir pakartotinai naudojamas, duomenų bazė ir duomenys taip pat yra vienodi.
Tokios monolitinės-modulinės architektūros rėmuose tikriausiai būtų galima išvengti šių klaidų ir problemų: pasidalyti atsakomybę, pertvarkyti ir kodą, ir duomenų bazę, aiškiai atskirti sluoksnius vienas nuo kito, kasdien stebėti kokybę. Tačiau pasirinkti architektūriniai sprendimai ir dėmesys greitam sistemos funkcionalumo išplėtimui sukėlė stabilumo problemų.
Kaip „Proto galios“ tinklaraštis pastatė restoranų kasas
Jei picerijų tinklo (ir apkrovos) augimas tęstųsi tokiais pat tempais, tai po kurio laiko kritimai būtų tokie, kad sistema nebekiltų. Gerai iliustruoja problemas, su kuriomis pradėjome susidurti iki 2015 m., štai tokia istorija.
dienoraštyje "“ buvo valdiklis, rodantis viso tinklo metų pajamų duomenis. Valdiklis pasiekė Dodo viešąją API, kuri pateikia šiuos duomenis. Šią statistiką šiuo metu galima rasti adresu . Valdiklis buvo rodomas kiekviename puslapyje ir kas 20 sekundžių teikė užklausas laikmačiu. Prašymas nukeliavo į api.dodopizza.ru ir paprašė:
-
picerijų skaičius tinkle;
-
bendros tinklo pajamos nuo metų pradžios;
-
pajamos šiai dienai.
Prašymas pateikti statistiką apie pajamas nukeliavo tiesiai į duomenų bazę ir pradėjo prašyti duomenų apie užsakymus, greitai kaupti duomenis ir skelbti sumą.
Kasos restoranuose nukeliavo į tą pačią užsakymų lentelę, iškrovė šiai dienai gautų užsakymų sąrašą, į jį buvo įtraukti nauji užsakymai. Kasos aparatai teikdavo užklausas kas 5 sekundes arba atnaujindavo puslapį.
Diagrama atrodė taip:
Vieną rudenį Fiodoras Ovčinikovas savo tinklaraštyje parašė ilgą ir populiarų straipsnį. Daug žmonių atėjo į tinklaraštį ir pradėjo viską atidžiai skaityti. Kol kiekvienas atėjęs žmogus skaitė straipsnį, pajamų valdiklis veikė tinkamai ir kas 20 sekundžių prašė API.
API iškvietė saugomą procedūrą, skirtą apskaičiuoti visų tinkle esančių picerijų užsakymų sumą nuo metų pradžios. Apibendrinimas buvo pagrįstas užsakymų lentele, kuri yra labai populiari. Į ją patenka visos visų tuo metu veikiančių restoranų kasos. Kasos nebereagavo, užsakymai nebuvo priimami. Jie taip pat nebuvo priimti iš svetainės, nepasirodė sekime, pamainos vadovas negalėjo jų matyti savo sąsajoje.
Tai ne vienintelė istorija. Iki 2015 metų rudens kiekvieną penktadienį sistemos apkrova buvo kritinė. Kelis kartus išjungėme viešą API, o vieną kartą net svetainę teko išjungti, nes niekas nepadėjo. Netgi buvo sąrašas paslaugų su išjungimo nurodymu esant didelėms apkrovoms.
Nuo šiol prasideda mūsų kova su apkrovomis ir už sistemos stabilizavimą (nuo 2015 m. rudens iki 2018 m. rudens). Štai tada tai atsitiko"“. Be to, kartais pasitaikydavo ir gedimų, kai kurie buvo labai jautrūs, tačiau bendras nestabilumo laikotarpis dabar gali būti laikomas praėjusiu.
Spartus verslo augimas
Kodėl to negalima padaryti iš karto? Tiesiog pažvelkite į šias diagramas.
Taip pat 2014-2015 metais vyko atidarymas Rumunijoje ir ruošiamasi atidarymui JAV.
Tinklas labai sparčiai augo, atsidarė naujos šalys, atsirado naujų picerijų formatų, pavyzdžiui, maisto aikštelėje atidaryta picerija. Visa tai pareikalavo didelio dėmesio būtent Dodo IS funkcijų išplėtimui. Be visų šių funkcijų, be sekimo virtuvėje, produktų ir nuostolių apskaitos sistemoje, užsakymo išdavimo rodymo maisto teismo salėje vargu ar kalbėtume apie „teisingą“ architektūrą ir „teisingą“ požiūrį į plėtra dabar.
Kita kliūtis laiku peržiūrėti architektūrą ir apskritai atkreipti dėmesį į technines problemas buvo 2014 m. Tokie dalykai smarkiai paveikė komandų galimybes augti, ypač tokiam jaunam verslui kaip Dodo Pizza.
Greiti sprendimai, kurie padėjo
Problemos reikalingos sprendimų. Paprastai sprendimus galima suskirstyti į 2 grupes:
-
Greitieji, kurie užgesina ugnį ir suteikia nedidelę saugumo ribą bei suteikia mums laiko keistis.
-
Sisteminis ir todėl ilgas. Daugelio modulių pertvarkymas, monolitinės architektūros padalijimas į atskiras paslaugas (dauguma jų visai ne mikro, o makro paslaugos, ir čia kažkas yra ).
Sausas greitų pakeitimų sąrašas yra toks:
Padidinkite pagrindinį meistrą
Žinoma, pirmas dalykas, kurį reikia padaryti norint susidoroti su apkrovomis, yra padidinti serverio talpą. Tai buvo padaryta pagrindinei duomenų bazei ir žiniatinklio serveriams. Deja, tai įmanoma tik iki tam tikros ribos, tada tai tampa per brangu.
Nuo 2014 m. persikėlėme į Azure, šia tema tuo metu taip pat rašėme straipsnyje ““. Tačiau po keleto bazinio serverio padidėjimo jie susidūrė su išlaidomis.
Bazinės kopijos skaitymui
Pagrindui buvo padarytos dvi kopijos:
Skaityti repliką užklausoms dėl informacijos. Jis naudojamas skaityti katalogus, tipą, miestą, gatvę, piceriją, produktus (lėtai keičiamas domenas), ir tose sąsajose, kur priimtinas nedidelis vėlavimas. Šių kopijų buvo 2, jų prieinamumą užtikrinome taip pat, kaip ir meistrai.
Skaityti repliką ataskaitų užklausoms. Šios duomenų bazės prieinamumas buvo mažesnis, tačiau visos ataskaitos buvo nukreiptos į ją. Tegul jie turi didelių užklausų atlikti didžiulius duomenų perskaičiavimus, tačiau jie neturi įtakos pagrindinei duomenų bazei ir operacinėms sąsajoms.
Talpyklos kode
Kode niekur nebuvo talpyklos (iš viso). Dėl to į įkeltą duomenų bazę buvo pateiktos papildomos, ne visada būtinos užklausos. Talpyklos pirmiausia buvo tiek atmintyje, tiek išorinėje talpyklos tarnyboje, tai buvo Redis. Viskas buvo negaliojanti laiko, nustatymai buvo nurodyti kode.
Keli backend serveriai
Programos užpakalinę dalį taip pat reikėjo pakeisti, kad būtų galima valdyti padidėjusį darbo krūvį. Reikėjo iš vieno iis-serverio padaryti klasterį. Suplanavome kitą laiką iš atminties į RedisCache, kuri leido sukurti kelis serverius už paprasto apkrovos balansavimo su round robin. Iš pradžių buvo naudojamas tas pats Redis, kaip ir talpykloms, vėliau buvo padalintas į keletą.
Dėl to architektūra tapo sudėtingesnė ...
… bet dalis įtampos buvo pašalinta.
O tada reikėjo perdaryti pakrautus komponentus, ko ir ėmėmės. Apie tai kalbėsime kitoje dalyje.
Šaltinis: www.habr.com