🥇Historia e Arkitekturës Dodo IS: Monoliti i hershëm

Ose çdo kompani e pakënaqur me një monolit është e pakënaqur në mënyrën e vet.

Zhvillimi i sistemit Dodo IS filloi menjëherë, si biznesi Dodo Pizza, në 2011. Ai u bazua në idenë e dixhitalizimit të plotë dhe total të proceseve të biznesit, dhe më vete, e cila edhe atëherë në vitin 2011 shkaktoi shumë pikëpyetje dhe skepticizëm. Por tash e 9 vjet ne kemi ndjekur këtë rrugë - me zhvillimin tonë, i cili filloi me një monolit.

Ky artikull është një "përgjigje" për pyetjet "Pse të rishkruhet arkitektura dhe të bëhen ndryshime kaq të mëdha dhe afatgjata?" kthehu te artikulli i mëparshëm "Historia e Arkitekturës Dodo IS: Rruga e zyrës së pasme". Do të filloj me mënyrën se si filloi zhvillimi i Dodo IS, si dukej arkitektura origjinale, si u shfaqën modulet e reja dhe për shkak të problemeve që duheshin bërë ndryshime në shkallë të gjerë.

Seria e artikujve "Çfarë është Dodo IS?" tregon për:

Monoliti i hershëm në Dodo IS (2011-2015). (ti je ketu)
Rruga e zyrës së pasme: baza dhe autobus të ndara.
Rruga nga ana e klientit: fasada mbi bazën (2016-2017). (Në vazhdim...)
Historia e mikroshërbimeve reale. (2018-2019). (Në vazhdim...)
Përfundoi sharrimi i monolitit dhe stabilizimi i arkitekturës. (Në vazhdim...)

Arkitektura fillestare

Në vitin 2011, arkitektura Dodo IS dukej kështu:

Moduli i parë në arkitekturë është pranimi i porosive. Procesi i biznesit ishte:

klienti thërret piceri;
menaxheri e merr telefonin;
pranon një porosi me telefon;
e plotëson atë paralelisht në ndërfaqen e pranimit të porosisë: merren parasysh informacioni për klientin, të dhënat për detajet e porosisë, adresa e dorëzimit.

Ndërfaqja e sistemit të informacionit dukej diçka e tillë ...

Versioni i parë nga tetori 2011:

Është përmirësuar pak në janar 2012

Dodo Pizza Information System Dorëzim Pica Restaurant

Burimet për zhvillimin e modulit të marrjes së porosisë së parë ishin të kufizuara. Na u desh të bënim shumë, shpejt dhe me një ekip të vogël. Një ekip i vogël është 2 zhvillues që hodhën themelet për të gjithë sistemin e ardhshëm.

Vendimi i tyre i parë përcaktoi fatin e grumbullit të teknologjisë:

Backend në ASP.NET MVC, gjuhën C#. Zhvilluesit ishin dotnetchiki, kjo pirg ishte e njohur dhe e këndshme për ta.
Frontend në Bootstrap dhe JQuery: ndërfaqet e përdoruesit në stilet dhe skriptet e shkruara vetë.
Baza e të dhënave MySQL: pa kosto licence, e lehtë për t'u përdorur.
Serverët në Windows Server, sepse .NET atëherë mund të ishte vetëm nën Windows (ne nuk do të diskutojmë Mono).

Fizikisht, e gjithë kjo shprehej në "dedik tek pritësi".

Arkitektura e aplikimit për marrjen e porosive

Atëherë të gjithë po flisnin tashmë për mikroshërbime, dhe SOA u përdor në projekte të mëdha për 5 vjet, për shembull, WCF u lëshua në 2006. Por më pas ata zgjodhën një zgjidhje të besueshme dhe të provuar.

Ja ku eshte.

Asp.Net MVC është Razor, i cili, me kërkesë nga një formular ose nga një klient, jep një faqe HTML me paraqitjen e serverit. Në klient, skriptet CSS dhe JS shfaqin tashmë informacion dhe, nëse është e nevojshme, kryejnë kërkesat AJAX përmes JQuery.

Kërkesat në server përfundojnë në klasat *Controller, ku përpunimi dhe gjenerimi i faqes përfundimtare HTML bëhet në metodë. Kontrollorët bëjnë kërkesa për një shtresë logjike të quajtur *Shërbime. Secili prej shërbimeve korrespondonte me disa aspekte të biznesit:

