An jî her şirketek bêbext bi monolîtek bi awayê xwe nerazî ye.
Pêşveçûna pergala Dodo IS yekser dest pê kir, mîna karsaziya Dodo Pizza, di 2011 de. Ew li ser bingeha ramana dîjîtalkirina bêkêmasî û tevahî ya pêvajoyên karsaziyê, û , ku wê demê jî di sala 2011 de bû sedema gelek pirs û gumanan. Lê ev 9 sal in em vê rêyê dişopînin - bi pêşkeftina xwe ya ku bi yekdestî dest pê kir.
Ev gotar "bersiva" e ji bo pirsên "Çima mîmarî ji nû ve binivîsin û guhertinên weha mezin û demdirêj bikin?" vegerin gotara berê . Ez ê dest pê bikim ka pêşkeftina Dodo IS çawa dest pê kir, mîmariya orîjînal çawa xuya bû, modulên nû çawa xuya bûn, û ji ber çi pirsgirêkan pêdivî bû ku guhertinên mezin werin çêkirin.
Rêze gotarên "Dodo IS çi ye?" li ser dibêje:
-
Yekdestiya destpêkê li Dodo IS (2011-2015). (tu li vir î)
-
.
-
Rêya milê xerîdar: rûya li ser bingehê (2016-2017). (Ez teslîm nabim...)
-
Dîroka mîkroxizmetên rastîn. (2018-2019). (Ez teslîm nabim...)
-
Dîtina yekdest û stabîlkirina mîmariyê qediya. (Ez teslîm nabim...)
Mîmariya destpêkê
Di 2011 de, mîmariya Dodo IS bi vî rengî xuya bû:
Yekem modula di mîmariyê de pejirandina fermanê ye. Pêvajoya karsaziyê ev bû:
-
xerîdar gazî pizzeryayê dike;
-
gerînendeyê telefonê hildide;
-
fermanek bi têlefonê qebûl dike;
-
di navgîniya pejirandina fermanê de paralelî dagirtî dike: agahdariya li ser xerîdar, daneyên li ser hûrguliyên fermanê, navnîşana radestkirinê têne hesibandin.
Navbera pergala agahdariyê tiştek bi vî rengî xuya bû ...
Guhertoya yekem ji Cotmeha 2011:
Çavkaniyên ji bo pêşkeftina modula hilgirtina fermana yekem tixûbdar bûn. Diviyabû em gelek tişt, bi lez û bi tîmeke biçûk bikin. Tîmek piçûk 2 pêşdebiran e ku bingeha tevahiya pergala pêşerojê danî.
Biryara wan a yekem çarenûsa stûna teknolojiyê diyar kir:
-
Piştgiriya li ser ASP.NET MVC, zimanê C#. Pêşdebir dotnetchiki bûn, ev stack ji wan re nas û xweş bû.
-
Frontend li ser Bootstrap û JQuery: navgînên bikarhêner li ser şêwaz û nivîsarên xwe-nivîsandî.
-
Databasa MySQL: lêçûnên destûrnameyê tune, karanîna hêsan e.
-
Pêşkêşkerên li ser Windows Server, ji ber ku .NET wê hingê tenê di bin Windows-ê de bû (Em ê Mono nîqaş nekin).
Ji hêla fizîkî ve, ev hemî di "dedîka li mêvandar" de hate diyar kirin.
Order Intake Application Architecture
Dûv re her kes jixwe qala mîkroservisan dikir, û SOA 5 salan di projeyên mezin de hate bikar anîn, mînakî, WCF di 2006-an de hate berdan. Lê paşê wan çareseriyek pêbawer û îsbatkirî hilbijart.
Va ye.
Asp.Net MVC Razor e, ku, li ser daxwazek ji formek an ji xerîdarek, rûpelek HTML-ê bi pêşkêşkirina serverê re çêdike. Li ser xerîdar, nivîsarên CSS û JS jixwe agahdarî nîşan didin û, ger hewce be, daxwazên AJAX bi navgîniya JQuery re pêk bînin.
Daxwazên li ser pêşkêşkarê di dersên * Kontrolker de bi dawî dibin, ku li wir pêvajoyê û hilberîna rûpela HTML ya dawîn di rêbazê de pêk tê. Kontrolker daxwazan ji qatek mantiqê ya bi navê *Xizmet dikin. Her yek ji karûbar bi hin aliyên karsaziyê re têkildar bû:
-
Mînakî, Dezgeha StructureService li ser pizeryayan, li ser dezgehan agahdarî da. Dezgeh komek pizeryayan e ku ji hêla yek franchisee ve têne rêve kirin.
-
ReceivingOrdersService berhevoka fermanê qebûl kir û hesab kir.
-
Û SmsService bi gazîkirina karûbarên API-ê ji bo şandina SMS-ê şandin.
Karûbar daneyên ji databasê hildiweşîne, mentiqê karsaziyê hilanîn. Her karûbar yek an jî çend * Depoyên bi navê guncan hebûn. Wan berê pirs ji prosedurên hilanîn ên di databasê de û qatek nexşevanan dihewand. Di depoyan de mantiqa karsaziyê hebû, nemaze di wan ên ku daneya raporê diweşandin. ORM nehat bikar anîn, her kes xwe dispêre sql-ya destan.
Di heman demê de qatek modela domainê û çînên alîkar ên hevpar jî hebû, mînakî, çîna Order ku ferman hilanî. Li heman cihî, di qatê de, ji bo veguheztina nivîsa pêşandanê li gorî pereyê hilbijartî alîkarek hebû.
Hemî ev dikare bi modelek weha were temsîl kirin:
Order Way
Ji bo afirandina fermanek wusa rêyek destpêkê ya hêsan bihesibînin.
Di destpêkê de, malper statîk bû. Bihayên wê hebûn, û li ser - jimareyek têlefonê û nivîsa "Heke hûn pizza dixwazin - bi jimareyê re telefon bikin û ferman bidin." Ji bo fermanê, divê em pêvekek hêsan bicîh bînin:
-
Xerîdar bi bihayên malperek statîk ziyaret dike, hilberan hildibijêre û jimara ku li ser malperê hatî navnîş kirin bang dike.
-
Xerîdar navên hilberên ku ew dixwazin li fermanê zêde bikin nav dike.
-
Navnîşan û navê xwe dide.
-
Operator fermanê qebûl dike.
-
Ferman di navgîniya fermanên pejirandî de tê xuyang kirin.
Hemî bi nîşandana menuyê dest pê dike. Bikarhêner-operatorek têketî tenê yek fermanê di demekê de qebûl dike. Ji ber vê yekê, selika pêşnûmeyê dikare di rûniştina wî de were hilanîn (danişîna bikarhêner di bîranînê de tê hilanîn). Tiştek selikê heye ku hilber û agahdariya xerîdar vedihewîne.
Xerîdar navê hilberê dike, operator li ser bitikîne + li kêleka hilberê, û daxwazek ji serverê re tê şandin. Agahiyên li ser hilberê ji databasê têne derxistin û agahdariya hilberê li selikê zêde dibe.
bingotin. Erê, li vir hûn nekarin hilberê ji databasê derxînin, lê ji pêşê veguhezînin. Lê ji bo zelaliyê, min rêça ji databasê tam nîşan da.
Piştre, navnîşan û navê xerîdar binivîse.
Dema ku hûn bikirtînin "Ferman biafirînin":
-
Daxwaz ji OrderController.SaveOrder() re tê şandin.
-
Em Selikê ji danişînê distînin, di hêjahiya ku em hewce ne de hilber hene.
-
Em selikê bi agahdariya di derheqê xerîdar de temam dikin û wê digihînin rêbaza AddOrder ya çîna ReceivingOrderService, ku ew li databasê tê hilanîn.
-
Di databasê de tabloyên bi rêzê, pêkhatina fermanê, xerîdar heye, û ew hemî bi hev ve girêdayî ne.
-
Navbera nîşana fermanê diçe û fermanên herî dawî derdixe û wan nîşan dide.
Modulên nû
Girtina fermanê girîng û pêwîst bû. Ger fermanek we tune ku hûn bifroşin hûn nikarin karsaziyek pizza bikin. Ji ber vê yekê, pergalê dest bi wergirtina fonksiyonê kir - hema hema ji 2012 heta 2015. Di vê demê de, gelek blokên pergalê yên cihêreng xuya bûn, ku ez ê bang bikim modules, Berevajî têgeha karûbar an hilberê.
Modulek komek fonksiyonan e ku ji hêla hin armanca karsaziya hevpar ve têne yek kirin. Di heman demê de, ew bi fîzîkî di heman serîlêdanê de ne.
Modul dikarin blokên pergalê têne gotin. Mînakî, ev modulek raporê ye, navgînên rêveberiyê, , destûr. Vana hemî navgînên bikarhêner ên cihêreng in, hin jî xwedan şêwazên dîtbarî yên cihê ne. Di heman demê de, her tişt di çarçoveya yek serîlêdanê de, yek pêvajoya xebitandinê de ye.
Ji hêla teknîkî ve, modul wekî Area hatine sêwirandin (ramanek wusa jî tê de ma ). Ji bo pêşê, modelan, û hem jî dersên wan ên kontrolker pelên cûda hebûn. Di encamê de, sîstem ji vê ...
... di vê yekê de:
Hin modul ji hêla malperên veqetandî ve têne bicîh kirin (projeya bikêrhatî), ji ber fonksiyonek bi tevahî cihêreng û hinekî jî ji ber pêşveçûnek piçûktir, bêtir baldar. Ev:
-
Site - malpera dodopizza.ru.
-
Eksport: barkirina raporên ji Dodo IS ji bo 1C.
-
şexsî - hesabê kesane yê karmend. Ew ji hev veqetandî hate pêşve xistin û xwedan xala têketinê û sêwirana cûda ye.
-
fs - projeyek ji bo mêvandariya statîkan. Dûv re em ji wê dûr ketin, hemî statîkan bar kirin Akamai CDN.
Blokên mayî di serîlêdana BackOffice de bûn.
Ravekirina navê:
-
Diravgir - Diravê Restaurant.
-
ShiftManager - navgînên ji bo rola "Rêveberê Shift": statîstîkên xebitandinê yên li ser firotana pizzeria, şiyana danîna hilberan di navnîşa rawestandinê de, guheztina fermanê.
-
OfficeManager - ji bo rola "Rêveberê Pizzeriya" û "Franchisee" navbeynkariyê dike. Li vir fonksiyonên ji bo sazkirina pizzeriya, promosyonên wê yên bonus, wergirtin û xebata bi karmendan re, rapor têne berhev kirin.
-
PublicScreens - navgînên ji bo TV û tabletên ku li pîzzeryayan daleqandî ne. TV menuyan, agahdariya reklamê, rewşa fermanê piştî radestkirinê nîşan didin.
Wan qatek karûbarê hevpar, bloka pola domainê ya hevpar Dodo.Core, û bingehek hevpar bikar anîn. Carinan ew hîn jî dikaribûn rê li ber veguheztinan ber bi hev ve bibirin. Di nav de malperên kesane, wek dodopizza.ru an personal.dodopizza.ru, çûn ser karûbarên gelemperî.
Dema ku modulên nû xuya bûn, me hewl da ku em koda karûbarên ku berê hatine afirandin, prosedurên hilanîn û tabloyên di databasê de herî zêde ji nû ve bikar bînin.
Ji bo têgihiştinek çêtir a pîvana modulên ku di pergalê de hatine çêkirin, li vir diyagramek ji sala 2012-an bi plansaziyên pêşkeftinê heye:
Di sala 2015-an de, her tişt li ser nexşeyê bû û hêj bêtir di hilberînê de bû.
-
Pejirandina fermanê bûye blokek cihêreng a Navenda Têkiliyê, ku ferman ji hêla operator ve tê pejirandin.
-
Li pîzzeryayan ekranên giştî yên bi menu û agahdarî hatin daliqandin.
-
Di metbexê de modulek heye ku dema ku fermanek nû tê peyama dengî "New Pizza" bixweber dilîze, û di heman demê de fatûreyek ji bo kuryeyê jî çap dike. Ev pêvajoyên di metbexê de pir hêsan dike, dihêle ku karmend ji hêla hejmareke mezin a operasyonên hêsan ve neyên kişandin.
-
Yekîneya radestkirinê bû Kêleka Radestkirinê ya cihê, ku li wir ferman ji derhênerê ku berê veguheztibû hate dayîn. Dema xebata wî ji bo hesabkirina mûçeyê hate hesibandin.
Di heman demê de, ji 2012-an heya 2015-an, zêdetirî 10 pêşdebiran xuya bûn, 35 pizzeriy vekirin, pergalê li Romanya bicîh kirin û ji bo vekirina firotgehan li Dewletên Yekbûyî amade kirin. Pêşdebir êdî bi hemî peywiran re mijûl nebûn, lê di tîman de hatin dabeş kirin. her yek di beşa xwe ya pergalê de pispor e.
Pirsgirêkên
Di nav de ji ber mîmariyê (lê ne tenê).
Kaos di bingehê de
Yek bingeh rehet e. Lihevhatî dikare di wê de, û li ser hesabê amûrên ku di databasên pêwendiyê de hatine çêkirin, were bidestxistin. Karkirina pê re nas û rehet e, nemaze heke hindik tablo û daneyên piçûk hebin.
Lê di nav 4 salên pêşkeftinê de, databas derket ku nêzî 600 tablo, 1500 prosedurên hilanîn hene, ku gelek ji wan jî mantiq bûn. Mixabin, prosedurên hilanîn dema ku bi MySQL re dixebitin pir feydeyê nadin. Ew ji hêla bingehê ve nayên girtin, û hilanîna mantiqê di wan de pêşkeftin û xeletkirinê tevlihev dike. Ji nû ve karanîna kodê jî dijwar e.
Di gelek tabloyan de îndeksên minasib tunebûn, li deverek, berevajî vê yekê, gelek îndeks hebûn, ku têxistina wê dijwar bû. Pêdivî bû ku nêzîkê 20 tabloyan biguhezînin - danûstendina çêkirina fermanê dikare bi qasî 3-5 çirkeyan bigire.
Daneyên di tabloyan de her gav ne di forma herî guncaw de bûn. Li cihekî pêwîst bû ku denormalîzasyon were kirin. Beşek daneyên ku bi rêkûpêk hatine wergirtin di stûnek di forma avahiyek XML de bû, vê yekê dema darvekirinê zêde kir, pirsan dirêj kir û pêşkeftinê tevlihev kir.
Li ser heman tabloyan pir hatin hilberandin daxwazên heterojen. Tabloyên populer bi taybetî êş kişandin, mîna tabloya ku li jor hatî destnîşan kirin. emir an maseyên pizzeria. Ew hatin bikar anîn da ku navberên xebitandinê yên di metbexê, analîtîk de nîşan bidin. Malperek din bi wan re têkilî (), ku di her demek diyarkirî de dibe ku ji nişkê ve gelek daxwaz werin.
Daneyên hev nehatin kirin û gelek hesab li ser firînê bi karanîna bingehê pêk hatin. Vê yekê hesabên nehewce û barek zêde çêkir.
Pir caran kod diçû databasê dema ku nedikarî wiya bike. Li deverek têr operasyonên girseyî nebûn, li cîhek hewce bû ku yek daxwazek bi navgîniya kodê li çend kesan belav bikin da ku pêbawerî bilezînin û zêde bikin.
Di kodê de hevgirtin û tevlihevî
Modulên ku diviyabû ku ji beşa xwe ya karsaziyê berpirsiyar bin, ew bi dilsozî nekir. Hin ji wan fonksiyonên ji bo rolan dubare kirin. Mînakî, kirrûbirek herêmî ku berpirsiyarê çalakiya kirrûbirra torê ye li bajarê xwe neçar ma ku hem navbeynkariya "Rêveber" (ji bo afirandina promosyonên) hem jî navbeynkariya "Rêveberê Ofîsê" (ji bo dîtina bandora promosyonên li ser karsaziyê) bikar bîne. Bê guman, di hundurê her du modulan de heman karûbarê ku bi promosyonên bonus re dixebitî bikar anîn.
Karûbar (dersên di nav projeyek mezin a yekparêz de) dikarin hevûdu bang bikin da ku daneyên xwe dewlemend bikin.
Digel çînên modelê yên ku daneyan hilîne, xebatên di kodê de bi awayekî cuda dihat kirin. Li deverek çêker hebûn ku bi navgîniya wan gengaz bû ku qadên pêwîst diyar bikin. Li cihekî ev yek bi rêya milkên giştî pêk hat. Bê guman, wergirtin û veguherîna daneyan ji databasê cihêreng bû.
Mantiq an di kontrolkeran de an jî di dersên xizmetê de bû.
Dixuye ku ev pirsgirêkên piçûk in, lê wan pêşveçûnek pir hêdî kir û kalîteyê kêm kir, ku rê li ber bêîstîqrar û xeletiyan vedike.
Tevliheviya pêşveçûnek mezin
Di pêşketinê de bi xwe jî zehmetî derketin. Pêwîst bû ku blokên cûda yên pergalê û bi hev re bêne çêkirin. Bicihkirina hewcedariyên her pêkhateyê di kodek yekane de her ku diçe dijwartir dibû. Ne hêsan bû ku di heman demê de hemî pêkhateyan bipejirînin û xweş bikin. Li ser vê yekê di teknolojiyê de, nemaze di warê bingeh û pêşiyê de, sînorkirin hebûn. Pêwîst bû ku jQuery berbi çarçoveyên astek bilind ve were berdan, nemaze di warê karûbarên xerîdar (malper).
Di hin beşên pergalê de, databasên ji bo vê yekê guncantir dikarin werin bikar anîn.. Mînakî, paşê me doza karanîna me kir ku em ji Redis berbi CosmosDB-ê ve biçin da ku selikek fermanê hilînin.
Tîm û pêşdebirên ku di qada xwe de beşdar bûne eşkere ji bo karûbarên xwe, hem di warê pêşkeftinê û hem jî di warê pêşkeftinê de, bêtir xweserî dixwestin. Pevçûn tevlihev bikin, pirsgirêkan azad bikin. Ger ji bo 5 pêşdebiran ev pirsgirêk ne girîng be, wê hingê bi 10, û hêj bêtir bi mezinbûna plansazkirî re, dê her tişt cidîtir bibe. Û li pêş wê bû ku pêşveçûna serîlêdana mobîl be (ew di sala 2017-an de dest pê kir, û di 2018-an de bû ).
Parçeyên cûda yên pergalê hewceyê astên cûda yên aramiyê bûn, lê ji ber girêdana bihêz a pergalê, me nekarî vê yekê peyda bikin. Di pêşkeftina fonksiyonek nû de di panela rêveberiyê de xeletiyek baş dikaribû di pejirandina fermanek li ser malperê de çêbibe, ji ber ku kod hevpar e û ji nû ve tê bikar anîn, databas û dane jî yek in.
Dibe ku di çarçoveya mîmariyek wusa yekparêz-modular de ji van xeletî û pirsgirêkan dûr bikevin: dabeşkirina berpirsiyariyê bikin, hem kod û hem jî databasê nûve bikin, bi zelalî qatan ji hev veqetînin, her roj kalîteyê bişopînin. Lê çareseriyên mîmarî yên hilbijartî û balkişandina li ser berfirehbûna bilez a fonksiyona pergalê di warê aramiyê de bû sedema pirsgirêkan.
Çawa bloga Hêza Hişê kaseyên dravê li xwaringehan datîne
Ger mezinbûna tora pizzeryayê (û barkirin) bi heman lezê bidome, wê hingê piştî demekê dê hilweşîn wusa be ku pergal ranebe. Baş eşkere dike ku pirsgirêkên ku me di sala 2015-an de pê re rû bi rû mane, li vir çîrokek wusa ye.
Di blogê de "” widgetek bû ku daneyên li ser dahata salê ya tevahiya torê nîşan dide. Widget gihîştiye API-ya giştî ya Dodo, ku vê daneyê peyda dike. Ev statîstîk niha li vir heye . Widget li ser her rûpelê hate xuyang kirin û her 20 saniyeyan li ser demjimêrek daxwazek çêkir. Daxwaz çû api.dodopizza.ru û daxwaz kir:
-
hejmara pizzerias di torê de;
-
tevahiya dahata torê ya ji destpêka salê ve;
-
hatinên ji bo îro.
Daxwaza statîstîkên li ser dahatê rasterast çû ser databasê û dest bi daxwaza daneyan li ser fermanan kir, daneyên li ser firînê berhev kir û mîqdarê da.
Maseyên dravê yên li xwaringehan çûn ser heman tabloya fermanan, navnîşek fermanên ku ji bo îro hatine wergirtin rakirin û fermanên nû li wê zêde kirin. Qeydên drav daxwazên xwe her 5 saniyeyan an li ser nûvekirina rûpelê didin.
Diagram bi vî rengî xuya bû:
Payîzekê, Fyodor Ovchinnikov gotarek dirêj û populer li ser bloga xwe nivîsî. Gelek kes hatin blogê û dest bi xwendina her tiştî bi baldarî kirin. Dema ku her yek ji kesên ku hatin gotarê dixwend, widgeta dahatê bi rêkûpêk xebitî û her 20 saniyeyan API-yê xwest.
API gazî pêvajoyek hilanînê kir ku ji destpêka salê û vir ve ji bo hemî pîzeryayên di zincîrê de berhevoka hemî fermanan hesab bike. Kombûn li ser tabloya fermanan bû, ku pir populer e. Hemî maseyên dravê yên hemî xwaringehên vekirî yên wê demê diçin wê. Maseyên dravê bersiv sekinîn, ferman nehatin qebûl kirin. Di heman demê de ew ji malperê nehatin pejirandin, li şopgerê xuya nebûn, rêvebirê guheztinê nikaribû wan di navbeynkariya xwe de bibîne.
Ev ne tenê çîrok e. Heya payîza 2015-an, her Înî barkirina pergalê krîtîk bû. Çend caran me API-ya giştî qut kir, û carek jî, me neçar ma ku malperê qut bikin, ji ber ku tiştek nekariye. Tewra navnîşek karûbarên ku di bin barên giran de fermana sekinandinê jî hebû.
Ji niha û pê ve têkoşîna me ya bi bar û ji bo îstiqrara sîstemê (ji payîza 2015’an heta payîza 2018’an) dest pê dike. Wê demê ev çêbû"". Wekî din, carinan têkçûn jî çêdibûn, hin jî pir hesas bûn, lê heyama giştî ya bêîstiqrariyê êdî dikare derbasbûyî were hesibandin.
Pêşveçûna karsaziyê ya bilez
Çima di cih de nehat kirin? Tenê li grafikên jêrîn binêrin.
Her wiha di salên 2014-2015’an de li Romanyayê vebûn hebû û li DYA’yê jî vebûn dihat amadekirin.
Tora pir zû mezin bû, welatên nû hatin vekirin, formên nû yên pizeryayan xuya bûn, mînakî, pizzeryayek li dadgeha xwarinê hate vekirin. Hemî vê yekê bi taybetî ji bo berfirehkirina fonksiyonên Dodo IS baldariyek girîng hewce dike. Bêyî van hemî fonksiyonan, bêyî şopandina di metbexê de, hesabkirina hilber û windahiyên di pergalê de, nîşandana fermanek li salona dadgeha xwarinê, em ê bi zehmetî qala mîmariya "rast" û nêzîkatiya "rast" bikin. pêşketina niha.
Astengiyek din a li ber vejandina biwext a mîmariyê û bi giştî balkişandina li ser pirsgirêkên teknîkî krîza 2014 bû. Tiştên bi vî rengî li fersendên mezinbûna tîmê, nemaze ji bo karsaziyek ciwanek mîna Dodo Pizza, bi dijwarî dixe.
Çareseriyên Bilez ku Alîkarî kirin
Pirsgirêkan hewceyê çareseriyê bûn. Bi kevneşopî, çareserî dikarin li 2 koman bêne dabeş kirin:
-
Yên bilez ên ku agir vedimirînin û marjîneyek piçûk a ewlehiyê didin me û ji me re wextê guheztinê bikirin.
-
Pergalî û, ji ber vê yekê, dirêj. Ji nû ve endezyariya hejmarek modulan, dabeşkirina mîmariya yekparêz li ser karûbarên cihêreng (piraniya wan qet ne mîkro ne, lê bêtir karûbarên makro ne, û tiştek di derheqê wê de heye ).
Lîsteya hişk a guhertinên bilez wiha ye:
Serwerê bingehê mezin bikin
Bê guman, yekem tiştê ku ji bo mijûlbûna bi barkêşan re tê kirin ev e ku kapasîteya serverê zêde bike. Ev ji bo databasa master û ji bo serverên malperê hate kirin. Mixabin, ev tenê heya sînorek diyarkirî gengaz e, wê hingê ew pir biha dibe.
Ji sala 2014-an vir ve, em çûne Azure, me di wê demê de di gotarê de jî li ser vê mijarê nivîsî "". Lê piştî rêzek zêdekirina serverê ji bo bingehê, ew li dijî lêçûnê derketin.
Replicayên bingehîn ji bo xwendinê
Ji bo bingehê du replica hatin çêkirin:
ReadReplica ji bo daxwazên referansê. Ew ji bo xwendina pelrêçan, celeb, bajar, kolan, pizzeria, hilberan (hêdî hêdî-hêdî guheztin domain), û di wan navberan de ku derengek piçûk tê pejirandin tê bikar anîn. 2 ji van replikayan hebûn, me hebûna wan bi heman awayê axayan misoger kir.
Ji bo Daxwazên Raporê Replica bixwînin. Vê databasê hebûna hindiktir bû, lê hemî rapor jê re çûn. Bila ji wan re daxwazên giran hebin ji bo ji nû ve hesibandina daneya mezin, lê ew bandorê li databasa bingehîn û navbeynkarên xebitandinê nakin.
Caches di kodê de
Di kodê de (bi tevahî) veşart tune bûn. Ev bû sedema daxwazên zêde, ne her gav hewcedar, ji databasa barkirî re. Caches yekem hem di bîrê de û hem jî li ser karûbarek cache ya derveyî bûn, ew Redis bû. Her tişt ji hêla demê ve hate betal kirin, mîhengan di kodê de hatine destnîşan kirin.
Pêşkêşkerên paşîn ên pirjimar
Di heman demê de pêdivî bû ku paşiya serîlêdanê were pîvandin da ku bargiraniyên zêde yên xebatê bigire. Pêwîst bû ku ji yek iis-server komik were çêkirin. Me ji nû ve plan kir ji bîranînê bigire heya RedisCache, ku ev gengaz kir ku meriv li pişt hevsengek bargiranek hêsan a bi dorpêk ve gelek pêşkêşkeran çêbike. Di destpêkê de, heman Redis wekî ji bo caches hate bikar anîn, paşê ew li çendan hate dabeş kirin.
Wekî encamek, mîmarî tevlihevtir bûye ...
… lê hinek ji tengezariyê hat rakirin.
Û dûv re hewce bû ku em hêmanên barkirî, yên ku me hildan, ji nû ve bikin. Em ê li ser vê yekê di beşa pêş de biaxivin.
Source: www.habr.com