Ose kompani të pafat me monolitin janë të pafat në mënyra të ndryshme.
Zhvillimi i sistemit Dodo IS filloi menjĂ«herĂ« pas themelimit tĂ« biznesit Dodo Pizza nĂ« vitin 2011. Ideja ishte digitalizimi i plotĂ« dhe total i proceseve tĂ« biznesit, , gjĂ« qĂ« atĂ«herĂ« nĂ« vitin 2011 shkaktoi shumĂ« pyetje dhe skepticizĂ«m. Por tani, pas 9 vjetĂ«sh, ne vazhdojmĂ« nĂ« kĂ«tĂ« rrugĂ« â me zhvillimin tonĂ«, qĂ« filloi me njĂ« monolit.
Ky artikull është "përgjigje" ndaj pyetjeve "Pse të rishkruhet arkitektura dhe të bëhen ndryshime kaq të mëdha dhe të gjatë?" ndaj artikullit të mëparshëm Do të filloj me se si filloi zhvillimi i Dodo IS, si dukej arkitektura origjinale, si u shfaqën modulet e reja dhe për çfarë problemesh duhej të bëheshin ndryshime të mëdha.
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 klient: fasada mbi bazĂ«n (2016-2017). (NĂ« procesâŠ)
Historia e mikrosherbimeve reale. (2018-2019). (NĂ« procesâŠ)
PĂ«rfundimi i ndarjes sĂ« monolitit dhe stabilizimi i arkitekturĂ«s. (NĂ« procesâŠ)
Arkitektura origjinale
Në vitin 2011, arkitektura Dodo IS dukej kështu:
Moduli i parĂ« nĂ« arkitekturĂ« â pranimi i porosisĂ«. Procesi i biznesit ishte si mĂ« poshtĂ«:
klienti telefonon në pizzeria;
menaxheri përgjigjet;
ai merr porosinë përmes telefonit;
paralelisht e regjistron atĂ« nĂ« ndĂ«rfaqen e pranimit tĂ« porosisĂ«: informacioni pĂ«r klientin, detajet e porosisĂ«, adresa e dĂ«rgesĂ«s, merren parasysh.Â
Ndërfaqja e sistemit informativ dukej 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Ă«hej shumĂ«, shpejt dhe me njĂ« grup tĂ« vogĂ«l. Grupi i vogĂ«l â ishin 2 zhvillues qĂ« ndĂ«rtuan themelet e tĂ« gjithĂ« sistemit tĂ« ardhshĂ«m.
Zgjidhja e parë e tyre përcaktoi fatin e stacks teknologjike:
Backend në ASP.NET MVC, gjuha C#. Zhvilluesit ishin dotnetçinj, kjo stack ishte e njohur dhe e këndshme për ta.
Frontend nĂ« Bootstrap dhe JQuery: ndĂ«rfaqet e pĂ«rdoruesit nĂ« stile dhe skripta tĂ« shkruar vetĂ«.Â
Baza e tĂ« dhĂ«nave MySQL: pa shpenzime pĂ«r licenca, e lehtĂ« pĂ«r tâu pĂ«rdorur.
Serverë në Windows Server, sepse .NET atëherë mund të ishte vetëm nën Windows (nuk do të flasim për Mono).
Fizikisht, gjithĂ« kjo ishte shprehur nĂ« "dedikimin e hostit".Â
Arkitektura e aplikacionit të pranimit të porosisë
Atëherë, të gjithë flisnin për mikroshërbime dhe 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.
Ja ajo.
Asp.Net MVC â Ă«shtĂ« Razor, qĂ« jep HTML-nĂ« nĂ« kĂ«rkesĂ« nga forma ose nga klienti me renderim nĂ« server. NĂ« klient, CSS dhe JS-skriptet tregojnĂ« informacionin dhe, sipas nevojĂ«s, kryejnĂ« kĂ«rkesa AJAX pĂ«rmes JQuery.
KĂ«rkesat nĂ« server shkojnĂ« nĂ« klasat *Controller, ku metodat trajtojnĂ« dhe gjenerojnĂ« HTML-nĂ« pĂ«rfundimtare. Kontrollet bĂ«jnĂ« kĂ«rkesa pĂ«r nivelin e logjikĂ«s, tĂ« quajtur *Services. Ădo shĂ«rbim ishte pĂ«rgjegjĂ«s pĂ«r njĂ« aspekt tĂ« caktuar tĂ« biznesit:
PĂ«r shembull, DepartmentStructureService jepte informacion pĂ«r pizzeritĂ«, pĂ«r departamentet. Departamenti â Ă«shtĂ« njĂ« grup pizzerish nĂ«n menaxhimin e njĂ« franchaizieri.
ReceivingOrdersService pranon dhe llogarit përmbajtjen e porosisë.
SmsService dërgon SMS, duke thirrur shërbimet e API për dërgimin e SMS.
ShĂ«rbimet trajtojnĂ« tĂ« dhĂ«nat nga baza, ruajnĂ« logjikĂ«n e biznesit. NĂ« çdo shĂ«rbim ka njĂ« ose mĂ« shumĂ« *Repository me emrin pĂ«rkatĂ«s. NĂ« to gjenden kĂ«rkesat pĂ«r procedurat e ruajtura nĂ« bazĂ« dhe niveli i mapperĂ«ve. NĂ« prosedurat e ruajtura ishte logjika e biznesit, veçanĂ«risht shumĂ« nĂ« ato qĂ« jepnin tĂ« dhĂ«na raportuese. ORM nuk u pĂ«rdor, tĂ« gjithĂ« mbĂ«shteteshin nĂ« SQL tĂ« shkruar me dorĂ«.Â
Ishte gjithashtu një nivel modeli domene dhe klasash ndihmëse të zakonshme, për shembull, klasa Order, që mbante porosinë. Atje, në nivel, kishte një ndihmës për metamorfizimin e tekstit të paraqitjes sipas valutos së zgjedhur.
Të gjithë këto mund të paraqiten në një model të tillë:
Rruga e porosisë
Le të shqyrtojmë rrugën e thjeshtëzuar të krijimit të një porosie të tillë.
Fillimisht, faqja ishte statike. Ajo kishte çmime, dhe sipĂ«r â numri i telefonit dhe shpallja "DĂ«shiron pica â telefononi dhe porositni". PĂ«r porosinĂ«, na duhej tĂ« realizonim njĂ« rrjedhĂ« tĂ« thjeshtĂ«:Â
Klienti hyn në faqen statike me çmimet, zgjedh produktet dhe telefonon numrin që është i shënuar në faqen.
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.
Gjithçka fillon me shfaqjen e menusë. Një përdorues-operator i identifikuar pranon vetëm një porosi në një moment të caktuar. Pra, karroca draft mund të ruhen në sesionin e tij (seanca e përdoruesit ruhet në memorie). Atje është objekti Cart, në të cilin ndodhen produktet dhe informacioni për klientin.
Klienti përmend produktin, operatori klikon në + pranë produktit dhe dërgohet një kërkesë në server. Informacioni për produktin merret nga baza dhe shtohet në informacionin e produktit në karrocë.
ShĂ«nim. Po, kĂ«tu nuk Ă«shtĂ« e nevojshme tĂ« nxirrni produktin nga baza, por mund tĂ« transferoni nga frontend. MegjithatĂ«, pĂ«r qartĂ«si unĂ« e tregova kĂ«tĂ« rrugĂ« nga baza.Â
Pastaj, futni adresĂ«n dhe emrin e klientit.Â
Kur klikoni "Krijo porosi":
Kërkesa dërgohet në OrderController.SaveOrder().
Merrni Kartën nga sesioni, ku ndodhen produktet në sasinë e duhur.
PlotĂ«soni KartĂ«n me informacionin e klientit dhe kaloni nĂ« metodĂ«n AddOrder tĂ« klasĂ«s ReceivingOrderService, ku ajo ruhet nĂ« bazĂ«.Â
Në bazë ka tabela për porosinë, përbërjen e porosisë, klientin dhe të gjitha janë të lidhura.
Interfaci i shfaqjes së porosisë merr dhe nxjerr porositë më të fundit dhe i shfaq ato.
Module të reja
Pranimi i porosisĂ« ishte i rĂ«ndĂ«sishĂ«m dhe i nevojshĂ«m. Nuk mund tĂ« bĂ«sh biznes me shitjen e picave nĂ«se nuk ke njĂ« sistem pĂ«r pranimin e porosive. Prandaj, sistemi filloi tĂ« zhvillohet me funksionalitete - nga rreth 2012 deri nĂ« 2015. GjatĂ« kĂ«saj periudhe u krijuan shumĂ« seksione tĂ« ndryshme tĂ« sistemit, tĂ« cilat do t'i quaj. modula, nĂ« kundĂ«rshtim me konceptin e shĂ«rbimit ose produktit.Â
Moduli është një grup funksionesh që janë të bashkuara me një qëllim të përbashkët biznesor. Përveç kësaj, ato ndodhen fizikisht në një aplikacion.
Modulat mund tĂ« quhen blloqe tĂ« sistemit. PĂ«r shembull, ky Ă«shtĂ« moduli i raporteve, ndĂ«rfaqet e adminit, , autorizimi. TĂ« gjitha kĂ«to janĂ« ndĂ«rfaqe tĂ« ndryshme pĂ«r pĂ«rdoruesin, disa prej tĂ« cilave kanĂ« madje stile vizuale tĂ« ndryshme. MegjithatĂ«, tĂ« gjitha janĂ« brenda njĂ« aplikacioni, njĂ« procesi funksional.Â
Nga pikĂ«pamja teknike, modulat ishin tĂ« organizuara si Area (njĂ« ide e tillĂ« ka mbetur nĂ« ). Aty ishin skedarĂ« tĂ« veçantĂ« pĂ«r frontend, modelet, si dhe klasat e tyre tĂ« kontrollorĂ«ve. NĂ« fund, sistemi u transformua nga njĂ«âŠ
âŠnĂ« njĂ« tĂ« tillĂ«:
Disa modulet janë realizuar si faqe të veçanta (projekte ekzekutiv), për shkak të funksionalitetit të veçantë dhe pjesërisht për shkak të zhvillimit më të fokusuar. Këto janë:
Site â i faqes dodopizza.ru.
Eksport: eksportimi i raporteve nga Dodo IS pĂ«r 1C.Â
Personal â zyra personale e punonjĂ«sit. U zhvillua veçmas dhe ka pikĂ«n e tij tĂ« hyrjes dhe njĂ« dizajn tĂ« veçantĂ«.
fs â projekt pĂ«r hostimin e statikĂ«s. MĂ« vonĂ« e braktisĂ«m, duke transferuar tĂ« gjithĂ« statikĂ«n nĂ« CDN Akamai.Â
Blloqet e tjera ishin brenda aplikacionit BackOffice.Â
Shpjegimi për emrat:
Cashier â Kasa e restorantit.
ShiftManager â ndĂ«rfaqet pĂ«r rolin "Menaxheri i ndĂ«rrimit": statistika operative pĂ«r shitjet e picave, mundĂ«sia pĂ«r tĂ« vendosur produkte nĂ« listĂ«n e bardhĂ«, tĂ« ndryshoni porosinĂ«.
OfficeManager â ndĂ«rfaqet pĂ«r rolin "Menaxher i picerisĂ«" dhe "FrashizĂ«". KĂ«tu janĂ« mbledhur funksionet pĂ«r konfigurimin e picerisĂ«, promovimet e saj, pranimin dhe punĂ«n me punonjĂ«sit, raportet.
PublicScreens â ndĂ«rfaqet pĂ«r televizorĂ«t dhe tabletĂ«t, qĂ« varen nĂ« piceritĂ«. NĂ« televizorĂ« shfaqet menuja, informacioni reklamues, statusi i porosisĂ« nĂ« momentin e 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 në tjetrin. Gjithashtu, disa faqe të veçanta, si dodopizza.ru ose personal.dodopizza.ru, shkonin në shërbime të përbashkëta.
Kur shfaqeshin modulet e reja, pĂ«rpiqeshim maksimalisht tĂ« ripĂ«rdorim kodin ekzistues tĂ« shĂ«rbimeve, procedurave tĂ« ruajtura dhe tabelave nĂ« bazĂ«.Â
Për të kuptuar më mirë shkallën e moduleve të krijuara në sistem, ja skema nga viti 2012 me planet e zhvillimit:
Deri në vitin 2015, gjithçka që ishte në skemë dhe madje edhe më shumë ishte në prodhim.
Pranimi i porosisë u shndërrua në një bllok të veçantë të Qendrës së Kontaktit, ku porosia pranohej nga një operator.
U shfaqën ekranet publike me menu dhe informacion, që varen në piceri.
Në kuzhinë ka një modul, i cili automatikisht luan një mesazh verbal "Pizza e re" kur bie një porosi e re dhe gjithashtu shtyp një faturë për kurierin. Kjo e thjeshton shumë proceset në kuzhinë dhe i lejon punonjësit të mos shpërqendrohen nga shumë operacione të thjeshta.
Blloku i dorĂ«zimit u shndĂ«rrua nĂ« njĂ« Kasa tĂ« DorĂ«zimit, ku porosia jepet kurierit, i cili Ă«shtĂ« regjistruar paraprakisht nĂ« ndĂ«rrimin. Koha e tij e punĂ«s Ă«shtĂ« marrĂ« parasysh pĂ«r llogaritjen e pagĂ«s.Â
Paralelisht nga 2012 deri nĂ« 2015 u zhvilluan mĂ« shumĂ« se 10 zhvillues, u hapĂ«n 35 piceri, u implementua sistemi nĂ« Rumani dhe u pĂ«rgatit pĂ«r hapjen e pikave nĂ« SHBA. Zhvilluesit tashmĂ« nuk merreshin me tĂ« gjitha detyrat, por ishin tĂ« ndarĂ« nĂ« grupe, secila e specializuar nĂ« atĂ« pjesĂ« tĂ« sistemit.Â
Problemet
Kjo në përputhje me arkitekturën (por jo vetëm).
Kaosi në bazë
NjĂ« bazĂ« â Ă«shtĂ« e pĂ«rshtatshme. NĂ« tĂ« mund tĂ« arrish konsistencĂ«, madje pĂ«rmes mjeteve tĂ« integruara nĂ« bazat relazionale. TĂ« punosh me tĂ« Ă«shtĂ« e zakonshme dhe e lehtĂ«, veçanĂ«risht nĂ«se ka pak tabela dhe pak tĂ« dhĂ«na.
Por katër vjet zhvillimi, baza kishte rreth 600 tabela, 1500 procedura të ruajtura, në shumë nga të cilat kishte edhe logjikë. Fatkeqësisht, procedurat e ruajtura nuk ofrojnë ndonjë avantazh të veçantë kur punoni me MySQL. Ato nuk ruajnë në cache nga baza, dhe ruajtja e logjikës në to e komplikon zhvillimin dhe debugging-un. Rinfoshkimi i kodit gjithashtu është i vështirë.
NĂ« shumĂ« tabela nuk kishte indekse tĂ« pĂ«rshtatshme, ndĂ«rsa nĂ« disa tĂ« tjera kishte shumĂ« indekse, gjĂ« qĂ« e bĂ«nte mĂ« tĂ« vĂ«shtirĂ« shtimin. Duhej tĂ« modifikohen rreth 20 tabela â transaksioni pĂ«r krijimin e porosisĂ« mund tĂ« zgjaste rreth 3-5 sekonda.Â
Të dhënat në tabela nuk ishin gjithmonë në formën më të duhur. Në disa raste duhej të bëhej de-normalizimi. Një pjesë e të dhënave që merrnim rregullisht ishte në një kolonë në formën e një strukture XML, gjë që e rrisnin kohën e ekzekutimit, zgjateshin kërkesat dhe e komplikonin zhvillimin.
PĂ«r tĂ« njĂ«jtat tabela ishin bĂ«rĂ« shumĂ« kĂ«rkesa tĂ« ndryshme. VeçanĂ«risht vuajtĂ«n tabelat e njohura, si tabela e pĂ«rmendur orders apo tabela pizzeria. Ato pĂ«rdorej pĂ«r tĂ« shpĂ«rndarĂ« ndĂ«rfaqet operative nĂ« kuzhinĂ«, analitikĂ«n. Gjithashtu u drejtohej faqes sĂ« internetit (), ku nĂ« çdo moment mund tĂ« kishte shumĂ« kĂ«rkesa tĂ« papritura.Â
TĂ« dhĂ«nat nuk ishin tĂ« agreguara dhe shumĂ« llogaritje ndodhnin nĂ« fluks me ndihmĂ«n e bazĂ«s. Kjo krijonte llogaritje tĂ« tepĂ«rta dhe ngarkesĂ« tĂ« shtuar.Â
Shpesh, kodi hynte nĂ« bazĂ« kur nuk kishte nevojĂ«. NĂ« disa raste mungonin operacionet bulk, ndonjĂ«herĂ« ishte e nevojshme tĂ« ndĂ«rtohej njĂ« kĂ«rkesĂ« mĂ« shumĂ« pĂ«rmes kodit, pĂ«r tĂ« pĂ«rshpejtuar dhe rritur besueshmĂ«rinĂ«.Â
Lidhja dhe ngatërrimi në kod
Modulet, të cilat duhet të ishin përgjegjëse për sektorët e tyre të biznesit, nuk e bënin këtë me ndershmëri.Disa prej tyre kishin përsëritje funksionesh për rolet. Për shembull, marketeri lokal, i cili ishte përgjegjës për aktivitetin marketing të rrjetit në qytetin e tij, duhej të përdorte si ndërfaqen "Admin" (për të krijuar fushata), ashtu edhe ndërfaqen "Menaxheri i Zyrës" (për të parë ndikimin e fushatave në biznes). Sigurisht, brenda të dy moduleve përdorej një shërbim, që punonte me fushatat e bonusit.
Shërbimet (klasa 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-model, qĂ« ruanin tĂ« dhĂ«na, punimi nĂ« kod bĂ«hej nĂ« mĂ«nyra tĂ« ndryshme.NĂ« disa raste kishte konstruktora, pĂ«rmes tĂ« cilĂ«ve mund tĂ« shiheshin fushat e detyrueshme. NĂ« disa tĂ« tjera, kjo bĂ«hej pĂ«rmes pronarĂ«ve publikĂ«. Sigurisht, marrja dhe transformimi i tĂ« dhĂ«nave nga baza ishte i larmishĂ«m.Â
Logjika ishte ose nĂ« kontrollet, ose nĂ« klasat e shĂ«rbimeve.Â
KĂ«to mund tĂ« duken si probleme tĂ« vogla, por ato ngadalĂ«suan shumĂ« zhvillimin dhe ulĂ«n cilĂ«sinĂ«, duke çuar nĂ« paqĂ«ndrueshmĂ«ri dhe gabime.Â
Sfidat e zhvillimit të madh
Problemet u shfaqën edhe në zhvillimin e vetë.Duhej të bëheshin blloqe të ndryshme të sistemit, madje paralelisht. Të vendosësh nevojat e çdo komponente në një kod të vetëm po bëhej gjithnjë e më e vështirë. Nuk ishte e lehtë të arrihej një marrëveshje dhe të kënaqeshin të gjitha komponentet njëherësh. Kësaj i shtoheshin kufizime në teknologji, veçanërisht kur bëhej fjalë për bazën dhe frontend-in. Duhej të hiqeshim nga JQuery drejt framework-ve më të avancuar, veçanërisht në pjesën e shërbimeve klientëve (faqja e internetit).
NĂ« disa pjesĂ« tĂ« sistemit mund tĂ« pĂ«rdoren baza mĂ« tĂ« pĂ«rshtatshme pĂ«r kĂ«tĂ«.PĂ«r shembull, mĂ« vonĂ« kishim njĂ« rast kalimi nga Redis nĂ« CosmosDB pĂ«r ruajtjen e shportĂ«s sĂ« porosisĂ«.Â
Ekipet dhe zhvilluesit, tĂ« cilĂ«t merreshin me fushĂ«n e tyre, dĂ«shironin qartĂ«sisht mĂ« shumĂ« autonomi pĂ«r shĂ«rbimet e tyre, si nĂ« zhvillim ashtu edhe nĂ« lĂ«shim. Konfliktet gjatĂ« bashkimit, probleme gjatĂ« lĂ«shimeve. NĂ«se pĂ«r 5 zhvillues kjo ishte njĂ« problem i parĂ«ndĂ«sishĂ«m, pĂ«r 10, e posaçërisht pĂ«r rritjen e parashikuar, gjithçka do tĂ« bĂ«hej mĂ« serioze. Dhe pĂ«rpara duhej tĂ« zhvillohej njĂ« aplikacion mobil (ai filloi nĂ« 2017, dhe nĂ« 2018 pati ).Â
Pjesë të ndryshme të sistemit kërkonin tregues të ndryshëm të stabilitetit, por për shkak të lidhjes së fortë të sistemit, nuk mundëm ta siguronim këtë. Një gabim në zhvillimin e një funksioni të ri në admin, mund të kishte ndikuar në pranimin e porosisë në faqen e internetit, pasi kodi ishte i përbashkët dhe i ripërdorueshëm, baza dhe të dhënat gjithashtu ishin të njëjta.
Ndoshta, mund të kishte qenë e mundur që edhe në kuadër të një arkitekture monolitike-moderne, të mos lejonim këto gabime dhe probleme: të bënim ndarje përgjegjësish, të bënim refaktorizimin e kodit dhe të bazës së të dhënave, të ndajmë qartë shtresat nga njëra-tjetra, dhe të kontrollojmë cilësinë çdo ditë. Por zgjidhjet arhitektonike të zgjedhura dhe fokusimi në zgjerimin e shpejtë të funksionalitetit të sistemit çuan në probleme në çështjet e stabilitetit.
Si forumi Fuqia e Mendjes vendosi kasat në restorante
NĂ«se rritja e rrjetit tĂ« picerive (dhe ngarkesave) do tĂ« vazhdonte me kĂ«tĂ« ritĂ«m, pas njĂ« kohe rĂ«niet do tĂ« ishin tĂ« tilla qĂ« sistemi nuk do tĂ« ngrihej mĂ«. NjĂ« histori qĂ« ilustron problemet me tĂ« cilat filluam tĂ« pĂ«rballemi nĂ« vitin 2015 Ă«shtĂ« kjo.Â
NĂ« blogun ânisi njĂ« widget qĂ« tregonte tĂ« dhĂ«nat pĂ«r tĂ« ardhurat e gjithĂ« rrjetit pĂ«r njĂ« vit. Widget-i thĂ«rriste API-nĂ« publike Dodo, e cila ofronte kĂ«to tĂ« dhĂ«na. Tani, kĂ«to statistika janĂ« tĂ« disponueshme nĂ« . Widget-i shfaqej nĂ« çdo faqe dhe bĂ«nte kĂ«rkesa çdo 20 sekonda. KĂ«rkesa shkonte nĂ« api.dodopizza.ru dhe kĂ«rkonte:
numrin e picerive në rrjet;
të ardhurat totale të rrjetit që nga fillimi i vitit;
të ardhurat e sotme.
KĂ«rkesa pĂ«r statistikat e tĂ« ardhurave shkonte menjĂ«herĂ« nĂ« bazĂ« dhe fillonte tĂ« kĂ«rkonte tĂ« dhĂ«na pĂ«r porositĂ«, duke agreguar tĂ« dhĂ«nat nĂ« kohĂ« reale dhe duke lĂ«shuar shumĂ«n.Â
Në këtë tavullinë të porosive hynin Kasat në restorante, duke nxjerrë listën e porosive të pranuara për sot, dhe aty shtoheshin porositë e reja. Kasat bënin kërkesa çdo 5 sekonda ose kur refresh-uan faqen.
Skema dukej kështu:
Një herë në vjeshtë, Fedor Ovchinnikov shkroi një artikull të gjatë dhe popullor në blogun e tij. Blogu tërheq shumë njerëz dhe ata filluan ta lexonin me kujdes. Ndërsa çdo person i pranishëm po lexonte artikullin, widget-i i të ardhurave punonte dhe kërkonte API-në çdo 20 sekonda.
API-ja thĂ«rriste njĂ« procedurĂ« tĂ« ruajtur pĂ«r llogaritjen e shumĂ«s sĂ« tĂ« gjitha porosive qĂ« nga fillimi i vitit pĂ«r tĂ« gjitha piceritĂ« e rrjetit. Agregimi bĂ«hej pĂ«r tabelĂ«n e porosive, e cila Ă«shtĂ« shumĂ« e popullarizuar. Aty hynin tĂ« gjitha kasat e restoranteve tĂ« hapura nĂ« atĂ« moment. Kasat ndaluan sĂ« pĂ«rgjiguri, porositĂ« nuk pranoheshin. Ato gjithashtu nuk pranoheshin nga faqja, nuk shfaqeshin nĂ« tracker, menaxheri i ndĂ«rrimit nuk mund tĂ« shihte ato nĂ« ndĂ«rfaqen e tij.Â
Kjo nuk është historia e vetme. Deri në vjeshtën e vitit 2015, çdo të premte ngarkesa në sistem ishte kritike. Disa herë ne fiknim API-në publike, dhe një herë, na duhej madje të fiknim faqen, sepse asgjë tjetër nuk ndihmoi. Kishte madje një listë shërbimesh me rendin e fikjes për ngarkesa të rënda.
Nga ky moment fillon lufta jonĂ« me ngarkesat dhe pĂ«r stabilizimin e sistemit (nga vjeshta e 2015 deri nĂ« vjeshtĂ«n e 2018). PikĂ«risht atĂ«herĂ« ndodhi ââ. Edhe mĂ« pas, herĂ« pas here ndodhnin prishje, disa prej tĂ« cilave ishin mjaft tĂ« ndjeshme, por periudha e pĂ«rgjithshme e destabilitetit tani mund tĂ« quhet e kaluar.
Rritja e madhe e biznesit
Pse nuk mund tĂ« âbĂ«hej menjĂ«herĂ« mirĂ«â? Mjafton tĂ« shohĂ«sh grafiket nĂ« vijim.
Gjithashtu, në vitet 2014-2015 u hap një pikë në Rumani dhe po përgatitej hapja në SHBA.
Rrjeti po rritej shumĂ« shpejt, po hapeshin vende tĂ« reja, po shfaqeshin formate tĂ« reja picerish, pĂ«r shembull, u hap njĂ« piceri nĂ« food court. E gjithĂ« kjo kĂ«rkonte njĂ« vĂ«mendje tĂ« konsiderueshme nĂ« zgjerimin e funksioneve Dodo IS. Pa tĂ« gjitha kĂ«to funksione, pa gjurmimin nĂ« kuzhinĂ«, llogaritjen e produkteve dhe humbjeve nĂ« sistem, shfaqjen e porosive nĂ« sallĂ«n e food court, vĂ«shtirĂ« se do tĂ« diskutonim tani pĂ«r arkitekturĂ«n âe duhurâ dhe qasjen âe saktĂ«â nĂ« zhvillim.
Pengesat për rivlerësimin në kohë të arkitekturës dhe vëmendjes në problemet teknike, ishin kriza e vitit 2014. Këto gjëra godasin rëndë mundësitë për rritjen e grupeve, veçanërisht për biznesin e ri siç ishte Dodo Pizza.
Zgjidhjet e shpejta që ndihmuan
Problemet kërkonin zgjidhje. Në mënyrë relative, zgjidhjet mund të ndahen në 2 grupe:
Të shpejta, të cilat shuhin zjarri dhe japin një rezervë të vogël stabiliteti dhe na fitojnë kohë për ndryshime.
Sistematike dhe, prandaj, tĂ« gjata. Riinxhirimi i disa moduleve, ndarja e arkitekturĂ«s monolite nĂ« shĂ«rbime tĂ« veçanta (shumica nga to nuk janĂ« nĂ« fakt mikro, por mĂ« shumĂ« makro-shĂ«rbime dhe pĂ«r kĂ«tĂ« ka ).Â
Lista e thjeshtë e ndryshimeve të shpejta është si vijon:
Rritja e kapacitetit të master bazës
Sigurisht, gjëja e parë që bëhet për të përballuar ngarkesat është rritja e kapacitetit të serverit. Kjo u bë për master bazën dhe për serverat web. Fatkeqësisht, kjo është e mundur vetëm deri në një kufi të caktuar, më pas bëhet shumë e shtrenjtë.
QĂ« nga viti 2014 ne kaluam nĂ« Azure, pĂ«r kĂ«tĂ« tema ne gjithashtu kemi shkruar atĂ«herĂ« nĂ« artikullin ââ. Por pas njĂ« sĂ«rĂ« rritjesh tĂ« serverit pĂ«r bazĂ«n, u penguam nĂ« koston.Â
Replicat e bazës për lexim
Bëri dy replika për bazën:
ReadReplica për kërkesat për registrat. Përdoret për leximin e regjistrave, si qytete, rrugë, piceri, produkte (domene të ngadalta), dhe në ato ndërfaqe ku pranohet një vonesë e vogël. Këto replika ishin 2, ne siguronim disponueshmërinë e tyre ashtu si edhe masterin.
ReadReplica pĂ«r kĂ«rkesat pĂ«r raporte. Kjo bazĂ« kishte njĂ« disponueshmĂ«ri mĂ« tĂ« ulĂ«t, por pĂ«rfshinte tĂ« gjitha raportet. Le tĂ« kenĂ« kĂ«rkesa tĂ« rĂ«nda pĂ«r pĂ«rllogaritje tĂ« mĂ«dha tĂ« tĂ« dhĂ«nave, por ato nuk ndikonin nĂ« bazĂ«n kryesore dhe nĂ« ndĂ«rfaqet operative.Â
Keshat në kod
Keshat në kod nuk ishin askund (përgjithësisht). Kjo çonte në kërkesa shtesë, jo gjithmonë të nevojshme, në bazën e ngarkuar. Keshat ishin fillimisht në memorie dhe gjithashtu në një shërbim të jashtëm të keshit, ishte Redis. Të gjitha invalidoheshin me kohë, cilësimet përcaktoheshin në kod.
Disa serverë për backend
Backend i aplikacionit gjithashtu duhet tĂ« shkallĂ«zohej pĂ«r tĂ« pĂ«rballuar ngarkesat e rritura. Duhej tĂ« krijonim njĂ« klaster nga njĂ« server i caktuar i iis. Ne transferuam nga memorie nĂ« RedisCache, e cila lejoi tĂ« krijoheshin disa serverĂ« qĂ« qendronin pas njĂ« balancuesi tĂ« thjeshtĂ« ngarkese me round robin. Fillimisht u pĂ«rdor tĂ« njĂ«jtin Redis si pĂ«r keshat, pastaj i ndamĂ« nĂ« disa.Â
Si pasojë, arkitektura u komplikuar...
...por një pjesë e ngarkesës u lehtësua.
Dhe më pas duhej të ripërkraheshin komponentët e ngarkuar, për të cilat ne filluam. Për këtë do flasim në pjesën tjetër.
Burimi: habr.com