Për shembull, DepartmentStructureService dha informacion mbi piceri, mbi departamente. Një departament është një grup piceri i drejtuar nga një ekskluzivitet i vetëm.
Shërbimi i Marrjes së Urdhërave pranoi dhe llogariti përbërjen e porosisë.
Dhe SmsService dërgoi SMS duke telefonuar shërbimet API për të dërguar SMS.

Shërbimet e përpunuara të të dhënave nga baza e të dhënave, logjika e ruajtur e biznesit. Çdo shërbim kishte një ose më shumë *depo me emrin e duhur. Ata tashmë përmbanin pyetje për procedurat e ruajtura në bazën e të dhënave dhe një shtresë hartuesish. Kishte logjikë biznesi në depo, veçanërisht në ato që lëshonin të dhëna raportuese. ORM nuk u përdor, të gjithë mbështeteshin në sql të shkruar me dorë.

Kishte gjithashtu një shtresë të modelit të domenit dhe klasa të zakonshme ndihmëse, për shembull, klasa Order që ruante porosinë. Në të njëjtin vend, në shtresë, kishte një ndihmës për konvertimin e tekstit të ekranit sipas monedhës së zgjedhur.

E gjithë kjo mund të përfaqësohet nga një model i tillë:

Mënyra e porositjes

Konsideroni një mënyrë fillestare të thjeshtuar për të krijuar një urdhër të tillë.

Fillimisht, faqja ishte statike. Kishte çmime mbi të, dhe në krye - një numër telefoni dhe mbishkrimin "Nëse doni pica - telefononi numrin dhe porositni". Për të porositur, duhet të zbatojmë një rrjedhë të thjeshtë:

Klienti viziton një faqe statike me çmime, zgjedh produktet dhe telefonon numrin e listuar në faqe.
Klienti emërton produktet që duan të shtojnë në porosi.
Jep 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 regjistruar pranon vetëm një porosi në të njëjtën kohë. Prandaj, karroca e draftit mund të ruhet në sesionin e tij (sesioni i përdoruesit ruhet në memorie). Ekziston një objekt i Shportës që përmban produkte dhe informacione për klientët.

Klienti emërton produktin, operatori klikon mbi të + pranë produktit dhe një kërkesë i dërgohet serverit. Informacioni rreth produktit nxirret nga baza e të dhënave dhe informacioni rreth produktit shtohet në karrocë.

Shënim. Po, këtu nuk mund ta tërhiqni produktin nga baza e të dhënave, por ta transferoni atë nga pjesa e përparme. Por për qartësi, unë tregova saktësisht rrugën nga baza e të dhënave.

Tjetra, shkruani adresën dhe emrin e klientit.

Kur klikoni "Krijo porosi":

Kërkesa dërgohet te OrderController.SaveOrder().
Ne marrim Karrocën nga seanca, ka produkte në sasinë që na duhen.
Ne e plotësojmë Kartën me informacione për klientin dhe ia kalojmë metodës AddOrder të klasës ReceivingOrderService, ku ruhet në bazën e të dhënave.
Baza e të dhënave ka tabela me rendin, përbërjen e porosisë, klientin dhe të gjitha janë të lidhura.
Ndërfaqja e shfaqjes së porosive shkon dhe nxjerr porositë më të fundit dhe i shfaq ato.

Module të reja

Marrja e porosisë ishte e rëndësishme dhe e nevojshme. Ju nuk mund të bëni një biznes pica nëse nuk keni një porosi për të shitur. Prandaj, sistemi filloi të fitojë funksionalitet - afërsisht nga 2012 deri në 2015. Gjatë kësaj kohe, u shfaqën shumë blloqe të ndryshme të sistemit, të cilat unë do t'i quaj modulet, në krahasim me konceptin e shërbimit ose produktit.

Një modul është një grup funksionesh që janë të bashkuara nga një qëllim i përbashkët i biznesit. Në të njëjtën kohë, ata janë fizikisht në të njëjtin aplikacion.

Modulet mund të quhen blloqe të sistemit. Për shembull, ky është një modul raportimi, ndërfaqe administratori, gjurmues i ushqimit në kuzhinë, autorizim. Këto janë të gjitha ndërfaqe të ndryshme të përdoruesit, disa madje kanë stile të ndryshme vizuale. Në të njëjtën kohë, gjithçka është në kuadrin e një aplikacioni, një procesi që funksionon.

Teknikisht, modulet u projektuan si Zonë (një ide e tillë madje mbeti në bërthama asp.net). Kishte skedarë të veçantë për frontin, modelet, si dhe klasat e tyre të kontrolluesve. Si rezultat, sistemi u transformua nga kjo ...

