Ose çdo kompani e palumturuar me një monolit është e palumturuar në mënyrën e saj.
Zhvillimi i sistemit Dodo IS filloi menjëherë pas fillimit të biznesit Dodo Pizza - në vitin 2011. Ideja themelore ishte digjitalizimi i plotë dhe total i proceseve të biznesit, dhe , gjë që atëherë në vitin 2011 shkaktoi shumë pyetje dhe skepticizëm. Por tani, pas 9 vjetësh, ne po ndjekim këtë rrugë - me zhvillimin tonë, i cili filloi me një monolit.
Ky artikull është "përgjigje" për pyetjet "Pse të rishkruajmë arkitekturën dhe të bëjmë ndryshime të tilla masive dhe të gjata?" ndaj artikullit të mëparshëm . Do të filloj me mënyrën se si filloi zhvillimi i Dodo IS, si dukej arkitektura fillestare, si u shfaqën modulet e reja dhe për çfarë problemeve u kërkua të bëhen ndryshime masive.
Seria e artikujve "ĂfarĂ« Ă«shtĂ« Dodo IS?" do tĂ« flasĂ« pĂ«r:
Monoliti i hershëm në Dodo IS (2011-2015). (Ju jeni këtu)
.
Rruga e pjesĂ«s sĂ« klientit: fasada mbi bazĂ« (2016-2017). (NĂ« pĂ«rparimâŠ)
Historia e mikroshĂ«rbimeve tĂ« vĂ«rteta. (2018-2019). (NĂ« pĂ«rparimâŠ)
PĂ«rfundimi i prishjes sĂ« monolitit dhe stabilizimi i arkitekturĂ«s. (NĂ« pĂ«rparimâŠ)
Arkitektura fillestare
Në vitin 2011, arkitektura e Dodo IS dukej kështu:
Moduli i parë në arkitekturë është pranimi i porosisë. Procesi i biznesit ishte i tillë:
klienti telefonon në restorantin e picave;
menaxheri e përgjigjet telefonit;
pranon porosinë me telefon;
paralelisht e regjistron atĂ« nĂ« ndĂ«rfaqen e pranimit tĂ« porosisĂ«: informacioni pĂ«r klientin merret parasysh, tĂ« dhĂ«nat pĂ«r detajet e porosisĂ«, adresĂ«n e dorĂ«zimit.Â
Ndërfaqja e sistemit informatik dukej pak a shumë kështu...
Versioni i parë nga tetori 2011:
Burimet për zhvillimin e modulit të parë të pranimit të porosisë ishin të kufizuara. Duhej të bënim shumë, shpejt dhe me një ekip të vogël. Ekip i vogël - ky ishte 2 zhvillues, të cilët vendosën themelet e gjithë sistemit të ardhshëm.
Zgjidhja e tyre të parëndësishme përcaktuan fatin e mëtejshëm të grupit teknologjik:
Backend në ASP.NET MVC, gjuha C#. Zhvilluesit ishin ndërlidhës, ky grup ishte i njohur dhe i këndshëm për ta.
Frontend nĂ« Bootstrap dhe JQuery: ndĂ«rfaqet e pĂ«rdoruesit nĂ« stil dhe skripte tĂ« krijuara vetĂ«.Â
Baza e të dhënave MySQL: pa kosto për licenca, e lehtë për tu përdorur.
Serverat në Windows Server, sepse .NET atëherë mund të ishte vetëm nën Windows (Mos e diskutojmë Mono).
Fizikisht, kjo shprehej nĂ« "dedikimin te hosti".Â
Arkitektura e aplikacionit të pranim-urdhrave
Atëherë të gjithë flisnin për mikroshërbime, ndërsa SOA ishte përdorur për rreth 5 vjet në projekte të mëdha, për shembull, WCF doli në vitin 2006. Por atëherë u zgjodh një zgjidhje e besueshme dhe e provuar.
Këtu është.
Asp.Net MVC është Razor, i cili lëshon një faqe HTML me renditje në server sipas kërkesës nga forma ose ndonjë klienti. Në klient tashmë CSS dhe scriptet JS paraqesin informacionin dhe, sipas nevojës, kryejnë kërkesa AJAX përmes JQuery.
KĂ«rkesat nĂ« server kalojnĂ« nĂ« klasat *Controller, ku nĂ« metodĂ« ndodh pĂ«rpunimi dhe gjenerimi i faqes finale HTML. KontrollorĂ«t bĂ«jnĂ« kĂ«rkesa nĂ« nivelin e logjikĂ«s, tĂ« quajtur *Services. Ădo shĂ«rbim pĂ«rgjigjej pĂ«r njĂ« aspekt tĂ« caktuar tĂ« biznesit:
Për shembull, DepartmentStructureService jepte informacion mbi pizzeritë dhe departamentet. Departamenti është një grup pizzerish nën menaxhimin e një franshizuesi.
ReceivingOrdersService pranonte dhe llogariste përbërjen e porosisë.
Dhe SmsService dërgonte SMS, duke thirrur shërbime API për dërgimin e SMS-ve.
ShĂ«rbimet pĂ«rpunonin tĂ« dhĂ«nat nga baza, ruanin logjikĂ«n e biznesit. NĂ« secilin shĂ«rbim kishte njĂ« ose mĂ« shumĂ« *Repository me emra pĂ«rkatĂ«s. Ato pĂ«rmbanin kĂ«rkesat pĂ«r procedurat e ruajtura nĂ« bazĂ« dhe nivelin e mapuesve. NĂ« procedurat e ruajtura ishte logjika e biznesit, sidomos shumĂ« nĂ« ato qĂ« jepnin tĂ« dhĂ«na raportuese. ORM nuk ishte pĂ«rdorur, tĂ« gjithĂ« mbĂ«shteteshin nĂ« SQL tĂ« shkruar me dorĂ«.Â
Ishte gjithashtu një nivel modeli domene dhe klasash ndihmëse të përgjithshme, për shembull, klasa Order, e cila përmbante porosinë. Atje, në nivelin e ndihmësve, ndodhej një ndihmës për konvertimin e tekstit të shfaqjes sipas monedhës së zgjedhur.
E gjithë kjo mund të paraqitet me këtë model:
Rruga e porosisë
Le të shqyrtojmë rrugën e thjeshtuar fillestare të krijimit të një porosie të tillë.
Fillimisht, faqja ishte statike. Ajo kishte çmime, dhe lart shkruhej numri i telefonit dhe titulli "DĂ«shiron pica â telefononi nĂ« numĂ«r dhe porositni". PĂ«r tĂ« bĂ«rĂ« njĂ« porosi, na duhej tĂ« zbatonim njĂ« fluks tĂ« thjeshtĂ«:Â
Klienti hyn në faqen statike me çmimet, zgjedh produktet dhe telefonon në numrin e dhënë në faqe.
Klienti përmend produktet që dëshiron të shtojë në porosi.
Përmend adresën dhe emrin e tij.
Operatori pranon porosinë.
Porosia shfaqet në ndërfaqen e porosive të pranuara.
E gjithëçka fillon me paraqitjen e menusë. Përdoruesi operator i lidhur në një moment e pranon vetëm një porosi. Prandaj, karroca draft mund të ruhet në sesionin e tij (sesioni i përdoruesit ruhet në memorie). Aty është objekti Cart, në të cilin ndodhen produktet dhe informacioni mbi klientin.
Klienti thotë produktin, operatori klikojnë në + në anë të produktit, dhe në server dërgohet një kërkesë. Nga produkti merret informacioni nga baza dhe informacioni mbi produktin shtohet në karrocë.
ShĂ«nim. Po, kĂ«tu mund tĂ« mos merret produkti nga baza, por tĂ« dĂ«rgohet nga frontend. Por pĂ«r transparencĂ« unĂ« e tregova pikĂ«risht rrugĂ«n nga baza.Â
MĂ« pas, vendosim adresĂ«n dhe emrin e klientit.Â
Kur klikoni "Krijo porosi":
Dërgojmë kërkesën në OrderController.SaveOrder().
Marrim Cart nga sesioni, aty ndodhen produktet në sasinë e nevojshme.
Shtohet informacioni mbi klientin nĂ« Cart dhe e dĂ«rgojmĂ« nĂ« metodĂ«n AddOrder tĂ« klasĂ«s ReceivingOrderService, ku ruhet nĂ« bazĂ«.Â
Në bazë ka tabela me porosi, përbërjen e porosisë, klientin dhe të gjitha janë të lidhura.
Ndërfaqja e paraqitjes së porosisë shkon dhe merr porositë më të fundit dhe i reflektron ato.
Modules të reja
Pranimi i porosisĂ« ishte i rĂ«ndĂ«sishĂ«m dhe i nevojshĂ«m. Nuk mund tĂ« bĂ«sh biznes nĂ« shitjen e pizzave, nĂ«se nuk ke njĂ« sistem pĂ«r pranimin e porosive pĂ«r shitje. Prandaj, sistemi filloi tĂ« pĂ«rmirĂ«sohej me funksionalitete â rreth 2012 deri nĂ« 2015. GjatĂ« kĂ«saj kohe u shfaqĂ«n shumĂ« blloqe tĂ« ndryshme tĂ« sistemit, tĂ« cilat do t'i quaj modulet, nĂ« kontrast me konceptin e shĂ«rbimit apo produktit.Â
Moduli është një grup funksionesh që janë të bashkuara nga një objektiv i përbashkët biznesi. Në të njëjtën kohë, ato fizikisht ndodhen në një aplikacion.
Modulet mund tĂ« quhen blloqe tĂ« sistemit. PĂ«r shembull, ky Ă«shtĂ« moduli i raporteve, ndĂ«rfaqet eAdmin. , identifikimi. TĂ« gjitha kĂ«to janĂ« ndĂ«rfaqe tĂ« ndryshme pĂ«r pĂ«rdoruesin, disa madje kanĂ« edhe stile vizuale tĂ« ndryshme. TĂ« gjitha janĂ« brenda njĂ« aplikacioni, njĂ« procesi funksionimi.Â
Teknikisht, modulet ishin tĂ« dekoruara si Area (kjo ide ka mbetur edhe nĂ« ). Kishin skedar tĂ« ndara pĂ«r frontend-in, modelet, si dhe klasat e tyre tĂ« kontrollorĂ«ve. NĂ« fund, sistemi u transformua nga njĂ«âŠ
âŠnĂ« kĂ«tĂ«:
Disa module janë realizuar si faqe të veçanta (projekti ekzekutiv), për shkak të funksionaliteteve tërësisht të veçanta dhe pjesërisht për shkak të zhvillimit më të fokusuar. Këto janë:
Faqja â i faqes dodopizza.ru.
Eksporto: shkarkimi i raportimeve nga Dodo IS pĂ«r 1C.Â
Personal â llogaria personale e punonjĂ«sit. U zhvillua veçmas dhe ka hyrje tĂ« vet dhe dizajn tĂ« veçantĂ«.
fs â projekt pĂ«r hostimin e statikĂ«s. MĂ« vonĂ« u shmangĂ«m nga kjo, duke e transferuar tĂ« gjithĂ« statikĂ«n nĂ« CDN Akamai.Â
Blloqet e tjera ndodheshin nĂ« aplikacionin BackOffice.Â
Shpjegim mbi emrat:
Kasieri â Kasa e restorantit.
Menaxheri i NdĂ«rrimit â ndĂ«rfaqet pĂ«r rolin "Menaxher i NdĂ«rrimit": statistika operuese mbi shitjet e pizzarive, mundĂ«sia pĂ«r tĂ« vendosur produkte nĂ« listĂ«n e ndalimit, ndryshimi i porosisĂ«.
Menaxheri i ZyrĂ«s â ndĂ«rfaqet pĂ«r rolin "Menaxher i Pizzarive" dhe "Franshizuesi". KĂ«tu janĂ« mbledhur funksionet pĂ«r konfigurimin e pizzarive, promovimet e tyre, pranimin dhe punĂ«n me punonjĂ«sit, raportet.
Ekranet Publike â ndĂ«rfaqet pĂ«r televizorĂ«t dhe tabletĂ«t, tĂ« cilĂ«t varen nĂ« pizzari. NĂ« televizorĂ« shfaqet menyja, informacion reklamues, statusi i porosisĂ« gjatĂ« dorĂ«zimit.Â
Ata përdorën një shtresë të përbashkët shërbimesh, një bllok të përbashkët të klasave domain Dodo.Core, si dhe një bazë të përbashkët. Ndonjëherë mund të kalonin nga njëri te tjetri. Përfshirë shërbimet e përbashkëta, vizitonin edhe faqet e veçanta, si dodopizza.ru ose personal.dodopizza.ru.
Me shfaqjen e moduleve tĂ« reja, u pĂ«rpoqĂ«m tĂ« ri-pĂ«rdorim kodin e tashmĂ« krijuar tĂ« shĂ«rbimeve, procedurave tĂ« ruajtura dhe tabelave nĂ« bazĂ«.Â
Për një kuptim më të mirë të shkallës së moduleve të bëra në sistem, ja skema nga viti 2012 me planet e zhvillimit:
Deri në vitin 2015, gjithçka në skemë dhe madje më shumë ishte në prodhim.
Pranimi i porosisë u shndërrua në një bllok të veçantë të Qendrës së Kontaktit, ku porosia pranoheshin nga operatori.
Shfaqën ekrane publike me meny dhe informacion, të cilat varen në pizzari.
Në kuzhinë ka një modul, i cili automatikisht riprodhon një mesazh me zë "Pizza e re" me pranimin e një porosie të re, si dhe printon një fletë dërgesë për kurierin. Kjo e thjeshton shumë proceset në kuzhinë, duke lejuar që punonjësit të mos shqetësohen nga një numër i madh operacionesh të thjeshta.
Blloku i dorĂ«zimit u bĂ« njĂ« KasĂ« e VeçantĂ« e DorĂ«zimit, ku porosia i jepet kurierit, i cili fillimisht ishte caktuar nĂ« ndĂ«rrim. Koha e tij e punĂ«s u lĂ«shua pĂ«r mbajtjen e pagĂ«s.Â
Paralelisht nga 2012 deri nĂ« 2015 u shfaqĂ«n mĂ« shumĂ« se 10 zhvillues, u hapĂ«n 35 pizzeri, u zhvillua njĂ« sistem pĂ«r Rumani dhe u pĂ«rgatitĂ«n pika pĂ«r hapje nĂ« SHBA. Zhvilluesit nuk merreshin mĂ« me tĂ« gjitha detyrat, por u ndanĂ« nĂ« grupe; secila specializohej nĂ« pjesĂ«n e saj tĂ« sistemit.Â
Problemet
Përfshirë edhe për shkak të arkitekturës (por jo vetëm).
Kaosi në bazë
NjĂ« bazĂ« â Ă«shtĂ« e pĂ«rshtatshme. Ajo mund tĂ« arrijĂ« konsistencĂ«, pĂ«rmes mjeteve tĂ« integruara nĂ« bazat relacionale. TĂ« punosh me tĂ« Ă«shtĂ« e njohur dhe e lehtĂ«, veçanĂ«risht nĂ«se ka pak tabela dhe pak tĂ« dhĂ«na.
Por gjatë 4 viteve të zhvillimit, në bazë rezultuan rreth 600 tabela, 1500 procedura të ruajtura, shumë prej të cilave kishin gjithashtu logjikë. Fatkeqësisht, procedurat e ruajtura nuk ofrojnë ndonjë përfitim të veçantë kur punohet me MySQL. Ato nuk keqen nga baza, dhe ruajtja e logjikës në to e komplikon zhvillimin dhe kërkimin. Rishfrytëzimi i kodit gjithashtu është i vështirë.
NĂ« shumĂ« tabela nuk kishte indekse tĂ« pĂ«rshtatshme, ndonjĂ«herĂ«, pĂ«rkundrazi, kishte shumĂ« indekse, tĂ« cilat e vĂ«shtirĂ«sonin inserimin. Duhej tĂ« modifikoheshin rreth 20 tabela â transaksioni pĂ«r krijimin e njĂ« porosie mund tĂ« zgjaste rreth 3-5 sekonda.Â
Të dhënat në tabela nuk ishin gjithmonë në formën më të përshtatshme. Diku duhej të bëhej denormalizim. Një pjesë e të dhënave që merreshin rregullisht ishte në një kolone në formën e një strukture XML, kjo e rritte kohën e ekzekutimit, zgjaste kërkesat dhe e komplikonte zhvillimin.
Ngarkoheshin shumĂ« kĂ«rkesa tĂ« larmishme. VeçanĂ«risht vuajtĂ«n tabelat e njohura, si tabela e pĂ«rmendur orders ose tabela pizzeria. Ato pĂ«rdoren pĂ«r tĂ« treguar ndĂ«rfaqen operative nĂ« kuzhinĂ«, analitikĂ«n. Po ashtu, u referoheshin nga uebsajti (), ku nĂ« çdo moment mund tĂ« vinin papritur shumĂ« kĂ«rkesa.Â
TĂ« dhĂ«nat nuk ishin tĂ« agreguara dhe shumĂ« llogaritje ndodhnin nĂ« fluturim me mjetet e bazĂ«s. Kjo krijonte llogaritje tĂ« panevojshme dhe njĂ« ngarkesĂ« shtesĂ«.Â
Shpesh, kodi hynte nĂ« bazĂ« kur nuk kishte pse ta bĂ«nte kĂ«tĂ«. Diku mungonin operacionet bulk, diku duhej tĂ« shpĂ«rndaheshin njĂ« kĂ«rkesĂ« nĂ« disa tĂ« tjera pĂ«rmes kodit, pĂ«r tĂ« pĂ«rshpejtuar dhe rritur besueshmĂ«rinĂ«.Â
Lidhshmëria dhe ngathtësia në kod
Modulet, të cilat duhej të përgjigjeshin për sektorin e tyre të biznesit, nuk e bënin këtë me sinqeritet.. Disa prej tyre kishin dublim të funksioneve për rolet. Për shembull, një marketer lokal, i cili përgjigjej për aktivitetin marketingut në rrjet në qytetin e tij, ishte e nevojshme që të përdorte si ndërfaqen "Administrator" (për krijimin e promovimeve), ashtu edhe ndërfaqen "Menaxheri i Zyrës" (për të parë ndikimin e promovimeve në biznes). Sigurisht, brenda të dy modulit përdornin një shërbim të përbashkët, i cili punonte me promovimet bonus.
Shërbimet (klasat brenda një projekti të madh monolitik) mund të thërrisnin njëra-tjetrën për të pasuruar të dhënat e tyre.
Me klasat e modeleve vetĂ«, tĂ« cilat ruanin tĂ« dhĂ«nat, puna nĂ« kod bĂ«hej nĂ« mĂ«nyra tĂ« ndryshme. Diku kishte konstruktora, pĂ«rmes tĂ« cilave mund tĂ« specifikonin fushat e detyrueshme. Diku kjo bĂ«hej pĂ«rmes pronave publike. Sigurisht, marrja dhe pĂ«rpunimi i tĂ« dhĂ«nave nga baza ishte e larmishme.Â
Logjika ishte ose nĂ« kontrollet, ose nĂ« klasat e shĂ«rbimeve.Â
KĂ«to duken si probleme tĂ« vogla, por ato ngadalĂ«sonin shumĂ« zhvillimin dhe ulin cilĂ«sinĂ«, qĂ« çonte nĂ« paqĂ«ndrueshmĂ«ri dhe gabime.Â
Kompleksiteti i zhvillimit të madh
Vështirësitë ndodhën edhe në zhvillim. Duhej të bëheshin blloqe të ndryshme të sistemit, për më tepër paralelisht. Përfshirja e nevojave të çdo komponenti në një kod të vetme po bëhej gjithnjë e më e vështirë. Nuk ishte e lehtë të binin dakord dhe të kënaqnin të gjithë komponentët njëkohësisht. Këtyre iu shtuan kufizimet në teknologji, veçanërisht në lidhje me bazën dhe front-endin. Duhej të heqeshim dorë nga JQuery në favor të kornizave të nivelit të lartë, sidomos në pjesën e shërbimeve klientike (faqja).
NĂ« disa pjesĂ« tĂ« sistemit mund tĂ« pĂ«rdoret baza, mĂ« e pĂ«rshtatshme pĂ«r kĂ«tĂ«. PĂ«r shembull, mĂ« vonĂ« patĂ«m njĂ« precedent kalimi nga Redis nĂ« CosmosDB pĂ«r ruajtjen e shportĂ«s sĂ« porosisĂ«.Â
Ekipet dhe zhvilluesit qĂ« merren me fushat e tyre, qartĂ« donin mĂ« shumĂ« autonomi pĂ«r shĂ«rbimet e tyre, si nĂ« aspektin e zhvillimit, ashtu edhe nĂ« atĂ« tĂ« publikimit. Konfliktohen gjatĂ« bashkimit, probleme gjatĂ« lĂ«shimeve. NĂ«se pĂ«r 5 zhvillues kĂ«tĂ« problem nuk Ă«shtĂ« substancial, pĂ«r 10, e sidomos nĂ« rritjen e planifikuar, gjithçka do tĂ« bĂ«hej mĂ« serioze. Dhe pĂ«rpara duhej tĂ« kishte zhvillim tĂ« aplikacionit mobil (ai filloi nĂ« 2017, dhe nĂ« 2018 ishte ).Â
Pjesë të ndryshme të sistemit kërkonin tregues të ndryshëm stabiliteti., por shkak të lidhjes së fortë të sistemit, ne nuk mund ta siguronim këtë. Një gabim në zhvillimin e një funksioni të ri në panel mund të ishte shkaktari i problematikave gjatë procesit të porosisë në faqe, pasi kodi është i përbashkët dhe i ricikluar, baza dhe të dhënat gjithashtu janë të njëjta.
Ndoshta do të ishte e mundur të mos lejohej këto gabime dhe probleme në kuadër të një arkitekture monolitike-modulare: të bëhej ndarja e përgjegjësive, të kryhej refaktorizimi si i kodit, ashtu edhe i bazës së të dhënave, të ndaheshin qartë shtresat nga njëra-tjetra, dhe të kontrollohej cilësia çdo ditë. Por vendimet arkitektonike të zgjedhura dhe fokusimi në zgjerimin e shpejtë të funksionalitetit të sistemit çuan në probleme sa i përket stabilitetit.
Si blogu Sila e mendjes dërgoi të ardhurat në restorante
NĂ«se rritja e rrjetit tĂ« picerive (dhe ngarkesave) do tĂ« vazhdonte me tĂ« njĂ«jtin ritĂ«m, pas disa kohĂ«sh rĂ«niet do tĂ« ishin tĂ« tilla qĂ« sistemi nuk do tĂ« ngrinte mĂ«. NjĂ« histori e tillĂ« ilustron mirĂ« problemet me tĂ« cilat filluam tĂ« pĂ«rballeshim nĂ« vitin 2015.Â
NĂ« blogun ââ kishte njĂ« widget qĂ« shfaqte tĂ« dhĂ«nat mbi tĂ« ardhurat pĂ«r vitin e gjithĂ« rrjetit. Widgeti i referohej API-sĂ« publike Dodo, e cila ofron kĂ«to tĂ« dhĂ«na. Tani kjo statistikĂ« Ă«shtĂ« e disponueshme nĂ« . Widgeti shfaqej nĂ« çdo faqe dhe bĂ«nte kĂ«rkesa nĂ« intervale çdo 20 sekonda. KĂ«rkesa shkonte nĂ« api.dodopizza.ru dhe kĂ«rkonte:
numrin e picerive në rrjet;
të ardhurat totale të rrjetit nga fillimi i vitit;
të ardhurat për sot.
KĂ«rkesa pĂ«r statistikĂ«n mbi tĂ« ardhurat shkonte direkt nĂ« bazĂ« dhe fillonte tĂ« kĂ«rkonte tĂ« dhĂ«nat mbi porositĂ«, duke i agreguar ato nĂ« kohĂ« reale dhe duke dhĂ«nĂ« shumĂ«n.Â
Në të njëjtën tabelë porosish hynin Kassat në restorante, nxirrnin listën e porosive të pranuara për sot, dhe përfshinin edhe porosi të reja. Kassat bënin kërkesat e tyre çdo 5 sekonda ose me rinovimin e faqes.
Skema dukej kështu:
Një herë në vjeshtë, Fyodor Ovchinnikov shkroi një artikull të gjatë dhe popullor në blogun e tij. Në blog erdhën shumë njerëz dhe filluan ta lexonin me kujdes. Ndërsa secili nga ata që erdhën lexonte artikullin, widgeti me të ardhurat punonte siç duhet dhe bënte kërkesa në API çdo 20 sekonda.
API ka thirrur procedurĂ«n e ruajtur pĂ«r llogaritjen e shumĂ«s sĂ« tĂ« gjitha porosive qĂ« nga fillimi i vitit nĂ« tĂ« gjitha pica-terit e rrjetit. Agregimi po bĂ«hej mbi tabelĂ«n porositĂ«, e cila Ă«shtĂ« shumĂ« e njohur. NĂ« tĂ« hynin tĂ« gjitha kasat e tĂ« gjitha restoranteve tĂ« hapura nĂ« atĂ« moment. Kassat ndaluan sĂ« pĂ«rgjiguri, porositĂ« nuk u pranohen. Po ashtu, ato nuk pranoheshin nga faqja, nuk shfaqeshin nĂ« tracker, menaxheri i ndĂ«rrimit nuk mund t'i shihte ato nĂ« ndĂ«rfaqen e tij.Â
Kjo nuk është historia e vetme. Deri në vjeshtën e vitit 2015, ngarkesa në sistem ishte kritike çdo të premte. Disa herë e çuam jashtë funksionit API publik, dhe një herë, na duhej madje të fiknim faqen, sepse asgjë nuk ndihmonte. Madje kishte një listë shërbimesh me rregullin e fikjes në rast ngarkesash serioze.
Nga kjo kohë fillon lufta jonë me ngarkesat dhe për stabilizimin e sistemit (nga vjeshta e vitit 2015 deri në vjeshtën e vitit 2018). Pikërisht atëherë ndodhi "". Përpara ndodhnin ndodhi herë pas here, disa ishin shumë të ndjeshme, por periudha e përgjithshme e paqëndrueshmërisë tani mund të konsiderohet e kaluar.
Rritja e shpejtë e biznesit
Pse nuk mund të "bëhej menjëherë mirë"? Mjafton të shikosh grafikun e mëposhtëm.
Gjithashtu, në vitet 2014-2015 u hap një degë në Rumani dhe u përgatit hapja e një dege në SHBA.
Rrjeti po rritej shumë shpejt, po hapeshin vende të reja, po shfaqeshin formate të reja të picerive, për shembull, një pica-ter është hapur në një food court. Të gjitha këto kërkonin vëmendje të konsiderueshme pikërisht për zgjerimin e funksioneve Dodo IS. Pa të gjitha këto funksione, pa gjurmimin në kuzhinë, regjistrimin e produkteve dhe humbjeve në sistem, shfaqjen e porosive në sallën e food court, nuk do të flisnim tani për "arkitekturën e duhur" dhe "qasjen e saktë" në zhvillim.
Po ashtu pengesat për rishikimin e kohës së arkitekturës dhe në përgjithësi vëmendjen ndaj problemeve teknike ishte kriza e vitit 2014. Këto gjëra godasin rëndë mundësitë për rritjen e ekipeve, veçanërisht për bizneset e reja, siç ishte Dodo Pica.
Zgjidhjet e shpejta që ndihmuan
Problemet kërkonin zgjidhje. Në mënyrë të përgjithshme, zgjidhjet mund të ndahen në 2 grupe:
Të shpejtat, të cilat shuajnë zjarrin dhe ofrojnë një rezervë të vogël forcë dhe na fitojnë kohë për ndryshime.
Sistematike dhe, pĂ«r kĂ«tĂ« arsye, tĂ« gjatĂ«. Ristrukturimi i disa moduleve, ndarja e arkitekturĂ«s monolitike nĂ« shĂ«rbime tĂ« veçanta (shumica e tyre janĂ« pĂ«r t'u konsideruar mĂ« shumĂ« makro-shĂ«rbime sesa mikro, dhe pĂ«r kĂ«tĂ« ka) ).Â
Lista e shkurtër e ndryshimeve është si vijon:
Shkalla deri te master baza
Sigurisht, e para gjë që bëhet për të përballuar ngarkesat është të rritet fuqia e serverit. Kjo është bërë për master bazën dhe për serverët web. Fatkeqësisht, kjo është e mundur vetëm deri në një kufi të caktuar, më tej bëhet shumë e shtrenjtë.
QĂ« nga viti 2014 ne kaluam nĂ« Azure, pĂ«r kĂ«tĂ« temĂ« ne gjithashtu kemi shkruar qĂ« nĂ« atĂ« kohĂ« nĂ« artikullin "". Por pas njĂ« vargu rritjesh tĂ« serverĂ«ve pĂ«r bazĂ«n, ne u goditĂ«m nga çmimi.Â
Replika e bazës për lexim
U krijuan dy replika për bazën:
ReadReplica për kërkesa mbi referencat. Ajo përdoret për leximin e referencave, si qytetet, rrugët, pizzëritë, produktet (domen afatshkurtër të ndryshuar), dhe në ato ndërfaqe ku pranohet një vonesë e vogël. Këto replika ishin 2, ne i siguruan ato po ashtu si masterin.
ReadReplica pĂ«r kĂ«rkesa mbi raporte. NĂ« kĂ«tĂ« bazĂ«, disponueshmĂ«ria ishte mĂ« e ulĂ«t, por tĂ« gjitha raportet kalonin aty. Edhe pse kishte kĂ«rkesa tĂ« rĂ«nda mbi pĂ«rllogaritje tĂ« mĂ«dha, ato nuk ndikojnĂ« nĂ« bazĂ«n kryesore dhe nĂ« ndĂ«rfaqet operative.Â
Cache në kod
Nuk kishte kesh në kod (asgjë). Kjo shkaktonte kërkesa shtesë, jo gjithmonë të nevojshme, në bazën e ngarkuar. Kesh ishin fillimisht në memorje, si dhe në një shërbim të jashtëm për kesh, ishte Redis. Të gjitha u invaliduan sipas kohës, konfigurimet u tregoheshin në kod.
Disa servera për backend
Backend i aplikacionit gjithashtu duhej tĂ« jetĂ« e pĂ«rshtatur pĂ«r tĂ« pĂ«rballuar ngarkesat e rritura. Duhej bĂ«rĂ« njĂ« klaster nga njĂ« server i vetĂ«m i iis. Ne e transferuam nga memorja nĂ« RedisCache, gjĂ« qĂ« lejoj tĂ« ketĂ« disa servera, qĂ« qĂ«ndrojnĂ« pas njĂ« balancuesi thjeshtĂ« ngarkese me round robin. Fillimisht u pĂ«rdor i njĂ«jti Redis, qĂ« pĂ«rdorej edhe pĂ«r keshĂ«t, pastaj u shpĂ«rndan nĂ« disa.Â
NĂ« fund, arkitektura u komplikuar...
...por një pjesë e tensionit arriti të hiqet.
Dhe më pas duhej të riemërtoheshin komponentët e ngarkuar, për të cilat ne u angazhuam. Për këtë do të flasim në pjesën tjetër.
Burimi: habr.com
