O ogni cumpagnia infelice cù un monolitu hè infelice in u so modu.
U sviluppu di u sistema Dodo IS hà iniziatu immediatamente, cum'è l'affari Dodo Pizza, in 2011. Hè stata basatu annantu à l'idea di digitalizazione cumpleta è tutale di i prucessi di cummerciale, è , chì ancu allora in 2011 hà causatu assai dumande è scetticismu. Ma per 9 anni avemu seguitu sta strada - cù u nostru sviluppu, chì principia cù un monolitu.
Questu articulu hè una "risposta" à e dumande "Perchè riscrive l'architettura è fà cambiamenti cusì grande è longu?" torna à l'articulu precedente . Accuminciaraghju cù cumu u sviluppu di Dodo IS hà iniziatu, cumu l'architettura originale pareva, cumu si prisentanu novi moduli, è per via di quali prublemi anu da esse fatte cambiamenti à grande scala.
Serie di articuli "Chì hè Dodo IS?" parla di:
-
Primu monolitu in Dodo IS (2011-2015). (tu sì quì)
-
.
-
U percorsu di u cliente: facciata sopra a basa (2016-2017). (In corsu...)
-
A storia di i veri microservizi. (2018-2019). (In corsu...)
-
Sega finita di u monolitu è stabilizazione di l'architettura. (In corsu...)
Architettura iniziale
In u 2011, l'architettura Dodo IS pareva cusì:
U primu modulu in l'architettura hè l'accettazione di l'ordine. U prucessu cummerciale era:
-
u cliente chjama a pizzeria;
-
u manager piglia u telefuninu;
-
accetta un ordine per telefonu;
-
u riempie in parallelu in l'interfaccia di accettazione di l'ordine: piglia in contu l'infurmazioni nantu à u cliente, i dati nantu à i dettagli di l'ordine, l'indirizzu di consegna.
L'interfaccia di u sistema d'infurmazione pareva qualcosa cusì ...
Prima versione da uttrovi 2011:
I risorse per u sviluppu di u modulu di primu ordine sò limitati. Avemu avutu à fà assai, prestu è cù una piccula squadra. Una piccula squadra hè 2 sviluppatori chì pusonu i fundamenti per tuttu u sistema futuru.
A so prima decisione hà determinatu u destinu di a pila di tecnulugia:
-
Backend in ASP.NET MVC, lingua C#. I sviluppatori eranu dotnetchiki, sta pila era familiar è piacevule per elli.
-
Frontend nantu à Bootstrap è JQuery: interfacce d'utilizatori nantu à stili è script auto-scritti.
-
Database MySQL: senza costi di licenza, faciule d'utilizà.
-
Servitori in Windows Server, perchè .NET allora puderia esse solu sottu Windows (ùn discuteremu micca di Mono).
Fisicamente, tuttu questu hè statu spressu in u "dedic at the hoster".
Architettura di l'applicazioni di ingressu di ordini
Allora tutti parlavanu digià di i microservizi, è SOA hè stata utilizata in grandi prughjetti per 5 anni, per esempiu, WCF hè stata liberata in 2006. Ma dopu sceglienu una soluzione affidabile è pruvata.
Eccu.
Asp.Net MVC hè Razor, chì, nantu à a dumanda da una forma o da un cliente, rende una pagina HTML cù u servitore. Nantu à u cliente, i script CSS è JS mostranu digià infurmazioni è, se ne necessariu, eseguite richieste AJAX attraversu JQuery.
E dumande nantu à u servitore finiscinu in i classi *Controller, induve a trasfurmazioni è a generazione di a pagina HTML finali si trova in u metudu. I cuntrolli facenu dumande à una strata di logica chjamata * Servizi. Ognunu di i servizii currisponde à qualchì aspettu di l'affari:
-
Per esempiu, DepartmentStructureService hà datu infurmazione nantu à pizzeria, nantu à dipartimenti. Un dipartimentu hè un gruppu di pizzeria gestitu da un unicu franchisee.
-
ReceivingOrdersService accettatu è calculatu a cumpusizioni di l'ordine.
-
È SmsService hà mandatu SMS chjamendu i servizii API per mandà SMS.
I servizii anu trattatu dati da a basa di dati, a logica cummerciale almacenata. Ogni serviziu avia unu o più * Repository cù u nome appropritatu. Anu digià cuntenuti dumande à e prucedure almacenate in a basa di dati è una strata di mappe. Ci era una logica cummerciale in i magazzini, soprattuttu assai in quelli chì emettenu dati di rapportu. L'ORM ùn era micca usatu, tutti si basavanu in sql scritti à manu.
Ci era ancu una strata di u mudellu di duminiu è e classi d'aiutu cumuni, per esempiu, a classa Order chì hà guardatu l'ordine. In u stessu locu, in a capa, ci era un aiutu per cunvertisce u testu di visualizazione secondu a valuta scelta.
Tuttu chistu pò esse rapprisintatu da un tali mudellu:
Ordine Way
Cunsiderate un modu simplificatu iniziale per creà un tali ordine.
In principiu, u situ era staticu. Avia i prezzi nantu à questu, è in cima - un numeru di telefunu è l'inscription "Se vulete pizza - chjamate u numeru è ordine". Per ordine, avemu bisognu di implementà un flussu simplice:
-
U cliente visita un situ staticu cù i prezzi, selezziunate i prudutti è chjama u numeru listatu in u situ.
-
U cliente chjama i prudutti chì volenu aghjunghje à l'ordine.
-
Dà u so indirizzu è nome.
-
L'operatore accetta l'ordine.
-
L'ordine hè visualizatu in l'interfaccia di ordini accettati.
Tuttu principia cù a visualizazione di u menu. Un utilizatore-operatore cunnessu accetta solu un ordine à u mumentu. Dunque, u carrettu di draft pò esse guardatu in a so sessione (a sessione di l'utilizatori hè guardata in memoria). Ci hè un oggettu Cart chì cuntene i prudutti è l'infurmazioni di i clienti.
U cliente chjama u pruduttu, l'operatore cliccà + accantu à u pruduttu, è una dumanda hè mandata à u servitore. L'infurmazione nantu à u produttu hè sguassata da a basa di dati è l'infurmazione nantu à u pruduttu hè aghjuntu à u carrettu.
Vita. Iè, quì ùn pudete micca tirà u pruduttu da a basa di dati, ma trasferisce da u frontend. Ma per a chiarezza, aghju dimustratu esattamente u percorsu da a basa di dati.
Dopu, entre l'indirizzu è u nome di u cliente.
Quandu clicate "Crea Ordine":
-
A dumanda hè mandata à OrderController.SaveOrder ().
-
Avemu u Cart da a sessione, ci sò prudutti in a quantità chì avemu bisognu.
-
Cumpulemu u Cart cù l'infurmazioni nantu à u cliente è u passanu à u metudu AddOrder di a classa ReceivingOrderService, induve hè salvatu à a basa di dati.
-
A basa di dati hà tavule cù l'ordine, a cumpusizioni di l'ordine, u cliente, è sò tutti cunnessi.
-
L'interfaccia di visualizazione di l'ordine va è tira fora l'ultimi ordini è li mostra.
Moduli novi
Piglià l'ordine era impurtante è necessariu. Ùn pudete micca fà un affari di pizza se ùn avete micca un ordine per vende. Dunque, u sistema hà cuminciatu à acquistà funziunalità - circa da 2012 à 2015. Duranti stu tempu, parechji blocchi diffirenti di u sistema apparsu, chì chjamaraghju moduli, in uppusizione à u cuncettu di serviziu o pruduttu.
Un modulu hè un inseme di funzioni chì sò uniti da qualchì scopu cummerciale cumuni. À u listessu tempu, sò fisicamenti in a listessa applicazione.
I moduli ponu esse chjamati blocchi di sistema. Per esempiu, questu hè un modulu di rapportu, interfacce admin, , l'autorizazione. Quessi sò tutti interfacce d'utilizatori diffirenti, alcuni anu ancu stili visuali diffirenti. À u listessu tempu, tuttu hè in u quadru di una applicazione, un prucessu in esecuzione.
Tecnicamente, i moduli sò stati cuncepiti cum'è Area (una tale idea hè stata ancu in ). Ci sò stati schedarii separati per u frontend, mudelli, è ancu e so classi di controller. In u risultatu, u sistema hè statu trasfurmatu da questu ...
... in questu:
Certi moduli sò implementati da siti separati (prughjettu eseguibile), per via di una funziunalità completamente separata è in parte per un sviluppu pocu separatu, più focu. Questu:
-
di u situ - situ dodopizza.ru.
-
Esporta: caricate rapporti da Dodo IS per 1C.
-
pirsunali - contu persunale di l'impiigatu. Hè statu sviluppatu separatamente è hà u so propiu puntu d'entrata è un disignu separatu.
-
fs - un prughjettu per hosting statics. In seguitu avemu alluntanatu da ellu, movendu tutte e statiche à u CDN Akamai.
U restu di i blocchi eranu in l'applicazione BackOffice.
Spiegazione di u nome:
-
Cashier - Cassiere di ristorante.
-
ShiftManager - interfacce per u rolu "Shift Manager": statistiche operative nantu à a vendita di pizzeria, a capacità di mette i prudutti nantu à a lista di stop, cambià l'ordine.
-
OfficeManager - interfacce per i roli "Pizzeria Manager" è "Franchisee". Quì sò cullate funzioni per a creazione di una pizzeria, i so prumuzioni bonus, riceve è travaglià cù l'impiegati, rapporti.
-
PublicScreens - interfacce per TV è tablette appesi in pizzeria. I TV mostranu menu, informazioni publicitarie, statu di ordine à a consegna.
Anu utilizatu una strata di serviziu cumuni, un bloccu di classi di duminiu cumuni Dodo.Core, è una basa cumuni. Calchì volta puderanu ancu guidà à longu i transizioni l'un à l'altru. Cumpresi siti individuali, cum'è dodopizza.ru o personal.dodopizza.ru, andò à i servizii generali.
Quandu i novi moduli apparsu, avemu pruvatu à reutilizà u codice di servizii digià creatu, prucedure almacenate è tavule in a basa di dati à u massimu.
Per un megliu capiscenu di a scala di i moduli fatti in u sistema, quì hè un diagramma da 2012 cù piani di sviluppu:
In u 2015, tuttu era nantu à a mappa è ancu di più era in produzzione.
-
L'accettazione di l'ordine hè diventata in un bloccu separatu di u Contact Center, induve l'ordine hè accettatu da l'operatore.
-
Ci era schermi publichi cù menu è informazioni appesi in pizzeria.
-
A cucina hà un modulu chì riproduce automaticamente u messagiu vocale "New Pizza" quandu un novu ordine ghjunghje, è ancu stampa una fattura per u corriere. Questu simplificà assai i prucessi in a cucina, permette à l'impiegati di ùn esse distratti da un gran numaru di operazioni simplici.
-
U bloccu di consegna hè diventatu un Checkout di Consegna separatu, induve l'ordine hè statu emessu à u corriere chì avia prima pigliatu u turnu. U so tempu di travagliu hè statu cunsideratu per u calculu di a paga.
In parallelu, da u 2012 à u 2015, più di 10 sviluppatori apparsu, 35 pizzeria aperti, implementatu u sistema in Romania è preparatu per l'apertura di punti di vendita in i Stati Uniti. I sviluppatori ùn anu più trattatu di tutti i travaglii, ma sò stati divisi in squadre. ognunu hè specializatu in a so parte di u sistema.
Problemi
Inclusu per via di l'architettura (ma micca solu).
Caos in a basa
Una basa hè cunvene. A cuerenza pò esse ottenuta in questu, è à a spesa di l'arnesi integrati in basa di dati relazionale. U travagliu cun ellu hè familiar è cunvene, soprattuttu s'ellu ci sò pocu tavule è pocu dati.
Ma più di 4 anni di sviluppu, a basa di dati hè stata di circa 600 tabelle, 1500 prucedure almacenate, assai di quali avianu ancu logica. Alas, e prucedure almacenate ùn portanu micca assai vantaghju quandu travaglia cù MySQL. Ùn sò micca cache da a basa, è l'almacenamiento di a logica in elli complica u sviluppu è a debugging. A reutilizazione di u codice hè ancu difficiule.
Parechji tavule ùn anu micca indici adattati, in qualchì locu, à u cuntrariu, ci era assai indici, chì facia difficiuli di inserisce. Era necessariu di mudificà circa 20 tables - a transazzione per creà un ordine puderia piglià circa 3-5 seconde.
I dati in i tavule ùn sò micca sempre in a forma più apprupriata. In qualchì locu era necessariu di fà a denormalizazione. A parte di e dati ricivuti regularmente era in una colonna in forma di una struttura XML, questu hà aumentatu u tempu d'esekzione, allungatu e dumande è cumplicatu u sviluppu.
À i stessi tavulini sò stati pruduciuti assai richieste eterogenee. I tavulini populari anu patitu soprattuttu, cum'è a tavola citata sopra. cumandati da o tavule Pizzeria. Sò stati usati per vede l'interfaccia operativa in a cucina, analitiche. Un altru situ li hà cuntattatu (), induve in ogni mumentu un saccu di dumande puderia vene di colpu.
I dati ùn sò micca aggregati è parechji calculi anu fattu nantu à a mosca cù a basa. Questu hà creatu calculi innecessarii è carica supplementu.
Spessu u codice andava à a basa di dati quandu ùn pudia micca fà. In qualchì locu ùn ci era micca abbastanza operazioni in massa, in qualchì locu ci vole à sparghje una dumanda in parechje attraversu u codice per accelerà è aumentà a fiducia.
Cohesion and offuscation in codice
I moduli chì anu da esse rispunsevuli di a so parte di l'affari ùn anu micca fattu onestamente. Qualchidunu di elli avianu duplicazione di funzioni per roli. Per esempiu, un venditore lucale chì hè rispunsevuli di l'attività di marketing di a rete in a so cità hà avutu aduprà l'interfaccia "Admin" (per creà promozioni) è l'interfaccia "Office Manager" (per vede l'impattu di e promozioni nantu à l'affari). Di sicuru, in i dui moduli anu utilizatu u stessu serviziu chì hà travagliatu cù promozioni bonus.
I servizii (classi in un grande prughjettu monoliticu) puderanu chjamà l'altri per arricchisce i so dati.
Cù e classi di mudelli stessi chì almacenanu dati, u travagliu in u codice hè stata fatta in modu diversu. In qualchì locu ci era custruttori attraversu quale era pussibule di specificà i campi necessarii. In qualchì locu hè statu fattu per mezu di pruprietà publiche. Di sicuru, ottene è trasfurmà e dati da a basa di dati era variatu.
A logica era o in i cuntrolli o in e classi di serviziu.
Quessi parevanu prublemi minori, ma rallentavanu assai u sviluppu è a qualità ridutta, purtendu à inestabilità è bug.
A cumplessità di un grande sviluppu
Difficultà sò sviluppati in u sviluppu stessu. Era necessariu di fà diverse blocchi di u sistema, è in parallelu. Aduprà i bisogni di ogni cumpunente in un codice unicu hè diventatu sempre più difficiule. Ùn era micca faciule d'accordu è piacè tutti i cumpunenti à u stessu tempu. Aghjunghjite à questu limitazioni in a tecnulugia, in particulare in quantu à a basa è u frontend. Era necessariu di abbandunà JQuery versu i quadri d'altu livellu, soprattuttu in quantu à i servizii di u cliente (situ web).
In certi parti di u sistema, i basa di dati più adattati per questu puderia esse usatu.. Per esempiu, dopu avemu avutu u casu d'usu di trasfurmà da Redis à CosmosDB per almacenà una cesta d'ordine.
I squadre è i sviluppatori implicati in u so campu vulianu chjaramente più autonomia per i so servizii, sia in termini di sviluppu sia di rollout. Unisce i cunflitti, liberate prublemi. Se per i sviluppatori 5 stu prublema hè insignificante, allora cù 10, è ancu più cù a crescita pianificata, tuttu diventerà più seriu. È davanti à esse u sviluppu di una applicazione mobile (hè cuminciatu in 2017, è in 2018 hè stata ).
E diverse parti di u sistema necessitanu diversi livelli di stabilità, ma per via di a forte cunnessione di u sistema, ùn pudemu micca furnisce questu. Un errore in u sviluppu di una nova funzione in u pannellu admin puderia esse fattu in l'accettazione di un ordine in u situ, perchè u codice hè cumunu è reutilizable, a basa di dati è e dati sò ancu listessi.
Puderia esse pussibule di evitari questi sbagli è prublemi in u quadru di una tale architettura monolitica-modulare: fà una divisione di rispunsabilità, refactor sia u codice è a basa di dati, separà chjaramente i strati l'una di l'altru, seguite a qualità ogni ghjornu. Ma e suluzioni architettoniche scelte è u focu annantu à a rapida espansione di e funziunalità di u sistema hà purtatu à prublemi in termini di stabilità.
Cumu u blog Power of the Mind mette i cash registers in i ristoranti
Se a crescita di a reta di pizzeria (è a carica) cuntinuò à u listessu ritmu, dopu un pocu tempu, i cascate seranu tali chì u sistema ùn risurrezzione. Ben illustra i prublemi chì avemu cuminciatu à affruntà da 2015, quì hè una tale storia.
In u blog ""era un widget chì mostrava dati nantu à i rivenuti per l'annu di tutta a reta. U widget accede à l'API publica Dodo, chì furnisce questi dati. Sta statistica hè attualmente dispunibule à . U widget hè statu mostratu in ogni pagina è hà fattu richieste nantu à un cronometru ogni 20 seconde. A dumanda hè andata à api.dodopizza.ru è hà dumandatu:
-
u numeru di pizzeria in a reta;
-
Ingressu tutale di a rete da u principiu di l'annu;
-
entrate per oghje.
A dumanda di statistiche nantu à i rivenuti andò direttamente à a basa di dati è cuminciò à dumandà dati nantu à l'ordine, aggregating data on the fly è dà a quantità.
I cash desks in i ristoranti sò andati à a listessa tavola di ordini, scaricatu una lista di ordini ricevuti per oghje, è novi ordini sò stati aghjuntu. I cash registers anu fattu e so dumande ogni 5 seconde o in a pagina di rinfrescante.
U diagramma pareva cusì:
Una caduta, Fyodor Ovchinnikov hà scrittu un articulu longu è populari nantu à u so blog. Assai genti ghjunsenu à u blog è cuminciaru à leghje tuttu cù cura. Mentre chì ognuna di e persone chì venenu stava leghjendu l'articulu, u widget di entrate hà travagliatu bè è dumandava l'API ogni 20 seconde.
L'API hà chjamatu una prucedura almacenata per calculà a summa di tutti l'ordine da u principiu di l'annu per tutte e pizzeria in a catena. L'agregazione hè stata basatu annantu à a tavola di ordini, chì hè assai populari. Tutti i cash desks di tutti i ristoranti aperti à quellu tempu vanu à questu. I cash desks anu cessatu di risponde, ordini ùn sò micca accettati. Ùn sò micca stati ancu accettati da u situ, ùn anu micca apparsu nantu à u tracker, u shift manager ùn pudia micca vede in a so interfaccia.
Questa ùn hè micca a sola storia. À a caduta di u 2015, ogni vennari a carica nantu à u sistema era critica. Parechje volte avemu disattivatu l'API publicu, è una volta, avemu avutu ancu di disattivà u situ, perchè nunda hà aiutatu. Ci era ancu una lista di servizii cù un ordine di chjusu sottu carichi pesanti.
Da avà, a nostra lotta cù carichi è per a stabilizazione di u sistema principia (da u vaghjimu 2015 à u vaghjimu 2018). Hè quandu hè accadutu "". Inoltre, i fallimenti sò ancu accaduti à volte, alcuni eranu assai sensibili, ma u periodu generale di inestabilità pò esse cunsideratu passatu.
Rapidu crescita di l'affari
Perchè ùn si pudia fà subitu ? Basta à guardà i seguenti charts.
Ancu in 2014-2015 ci hè stata una apertura in Romania è una apertura in i Stati Uniti hè stata preparata.
A reta hè crisciutu assai rapidamente, i novi paesi sò stati aperti, i novi furmati di pizzeria apparsu, per esempiu, una pizzeria hè stata aperta à a corte di l'alimentariu. Tuttu chistu necessitava una attenzione significativa specificamente à l'espansione di e funzioni Dodo IS. Senza tutte queste funzioni, senza seguitu in a cucina, cuntabili per i prudutti è perditi in u sistema, affissendu l'emissione di un ordine in a sala di a sala di l'alimentariu, ùn sariamu micca parlatu di l'architettura "corretta" è di l'approcciu "correttu" per sviluppu avà.
Un altru ostaculu à a rivisione puntuale di l'architettura è in generale l'attenzione à i prublemi tecnichi era a crisa di u 2014. Cose cum'è questu colpi duramente in l'opportunità per e squadre di cresce, in particulare per una ghjovana impresa cum'è Dodo Pizza.
Soluzioni veloci chì aiutanu
I prublemi necessitanu suluzione. Cunvinziunali, suluzione pò esse divisu in 2 gruppi:
-
Quelli veloci chì spegnenu u focu è dà un picculu margine di salvezza è ci compranu tempu per cambià.
-
Sistemicu è, dunque, longu. Reengineering di una quantità di moduli, divisione di una architettura monolitica in servizii separati (a maiò parte di elli ùn sò micca à tutti i micro, ma piuttostu macro servizii, è ci hè qualcosa nantu à questu. ).
A lista secca di cambiamenti rapidi hè a siguenti:
Scale u maestru di basa
Di sicuru, a prima cosa chì hè fatta per trattà cù carichi hè di aumentà a capacità di u servitore. Questu hè statu fattu per a basa di dati maestru è per i servitori web. Alas, questu hè pussibule solu finu à un certu limitu, allora diventa troppu caru.
Dapoi u 2014, avemu trasfirutu à Azure, avemu ancu scrittu annantu à questu tema à quellu tempu in l'articulu "". Ma dopu à una seria di aumenti in u servitore per a basa, sò ghjunti contru à u costu.
Repliche di basa per a lettura
Dui repliche sò state fatte per a basa:
ReadReplica per richieste di riferimentu. Hè adupratu per leghje cartulari, tipu, cità, strada, pizzeria, prudutti (domaine cambiatu lentamente), è in quelli interfacce induve un picculu ritardu hè accettatu. Ci era 2 di sti repliche, avemu assicuratu a so dispunibilità in u listessu modu cum'è i maestri.
ReadReplica per e richieste di rapportu. Questa basa di dati avia una dispunibilità più bassa, ma tutti i rapporti sò andati à questu. Lasciate avè richieste pesanti per ricalculazioni di dati enormi, ma ùn anu micca affettatu a basa di dati principale è l'interfacce operative.
Cache in codice
Ùn ci era micca cache in ogni locu in u codice (in tuttu). Questu hà purtatu à richieste supplementari, micca sempre necessarie, à a basa di dati caricata. I cache eranu prima in memoria è in un serviziu di cache esternu, chì era Redis. Tuttu era invalidatu da u tempu, i paràmetri sò stati specificati in u codice.
Servitori di backend multipli
U backend di l'applicazione hà ancu bisognu à esse scalatu per trattà i carichi di travagliu aumentati. Era necessariu di fà un cluster da un iis-server. Avemu riprogrammatu da a memoria à RedisCache, chì hà permessu di fà parechji servitori daretu à un balancer di carica simplice cù round robin. À u principiu, u listessu Redis hè stata utilizata cum'è per i caches, dopu hè stata divisa in parechji.
In u risultatu, l'architettura hè diventata più cumplicata ...
... ma una parte di a tensione hè stata eliminata.
È tandu era necessariu di ripiglià i cumpunenti caricati, chì avemu fattu. Avemu da parlà di questu in a prossima parte.
Source: www.habr.com