...në këtë:

Disa module zbatohen nga sajte të veçanta (projekt i ekzekutueshëm), për shkak të një funksionaliteti krejtësisht të veçantë dhe pjesërisht për shkak të një zhvillimi pak më të veçantë, më të fokusuar. Kjo:

Faqe - versioni i parë faqja dodopizza.ru.
Eksport: ngarkimi i raporteve nga Dodo IS për 1C.
Personal - llogaria personale e punonjësit. Është zhvilluar veçmas dhe ka pikën e vet të hyrjes dhe dizajnin e veçantë.
fs — një projekt për pritjen e statikës. Më vonë u larguam prej tij, duke lëvizur të gjitha statikët në Akamai CDN.

Pjesa tjetër e blloqeve ishin në aplikacionin BackOffice.

Shpjegimi i emrit:

Arkëtar - Arkëtar restoranti.
ShiftManager - ndërfaqet për rolin "Shift Manager": statistika operacionale për shitjet e picerisë, aftësia për të vendosur produktet në listën e ndalimit, ndryshimi i renditjes.
OfficeManager - ndërfaqe për rolet "Menaxheri i Picerisë" dhe "Franchisee". Këtu janë mbledhur funksionet për ngritjen e një picerie, promovimet e saj bonus, marrjen dhe punën me punonjësit, raportet.
Ekranet publike - ndërfaqe për TV dhe tableta të varura në piceri. Televizorët shfaqin menutë, informacionin e reklamave, statusin e porosisë pas dorëzimit.

Ata përdorën një shtresë të përbashkët shërbimi, një bllok të zakonshëm të klasës së domenit Dodo.Core dhe një bazë të përbashkët. Ndonjëherë ata ende mund të udhëheqin përgjatë tranzicionit me njëri-tjetrin. Përfshirë faqet individuale, të tilla si dodopizza.ru ose personal.dodopizza.ru, shkuan në shërbime të përgjithshme.

Kur u shfaqën module të reja, ne u përpoqëm të ripërdornim në maksimum kodin e krijuar tashmë të shërbimeve, procedurat dhe tabelat e ruajtura në bazën e të dhënave.

Për një kuptim më të mirë të shkallës së moduleve të bëra në sistem, këtu është një diagram i vitit 2012 me planet e zhvillimit:

Deri në vitin 2015, gjithçka ishte në hartë dhe akoma më shumë ishte në prodhim.

Pranimi i porosisë është rritur në një bllok të veçantë të Qendrës së Kontaktit, ku porosia pranohet nga operatori.
Kishte ekrane publike me menu dhe informacione të varura në piceri.
Kuzhina ka një modul që luan automatikisht mesazhin zanor "New Pizza" kur vjen një porosi e re, dhe gjithashtu printon një faturë për korrierin. Kjo thjeshton shumë proceset në kuzhinë, lejon punonjësit të mos shpërqendrohen nga një numër i madh operacionesh të thjeshta.
Njësia e dorëzimit u bë një arkë e veçantë e dërgesës, ku porosia i lëshohej korrierit që kishte marrë më parë turnin. Koha e tij e punës është marrë parasysh për llogaritjen e listës së pagave.

Paralelisht, nga viti 2012 deri në 2015, u shfaqën më shumë se 10 zhvillues, u hapën 35 piceri, e vendosën sistemin në Rumani dhe u përgatitën për hapjen e pikave në Shtetet e Bashkuara. Zhvilluesit nuk merreshin më me të gjitha detyrat, por u ndanë në ekipe. secili i specializuar në pjesën e vet të sistemit.

Problemet

Përfshirë për shkak të arkitekturës (por jo vetëm).

Kaos në bazë

Një bazë është e përshtatshme. Konsistenca mund të arrihet në të, dhe në kurriz të mjeteve të ndërtuara në bazat e të dhënave relacionale. Puna me të është e njohur dhe e përshtatshme, veçanërisht nëse ka pak tabela dhe pak të dhëna.

Por gjatë 4 viteve zhvillim, baza e të dhënave rezultoi të kishte rreth 600 tabela, 1500 procedura të ruajtura, shumë prej të cilave kishin edhe logjikë. Mjerisht, procedurat e ruajtura nuk sjellin shumë përparësi kur punoni me MySQL. Ato nuk ruhen nga baza, dhe ruajtja e logjikës në to e ndërlikon zhvillimin dhe korrigjimin e gabimeve. Ripërdorimi i kodit është gjithashtu i vështirë.

