Aŭ ĉiu malfeliĉa kompanio kun monolito estas malfeliĉa laŭ sia maniero.
La evoluo de la Dodo IS-sistemo tuj komenciĝis, kiel la Dodo Pizza-komerco, en 2011. Ĝi baziĝis sur la ideo de kompleta kaj totala ciferecigo de komercaj procezoj, kaj , kiu eĉ tiam en 2011 kaŭzis multajn demandojn kaj skeptikon. Sed jam de 9 jaroj ni sekvas ĉi tiun vojon - per propra evoluo, kiu komenciĝis per monolito.
Ĉi tiu artikolo estas "respondo" al la demandoj "Kial reverki la arkitekturon kaj fari tiajn grandskalajn kaj longdaŭrajn ŝanĝojn?" reen al antaŭa artikolo . Mi komencos per kiel komenciĝis la evoluo de Dodo IS, kiel aspektis la originala arkitekturo, kiel aperis novaj moduloj kaj pro kiaj problemoj grandskalaj ŝanĝoj devis esti faritaj.
Serio de artikoloj "Kio estas Dodo IS?" rakontas pri:
-
Frua monolito en Dodo IS (2011-2015). (vi estas ĉi tie)
-
.
-
La klienta flanka vojo: fasado super la bazo (2016-2017). (En progreso...)
-
La historio de realaj mikroservoj. (2018-2019). (En progreso...)
-
Finita segado de la monolito kaj stabiligo de la arkitekturo. (En progreso...)
Komenca arkitekturo
En 2011, la Dodo IS-arkitekturo aspektis jene:
La unua modulo en la arkitekturo estas mendo-akcepto. La komerca procezo estis:
-
la kliento vokas la picejon;
-
la administranto prenas la telefonon;
-
akceptas mendon per telefono;
-
paralele plenigas ĝin en la interfaco de akcepto de mendo: ĝi konsideras informojn pri la kliento, datumojn pri mendodetaloj, liveran adreson.
La interfaco de la informsistemo aspektis kiel ĉi tio...
Unua versio de oktobro 2011:
Rimedoj por la disvolviĝo de la unua ordo prenanta modulo estis limigitaj. Ni devis fari multon, rapide kaj kun malgranda teamo. Malgranda teamo estas 2 programistoj, kiuj metis la fundamenton por la tuta estonta sistemo.
Ilia unua decido determinis la sorton de la teknologia stako:
-
Backend sur ASP.NET MVC, C#-lingvo. La programistoj estis dotnetchiki, ĉi tiu stako estis konata kaj agrabla al ili.
-
Frontend sur Bootstrap kaj JQuery: uzantinterfacoj pri memskribitaj stiloj kaj skriptoj.
-
MySQL-datumbazo: sen licencaj kostoj, facile uzebla.
-
Serviloj sur Windows Server, ĉar .NET tiam povus esti nur sub Vindozo (ni ne diskutos Mono).
Fizike, ĉio ĉi estis esprimita en la "dedic ĉe la gastiganto".
Arkitekturo de Apliko de Mendo
Tiam ĉiuj jam parolis pri mikroservoj, kaj SOA estis uzata en grandaj projektoj dum 5 jaroj, ekzemple, WCF estis publikigita en 2006. Sed tiam ili elektis fidindan kaj provitan solvon.
Jen ĝi.
Asp.Net MVC estas Razor, kiu, laŭ peto de formularo aŭ de kliento, prezentas HTML-paĝon kun servila bildigo. Sur la kliento, CSS kaj JS-skriptoj jam montras informojn kaj, se necese, plenumas AJAX-petojn per JQuery.
Petoj sur la servilo finiĝas en la *Regilo-klasoj, kie la prilaborado kaj generacio de la fina HTML-paĝo okazas en la metodo. Regiloj faras petojn al tavolo de logiko nomata *Servoj. Ĉiu el la servoj egalrilatis al iu aspekto de la komerco:
-
Ekzemple, DepartmentStructureService donis informojn pri picejoj, pri fakoj. Sekcio estas grupo de picejoj prizorgita fare de ununura koncesiulo.
-
ReceivingOrdersService akceptis kaj kalkulis la konsiston de la mendo.
-
Kaj SmsService sendis SMS vokante API-servojn por sendi SMS.
Servoj prilaboris datumojn de la datumbazo, konservis komercan logikon. Ĉiu servo havis unu aŭ plurajn *Deponejojn kun la taŭga nomo. Ili jam enhavis demandojn al stokitaj proceduroj en la datumbazo kaj tavolo de mapistoj. Estis komerca logiko en la stokejoj, precipe multe en tiuj, kiuj elsendis raportajn datumojn. ORM ne estis uzata, ĉiuj fidis mane skribitan sql.
Ekzistis ankaŭ tavolo de la domajna modelo kaj oftaj helpaj klasoj, ekzemple, la Ordo klaso kiu stokis la ordon. Samloke, en la tavolo, estis helpanto por konverti la montran tekston laŭ la elektita valuto.
Ĉio ĉi povas esti reprezentita per tia modelo:
Ordo Vojo
Konsideru simpligitan komencan manieron krei tian ordon.
Komence, la retejo estis senmova. Ĝi havis prezojn sur ĝi, kaj supre - telefonnumero kaj la surskribo "Se vi volas picon - voku la numeron kaj mendu." Por ordigi, ni devas efektivigi simplan fluon:
-
La kliento vizitas statikan retejon kun prezoj, elektas produktojn kaj vokas la numeron listigitan sur la retejo.
-
La kliento nomas la produktojn, kiujn ili volas aldoni al la mendo.
-
Donas sian adreson kaj nomon.
-
La operatoro akceptas la mendon.
-
La ordo estas montrata en la interfaco de akceptitaj mendoj.
Ĉio komenciĝas per montrado de la menuo. Ensalutinta uzanto-funkciigisto akceptas nur unu mendon samtempe. Tial, la skiza ĉaro povas esti konservita en lia sesio (la sesio de la uzanto estas konservita en memoro). Estas Cart-objekto enhavanta produktojn kaj klientajn informojn.
La kliento nomas la produkton, la operatoro alklakas + apud la produkto, kaj peto estas sendita al la servilo. Informoj pri la produkto estas eltirita el la datumbazo kaj informoj pri la produkto estas aldonitaj al la ĉaro.
Примечание. Jes, ĉi tie vi ne povas tiri la produkton el la datumbazo, sed translokigi ĝin de la fasado. Sed por klareco, mi montris ĝuste la vojon el la datumbazo.
Poste, enigu la adreson kaj nomon de la kliento.
Kiam vi alklakas "Krei Mendon":
-
La peto estas sendita al OrderController.SaveOrder ().
-
Ni ricevas Ĉaron de la kunsido, estas produktoj en la kvanto, kiun ni bezonas.
-
Ni kompletigas la Ĉaron kun informoj pri la kliento kaj transdonas ĝin al la AddOrder-metodo de la ReceivingOrderService-klaso, kie ĝi estas konservita al la datumbazo.
-
La datumbazo havas tabelojn kun la ordo, la konsisto de la ordo, la kliento, kaj ili ĉiuj estas konektitaj.
-
La mendo-montra interfaco iras kaj eltiras la plej novajn mendojn kaj montras ilin.
Novaj moduloj
Preni la ordon estis grava kaj necesa. Vi ne povas fari pickomercon se vi ne havas mendon por vendi. Tial la sistemo komencis akiri funkciojn - proksimume de 2012 ĝis 2015. Dum ĉi tiu tempo, multaj malsamaj blokoj de la sistemo aperis, kiujn mi nomos moduloj, kontraste al la koncepto de servo aŭ produkto.
Modulo estas aro de funkcioj, kiuj estas kunigitaj per iu komuna komerca celo. Samtempe ili estas fizike en la sama aplikaĵo.
Moduloj povas esti nomitaj sistemblokoj. Ekzemple, ĉi tio estas raporta modulo, administraj interfacoj, , rajtigo. Ĉi tiuj estas ĉiuj malsamaj uzantinterfacoj, kelkaj eĉ havas malsamajn vidajn stilojn. Samtempe ĉio estas en la kadro de unu aplikaĵo, unu funkcianta procezo.
Teknike, la moduloj estis dizajnitaj kiel Areo (tia ideo eĉ restis en ). Ekzistis apartaj dosieroj por la fasado, modeloj, same kiel siaj propraj regilaj klasoj. Kiel rezulto, la sistemo estis transformita de ĉi tio ...
...en ĉi tion:
Kelkaj moduloj estas efektivigitaj de apartaj retejoj (efektivebla projekto), pro tute aparta funkcieco kaj parte pro iom aparta, pli fokusita evoluo. Ĉi tio:
-
ejo - retejo dodopizza.ru.
-
eksportado: alŝuto de raportoj de Dodo IS por 1C.
-
persona - persona konto de la dungito. Ĝi estis evoluigita aparte kaj havas sian propran enirpunkton kaj apartan dezajnon.
-
fs — projekto por gastigado de statiko. Poste ni malproksimiĝis de ĝi, movante ĉiujn statikojn al la Akamai CDN.
La resto de la blokoj estis en la aplikaĵo BackOffice.
Noma klarigo:
-
Kasisto - Restoracia kasisto.
-
ShiftManager - interfacoj por la rolo "Shift Manager": operaciaj statistikoj pri pizzeria vendo, la kapablo meti produktojn en la haltliston, ŝanĝi la ordon.
-
OfficeManager - interfacoj por la "Pizzeria Manager" kaj "Franĉizisto" roloj. Ĉi tie estas kolektitaj funkcioj por starigi picejon, ĝiaj bonusaj promocioj, ricevi kaj labori kun dungitoj, raportoj.
-
PublicScreens - interfacoj por televidiloj kaj tablojdoj pendantaj en picejoj. Televidiloj montras menuojn, reklamajn informojn, mendostatuson post livero.
Ili uzis oftan servotavolon, oftan Dodo.Core domajnan klasblokon, kaj komunan bazon. Kelkfoje ili ankoraŭ povis konduki laŭ la transiroj unu al la alia. Inkluzive de individuaj retejoj, kiel dodopizza.ru aŭ personal.dodopizza.ru, iris al ĝeneralaj servoj.
Kiam aperis novaj moduloj, ni provis maksimume reuzi la jam kreitan kodon de servoj, konservitajn procedurojn kaj tabelojn en la datumbazo.
Por pli bona kompreno de la skalo de la moduloj faritaj en la sistemo, jen diagramo de 2012 kun disvolvaj planoj:
Antaŭ 2015, ĉio estis sur la mapo kaj eĉ pli estis en produktado.
-
Akcepto de mendo kreskis en apartan blokon de la Kontakto-Centro, kie la mendo estas akceptita de la funkciigisto.
-
Estis publikaj ekranoj kun menuoj kaj informoj pendantaj en picejoj.
-
La kuirejo havas modulon, kiu aŭtomate ludas la voĉmesaĝon "Nova Pico" kiam nova mendo alvenas, kaj ankaŭ presas fakturon por la kuriero. Ĉi tio multe simpligas la procezojn en la kuirejo, permesas al dungitoj ne esti distritaj per granda nombro da simplaj operacioj.
-
La liverunuo iĝis aparta Liverkato, kie la mendo estis eldonita al la kuriero kiu antaŭe prenis la deĵoron. Lia labortempo estis enkalkulita por salajrokalkulo.
Paralele, de 2012 ĝis 2015, pli ol 10 programistoj aperis, 35 picejoj malfermiĝis, deplojis la sistemon al Rumanio kaj prepariĝis por la malfermo de ellasejoj en Usono. La programistoj ne plu traktis ĉiujn taskojn, sed estis dividitaj en teamojn. ĉiu specialiĝis pri sia propra parto de la sistemo.
Problemoj
Inkluzive pro la arkitekturo (sed ne nur).
Kaoso en la bazo
Unu bazo estas oportuna. Konsistenco povas esti atingita en ĝi, kaj koste de iloj konstruitaj en interrilatajn datumbazojn. Labori kun ĝi estas konata kaj oportuna, precipe se estas malmultaj tabeloj kaj malmulte da datumoj.
Sed dum 4 jaroj da evoluo, la datumbazo montriĝis havi ĉirkaŭ 600 tabelojn, 1500 konservitajn procedurojn, multaj el kiuj ankaŭ havis logikon. Ve, stokitaj proceduroj ne alportas multe da avantaĝo kiam vi laboras kun MySQL. Ili ne estas konservitaj en kaŝmemoro de la bazo, kaj stoki logikon en ili malfaciligas evoluon kaj senararigon. Kodreuzo ankaŭ estas malfacila.
Multaj tabeloj ne havis taŭgajn indeksojn, ie, male, estis multaj indeksoj, kiuj malfaciligis la enmetadon. Necesis modifi ĉirkaŭ 20 tabelojn - la transakcio por krei mendon povus daŭri ĉirkaŭ 3-5 sekundojn.
La datumoj en la tabeloj ne estis ĉiam en la plej taŭga formo. Ie necesis fari malnormaligon. Parto de la regule ricevitaj datumoj estis en kolumno en formo de XML-strukturo, tio pliigis la ekzekuttempon, plilongigis la demandojn kaj malfaciligis la evoluon.
Al la samaj tabloj produktis tre heterogenaj petoj. Popularaj tabloj suferis precipe, kiel la supre menciita tablo. ordonojn aŭ tabloj picejo. Ili kutimis montri operaciajn interfacojn en la kuirejo, analitiko. Alia retejo kontaktis ilin (), kie iam ajn povus veni subite multaj petoj.
La datumoj ne estis kunigitaj kaj multaj kalkuloj okazis sur la flugo uzante la bazon. Ĉi tio kreis nenecesajn kalkulojn kaj plian ŝarĝon.
Ofte la kodo iris al la datumbazo kiam ĝi ne povis fari tion. Ie ne estis sufiĉe da pograndaj operacioj, ie necesus disvastigi unu peton en plurajn per la kodo por plirapidigi kaj pliigi fidindecon.
Kohezio kaj malklarigado en kodo
Moduloj kiuj laŭsupoze estis respondecaj pri sia parto de la komerco ne faris ĝin honeste. Kelkaj el ili havis multobligon de funkcioj por roloj. Ekzemple, loka merkatisto, kiu respondecas pri la merkatagado de la reto en sia urbo, devis uzi kaj la interfacon "Admin" (por krei promociojn) kaj la interfacon "Office Manager" (por vidi la efikon de promocioj sur la komerco). Kompreneble, ene de ambaŭ moduloj uzis la saman servon kiu funkciis kun bonusaj promocioj.
Servoj (klasoj ene de unu monolita granda projekto) povus voki unu la alian por riĉigi siajn datumojn.
Kun la modelklasoj mem, kiuj stokas datumojn, laboro en la kodo estis farita alimaniere. Ie estis konstrukciistoj per kiuj eblis specifi postulatajn kampojn. Ie tio estis farita per publikaj proprietoj. Kompreneble, akiri kaj transformi datumojn de la datumbazo estis diversa.
La logiko estis aŭ en la regiloj aŭ en la servoklasoj.
Ĉi tiuj ŝajnas esti negravaj problemoj, sed ili tre malrapidigis evoluon kaj reduktis kvaliton, kondukante al malstabileco kaj cimoj.
La komplekseco de granda evoluo
Malfacilaĵoj ekestis en la evoluo mem. Necesis fari malsamajn blokojn de la sistemo, kaj paralele. Konveni la bezonojn de ĉiu komponento en ununuran kodon iĝis ĉiam pli malfacila. Ne estis facile konsenti kaj plezurigi ĉiujn komponantojn samtempe. Al tio aldoniĝis limigoj en teknologio, precipe koncerne la bazon kaj fasadon. Necesis forlasi jQuery al altnivelaj kadroj, precipe rilate al klientservoj (retejo).
En kelkaj partoj de la sistemo, datumbazoj pli taŭgaj por tio povus esti uzataj.. Ekzemple, poste ni havis la uzon de translokiĝo de Redis al CosmosDB por konservi mendan korbon.
Teamoj kaj programistoj implikitaj en sia kampo klare deziris pli da aŭtonomio por siaj servoj, kaj laŭ evoluo kaj lanĉo. Kunfandi konfliktojn, liberigu problemojn. Se por 5 programistoj ĉi tiu problemo estas sensignifa, tiam kun 10, kaj eĉ pli kun la planita kresko, ĉio fariĝus pli serioza. Kaj antaŭen estis la evoluo de poŝtelefona aplikaĵo (ĝi komenciĝis en 2017, kaj en 2018 ĝi estis ).
Malsamaj partoj de la sistemo postulis malsamajn nivelojn de stabileco, sed pro la forta konektebleco de la sistemo, ni ne povis provizi ĉi tion. Eraro en la disvolviĝo de nova funkcio en la administra panelo povus bone okazi en la akcepto de mendo en la retejo, ĉar la kodo estas ofta kaj reuzebla, la datumbazo kaj datumoj ankaŭ estas la samaj.
Verŝajne eblus eviti tiujn erarojn kaj problemojn en la kadro de tia monolita-modula arkitekturo: fari dividon de respondeco, refaktori kaj la kodon kaj la datumbazon, klare apartigi la tavolojn unu de la alia, kontroli la kvaliton ĉiutage. Sed la elektitaj arkitekturaj solvoj kaj la fokuso sur la rapida vastiĝo de la funkcieco de la sistemo kondukis al problemoj laŭ stabileco.
Kiel la blogo Power of the Mind metis la kasojn en restoraciojn
Se la kresko de la pizzeria reto (kaj ŝarĝo) daŭris samrapide, tiam post iom da tempo la faloj estus tiaj, ke la sistemo ne altiĝos. Bone ilustras la problemojn, kiujn ni komencis alfronti antaŭ 2015, jen tia rakonto.
En la blogo "” estis fenestraĵo kiu montris datumojn pri enspezo por la jaro de la tuta reto. La fenestraĵo aliris la publikan API de Dodo, kiu provizas ĉi tiujn datumojn. Ĉi tiu statistiko estas nuntempe havebla ĉe . La fenestraĵo estis montrita sur ĉiu paĝo kaj faris petojn per tempigilo ĉiujn 20 sekundojn. La peto iris al api.dodopizza.ru kaj petis:
-
la nombro da picejoj en la reto;
-
totala reto-enspezo ekde la komenco de la jaro;
-
enspezo por hodiaŭ.
La peto pri statistiko pri enspezo iris rekte al la datumbazo kaj komencis peti datumojn pri mendoj, kunigante datumojn sur la flugo kaj eldoni la kvanton.
Kasoj en restoracioj iris al la sama tablo de mendoj, malŝarĝis liston de mendoj ricevitaj por hodiaŭ, kaj novaj mendoj estis aldonitaj al ĝi. Kasregistriloj faris siajn petojn ĉiujn 5 sekundojn aŭ sur paĝa refreŝiĝo.
La diagramo aspektis jene:
Unu aŭtuno, Fjodor Ovĉinnikov skribis longan kaj popularan artikolon en sia blogo. Multaj homoj venis al la blogo kaj komencis legi ĉion atente. Dum ĉiu el la homoj, kiuj venis, legis la artikolon, la enspeza fenestraĵo funkciis ĝuste kaj petis la API ĉiujn 20 sekundojn.
La API nomis konservitan proceduron por kalkuli la sumon de ĉiuj mendoj ekde la komenco de la jaro por ĉiuj picejoj en la reto. La agregado baziĝis sur la tabelo de mendoj, kiu estas tre populara. Ĉiuj kasoj de ĉiuj malfermitaj restoracioj tiutempe iras al ĝi. Kasejoj ĉesis respondi, mendoj ne estis akceptitaj. Ili ankaŭ ne estis akceptitaj de la retejo, ne aperis sur la spurilo, la deĵorestro ne povis vidi ilin en sia interfaco.
Ĉi tio ne estas la sola rakonto. Antaŭ la aŭtuno de 2015, ĉiun vendredon la ŝarĝo sur la sistemo estis kritika. Plurfoje ni malŝaltis la publikan API, kaj unufoje, ni eĉ devis malŝalti la retejon, ĉar nenio helpis. Ekzistis eĉ listo de servoj kun ferma ordo sub pezaj ŝarĝoj.
Ekde nun komenciĝas nia lukto kun ŝarĝoj kaj por la stabiligo de la sistemo (de aŭtuno 2015 ĝis aŭtuno 2018). Tio estis kiam ĝi okazis"". Plue, malsukcesoj ankaŭ foje okazis, kelkaj estis tre sentemaj, sed la ĝenerala periodo de malstabileco nun povas esti konsiderata forpasita.
Rapida komerca kresko
Kial ĝi ne povus esti farita tuj? Nur rigardu la sekvajn leterojn.
Ankaŭ en 2014-2015 estis malfermo en Rumanio kaj malfermo en Usono estis preparita.
La reto kreskis tre rapide, novaj landoj estis malfermitaj, novaj formatoj de picejoj aperis, ekzemple, picejo estis malfermita ĉe la manĝejo. Ĉio ĉi postulis gravan atenton specife al la ekspansio de Dodo IS-funkcioj. Sen ĉiuj ĉi tiuj funkcioj, sen spurado en la kuirejo, kontado pri produktoj kaj perdoj en la sistemo, montrado de ordono en la manĝejo, ni apenaŭ parolus pri la "ĝusta" arkitekturo kaj la "ĝusta" aliro al evoluo nun.
Alia obstaklo al la ĝustatempa revizio de la arkitekturo kaj ĝenerale atento al teknikaj problemoj estis la krizo de 2014. Tiaj aferoj forte trafis ŝancojn por teamoj kreski, precipe por juna komerco kiel Dodo Pizza.
Rapidaj Solvoj Kiu Helpis
Problemoj bezonataj solvoj. Konvencie, solvoj povas esti dividitaj en 2 grupojn:
-
Rapidaj, kiuj estingas la fajron kaj donas malgrandan marĝenon de sekureco kaj aĉetas al ni tempon por ŝanĝi.
-
Sisteme kaj, do, longa. Reinĝenierado de kelkaj moduloj, divido de monolita arkitekturo en apartajn servojn (plej multaj el ili tute ne estas mikro, sed prefere makroservoj, kaj estas io pri tio ).
La seka listo de rapidaj ŝanĝoj estas jena:
Pligrandigu bazan majstron
Kompreneble, la unua afero, kiun oni faras por trakti ŝarĝojn, estas pliigi la kapablon de la servilo. Ĉi tio estis farita por la majstra datumbazo kaj por retserviloj. Ve, tio eblas nur ĝis certa limo, tiam ĝi fariĝas tro multekosta.
Ekde 2014, ni translokiĝis al Azure, ni ankaŭ skribis pri ĉi tiu temo tiutempe en la artikolo "". Sed post serio da pliiĝoj en la servilo por la bazo, ili renkontis la koston.
Bazaj kopioj por legado
Du kopioj estis faritaj por la bazo:
LeguReplikon por referencaj petoj. Ĝi estas uzata por legi dosierujojn, tipon, urbon, straton, picejon, produktojn (malrapide ŝanĝita domajno), kaj en tiuj interfacoj kie malgranda prokrasto estas akceptebla. Estis 2 el ĉi tiuj kopioj, ni certigis ilian haveblecon same kiel la majstroj.
ReadReplica por Raportaj Petoj. Ĉi tiu datumbazo havis pli malaltan haveblecon, sed ĉiuj raportoj iris al ĝi. Lasu ilin havi pezajn petojn por grandegaj datumaj rekalkuloj, sed ili ne influas la ĉefan datumbazon kaj operaciajn interfacojn.
Kaŝmemoroj en kodo
Ne estis kaŝmemoroj ie ajn en la kodo (tute). Ĉi tio kondukis al pliaj, ne ĉiam necesaj, petoj al la ŝarĝita datumbazo. Deponejoj unue estis kaj en-memoro kaj sur ekstera kaŝmemorservo, tio estis Redis. Ĉio estis malvalidigita de tempo, la agordoj estis specifitaj en la kodo.
Multoblaj backend serviloj
La malantaŭo de la aplikaĵo ankaŭ devis esti skaligita por trakti la pliigitajn laborŝarĝojn. Necesis fari aron el unu iis-servilo. Ni replanigis de memoro al RedisCache, kiu ebligis fari plurajn servilojn malantaŭ simpla ŝarĝbalancilo kun round robin. Komence, la sama Redis estis uzata kiel por kaŝmemoroj, poste ĝi estis dividita en plurajn.
Kiel rezulto, la arkitekturo fariĝis pli komplika ...
… sed iom da streĉiĝo estis forigita.
Kaj tiam necesis refari la ŝarĝitajn komponantojn, kiujn ni entreprenis. Pri tio ni parolos en la sekva parto.
fonto: www.habr.com