Shumë tabela nuk kishin indekse të përshtatshme, diku, përkundrazi, kishte shumë indekse, të cilat e vështirësonin futjen. Ishte e nevojshme të modifikoheshin rreth 20 tabela - transaksioni për të krijuar një porosi mund të zgjaste rreth 3-5 sekonda.

Të dhënat në tabela nuk ishin gjithmonë në formën më të përshtatshme. Diku u desh të bëhej denormalizimi. Një pjesë e të dhënave të marra rregullisht ishte në një kolonë në formën e një strukture XML, kjo rriti kohën e ekzekutimit, zgjati pyetjet dhe ndërlikoi zhvillimin.

Në të njëjtat tavolina janë prodhuar shumë kërkesa heterogjene. Tabelat e njohura pësuan veçanërisht, si tabela e përmendur më lart. urdhëron ose tavolina piceri. Ato u përdorën për të shfaqur ndërfaqet operacionale në kuzhinë, analitikë. Një faqe tjetër i kontaktoi ata (dodopizza.ru), ku në çdo moment mund të vinin papritmas shumë kërkesa.

Të dhënat nuk u grumbulluan dhe shumë llogaritje u bënë në fluturim duke përdorur bazën. Kjo krijoi llogaritje të panevojshme dhe ngarkesë shtesë.

Shpesh kodi shkonte në bazën e të dhënave kur nuk mund ta bënte këtë. Diku nuk kishte operacione të mjaftueshme me shumicë, diku do të ishte e nevojshme të shpërndahej një kërkesë në disa përmes kodit në mënyrë që të përshpejtohet dhe të rritet besueshmëria.

Kohezioni dhe turbullimi në kod

Modulet që supozohej të ishin përgjegjës për pjesën e tyre të biznesit nuk e bënë atë me ndershmëri. Disa prej tyre kishin dyfishim funksionesh për role. Për shembull, një tregtar lokal që është përgjegjës për aktivitetin e marketingut të rrjetit në qytetin e tij duhej të përdorte si ndërfaqen "Admin" (për të krijuar promovime) dhe ndërfaqen "Office Manager" (për të parë ndikimin e promocioneve në biznes). Sigurisht, brenda të dy moduleve përdorej i njëjti shërbim që funksiononte me promovime bonus.

Shërbimet (klasat brenda një projekti të madh monolit) mund të thërrasin njëri-tjetrin për të pasuruar të dhënat e tyre.

Me vetë klasat e modelit që ruajnë të dhëna, Puna në kod u krye ndryshe. Diku kishte konstruktorë përmes të cilëve ishte e mundur të specifikoheshin fushat e kërkuara. Diku kjo është bërë përmes pronave publike. Natyrisht, marrja dhe transformimi i të dhënave nga baza e të dhënave ishte i ndryshëm.

Logjika ishte ose te kontrollorët ose te klasat e shërbimit.

Këto duken të jenë çështje të vogla, por ato ngadalësuan shumë zhvillimin dhe ulën cilësinë, duke çuar në paqëndrueshmëri dhe defekte.

Kompleksiteti i një zhvillimi të madh

Vështirësitë u shfaqën në vetë zhvillimin. Ishte e nevojshme të bëheshin blloqe të ndryshme të sistemit, dhe paralelisht. Përshtatja e nevojave të secilit komponent në një kod të vetëm u bë gjithnjë e më e vështirë. Nuk ishte e lehtë për të rënë dakord dhe për të kënaqur të gjithë komponentët në të njëjtën kohë. Kësaj i shtuan kufizimet në teknologji, veçanërisht në lidhje me bazën dhe frontin. Ishte e nevojshme të braktisej jQuery drejt kornizave të nivelit të lartë, veçanërisht për sa i përket shërbimeve të klientit (faqes së internetit).

Në disa pjesë të sistemit, bazat e të dhënave më të përshtatshme për këtë mund të përdoren.. Për shembull, më vonë patëm rastin e përdorimit të lëvizjes nga Redis në CosmosDB për të ruajtur një shportë porosie.

Ekipet dhe zhvilluesit e përfshirë në fushën e tyre kërkonin qartësisht më shumë autonomi për shërbimet e tyre, si në aspektin e zhvillimit ashtu edhe në shpërndarjen. Bashkoni konfliktet, lironi problemet. Nëse për 5 zhvillues ky problem është i parëndësishëm, atëherë me 10, dhe aq më tepër me rritjen e planifikuar, gjithçka do të bëhej më serioze. Dhe përpara do të ishte zhvillimi i një aplikacioni celular (ai filloi në 2017, dhe në 2018 ishte rënie e madhe).

Pjesë të ndryshme të sistemit kërkonin nivele të ndryshme stabiliteti, por për shkak të lidhjes së fortë të sistemit, ne nuk mundëm ta siguronim këtë. Një gabim në zhvillimin e një funksioni të ri në panelin e administratorit mund të ketë ndodhur në pranimin e një porosie në sit, sepse kodi është i zakonshëm dhe i ripërdorshëm, baza e të dhënave dhe të dhënat janë gjithashtu të njëjta.

Ndoshta do të ishte e mundur të shmangeshin këto gabime dhe probleme në kuadrin e një arkitekture të tillë monolite-modulare: bëni një ndarje përgjegjësie, rifaktoroni kodin dhe bazën e të dhënave, ndani qartë shtresat nga njëra-tjetra, monitoroni cilësinë çdo ditë. Por zgjidhjet arkitekturore të zgjedhura dhe fokusi në zgjerimin e shpejtë të funksionalitetit të sistemit çuan në probleme në aspektin e qëndrueshmërisë.

Si i vendosi blog-u Power of the Mind arkat në restorante

Nëse rritja e rrjetit të picerisë (dhe e ngarkesës) do të vazhdonte me të njëjtin ritëm, atëherë pas një kohe rëniet do të ishin të tilla që sistemi nuk do të ngrihej. Ilustron mirë problemet me të cilat filluam të përballemi në vitin 2015, këtu është një histori e tillë.

Në blog "Fuqia e mendjes” ishte një widget që tregonte të dhëna për të ardhurat për vitin e të gjithë rrjetit. Miniaplikacioni iu qaset API-së publike Dodo, e cila ofron këto të dhëna. Kjo statistikë është aktualisht në dispozicion në http://dodopizzastory.com/. Widget shfaqej në çdo faqe dhe bënte kërkesa në një kohëmatës çdo 20 sekonda. Kërkesa shkoi në api.dodopizza.ru dhe kërkoi:

numri i picerive në rrjet;
të ardhurat totale të rrjetit që nga fillimi i vitit;
të ardhurat për sot.

Kërkesa për statistika mbi të ardhurat shkoi direkt në bazën e të dhënave dhe filloi të kërkonte të dhëna për porositë, duke grumbulluar të dhëna në fluturim dhe duke dhënë shumën.

Tavolinat e parave në restorante shkuan në të njëjtën tabelë porosish, shkarkonin një listë të porosive të marra për sot dhe iu shtuan porosi të reja. Kaskat i bënin kërkesat e tyre çdo 5 sekonda ose në rifreskimin e faqes.

Diagrami dukej kështu:

Një vjeshtë, Fyodor Ovchinnikov shkroi një artikull të gjatë dhe popullor në blogun e tij. Shumë njerëz erdhën në blog dhe filluan të lexojnë gjithçka me kujdes. Ndërsa secili nga njerëzit që erdhën po lexonte artikullin, miniaplikacioni i të ardhurave funksiononte siç duhet dhe kërkonte API-në çdo 20 sekonda.

API thirri një procedurë të ruajtur për të llogaritur shumën e të gjitha porosive që nga fillimi i vitit për të gjitha piceritë në rrjet. Përmbledhja u bazua në tabelën e porosive, e cila është shumë e njohur. Të gjitha arkat e të gjitha restoranteve të hapura në atë kohë shkojnë në të. Tavolinat e parave nuk reaguan më, porositë nuk pranoheshin. Ata gjithashtu nuk u pranuan nga faqja, nuk u shfaqën në gjurmues, menaxheri i ndërrimit nuk mund t'i shihte 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ë kemi fikur API-në publike, dhe një herë, madje na është dashur të fikim faqen, sepse asgjë nuk ndihmoi. Kishte madje një listë shërbimesh me një urdhër mbylljeje nën ngarkesa të rënda.

Tani e tutje fillon lufta jonë me ngarkesat dhe për stabilizimin e sistemit (nga vjeshta 2015 deri në vjeshtë 2018). Atehere ndodhi"rënie e madhe". Më tej, ndonjëherë ndodhnin edhe dështime, 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ë? Thjesht shikoni grafikët e mëposhtëm.

Gjithashtu në 2014-2015 ka pasur një hapje në Rumani dhe një hapje në SHBA është duke u përgatitur.

Rrjeti u rrit shumë shpejt, u hapën vende të reja, u shfaqën formate të reja piceri, për shembull, u hap një piceri në gjykatën e ushqimit. E gjithë kjo kërkonte vëmendje të konsiderueshme veçanërisht për zgjerimin e funksioneve të Dodo IS. Pa të gjitha këto funksione, pa gjurmimin në kuzhinë, llogaritjen e produkteve dhe humbjeve në sistem, shfaqjen e lëshimit të një urdhri në sallën e gjykatës së ushqimit, vështirë se do të flisnim për arkitekturën "korrekte" dhe qasjen "korrekte" ndaj zhvillim tani.

Një tjetër pengesë për rishikimin në kohë të arkitekturës dhe në përgjithësi vëmendjen ndaj problemeve teknike ishte kriza e vitit 2014. Gjëra të tilla godasin fort mundësitë për skuadrat për t'u rritur, veçanërisht për një biznes të ri si Dodo Pizza.

Zgjidhje të shpejta që ndihmuan

Problemet kërkonin zgjidhje. Në mënyrë konvencionale, zgjidhjet mund të ndahen në 2 grupe:

Të shpejtë që shuajnë zjarrin dhe japin një diferencë të vogël sigurie dhe na blejnë kohë për të ndryshuar.
Sistemik dhe, për rrjedhojë, i gjatë. Riinxhinierimi i një numri modulesh, ndarja e një arkitekture monolitike në shërbime të veçanta (shumica e tyre nuk janë aspak mikro, por më tepër shërbime makro, dhe ka diçka në lidhje me të Raporti i Andrey Morevskiy).

Lista e thatë e ndryshimeve të shpejta është si më poshtë:

Zmadhoni masterin e bazës

Sigurisht, gjëja e parë që bëhet për të përballuar ngarkesat është rritja e kapacitetit të serverit. Kjo është bërë për bazën e të dhënave master dhe për serverët në internet. Mjerisht, kjo është e mundur vetëm deri në një kufi të caktuar, atëherë bëhet shumë e shtrenjtë.

Që nga viti 2014, ne jemi transferuar në Azure, ne gjithashtu kemi shkruar për këtë temë në atë kohë në artikullin "Si Dodo Pizza ofron pica duke përdorur Microsoft Azure Cloud". Por pas një sërë rritjesh në server për bazën, ata dolën kundër kostos.

Replikat e bazës për lexim

Dy kopje u bënë për bazën:

Lexoni Replikën për kërkesat për referencë. Përdoret për të lexuar direktoritë, llojin, qytetin, rrugën, picën, produktet (domeni i ndryshuar ngadalë) dhe në ato ndërfaqe ku një vonesë e vogël është e pranueshme. Ishin 2 nga këto kopje, ne siguruam disponueshmërinë e tyre në të njëjtën mënyrë si masterat.

ReadReplica për kërkesat e raportit. Kjo bazë të dhënash kishte disponueshmëri më të ulët, por të gjitha raportet shkuan tek ajo. Le të kenë kërkesa të rënda për rillogaritje të mëdha të të dhënave, por ato nuk ndikojnë në bazën e të dhënave kryesore dhe ndërfaqet operacionale.

Memoria e fshehtë në kod

Nuk kishte asnjë memorie askund në kod (fare). Kjo çoi në kërkesa shtesë, jo gjithmonë të nevojshme, në bazën e të dhënave të ngarkuar. Memoriet e fshehta fillimisht ishin si në memorie ashtu edhe në një shërbim të jashtëm të memories, që ishte Redis. Gjithçka u zhvlerësua me kalimin e kohës, cilësimet u specifikuan në kod.

Serverë të shumtë backend

Backend-i i aplikacionit gjithashtu duhej të shkallëzohej për të përballuar ngarkesat e shtuara të punës. Ishte e nevojshme të bëhej një grup nga një server iis. Ne kemi riprogramuar sesioni i aplikimit nga memoria në RedisCache, i cili bëri të mundur krijimin e disa serverëve pas një balancuesi të thjeshtë të ngarkesës me rrumbullakët. Në fillim, i njëjti Redis u përdor si për cache, më pas u nda në disa.

Si rezultat, arkitektura është bërë më e ndërlikuar ...

… por një pjesë e tensionit u hoq.

Dhe më pas ishte e nevojshme të ribëheshin komponentët e ngarkuar, të cilët morëm përsipër. Për këtë do të flasim në pjesën tjetër.

Burimi: www.habr.com

Historia e Arkitekturës Dodo IS: Një monolit i hershëm