Habr cambia u mondu. Avemu blogging per più di un annu avà. Circa sei mesi fà, avemu ricevutu un feedback cumpletamente logicu da Khabrovites: "Dodo, dite in ogni locu chì avete u vostru propiu sistema. E chì hè stu sistema? E perchè una catena di pizza ne hà bisognu?
Avemu pusatu, pensatu è capitu chì avete ragione. Pruvemu di spiegà tuttu nantu à i nostri ditte, ma esce in pezzi strappati è ùn ci hè micca una descrizzione cumpleta di u sistema. Cusì hà iniziatu un longu viaghju di cullizzioni d'infurmazioni, di ricerca di l'autori è di scrive una seria d'articuli nantu à Dodo IS. Andemu!
Riconoscimenti: Grazie per sparte i vostri feedback cun noi. Grazie à ellu, avemu finalmente descrittu u sistema, compilatu un radar tecnicu è prestu prestu una grande descrizzione di i nostri prucessi. Senza di voi, avariamu stati seduti quì per altri 5 anni.
Serie di articuli "Chì hè Dodo IS?" parla di:
- Primu monolitu in Dodo IS (2011-2015). (In corsu...)
- U percorsu di u back office: basi è autobus separati. (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...)
Sè site interessatu à sapè qualcosa altru - scrivite in i cumenti.
Opinione nantu à a descrizzione cronologica da l'autore
Aghju regularmente una riunione per i novi impiegati nantu à u tema "Architettura di u Sistema". Chjamemu "Intro à Dodo IS Architecture" è face parte di u prucessu di imbarcazione per i novi sviluppatori. Dicendu in una forma o l'altru di a nostra architettura, di e so caratteristiche, aghju natu un certu approcciu storicu à a descrizzione.
Tradizionalmente, guardemu à u sistema cum'è un inseme di cumpunenti (tecnicu o di livellu più altu), moduli di cummerciale chì interagiscenu cù l'altri per ottene qualchì scopu. E se una tale vista hè ghjustificata per u disignu, allora ùn hè micca abbastanza adattatu per a descrizzione è l'intelligenza. Ci sò parechje ragioni quì:
- A realità hè diversa da ciò chì hè nantu à a carta. Micca tuttu funziona cum'è previstu. È simu interessate in quantu hè veramente fattu è funziona.
- Presentazione consistente di l'infurmazioni. In fatti, pudete andà in cronologia da u principiu à u statu attuale.
- Da simplice à cumplessu. Micca universale, ma in u nostru casu hè. L'architettura si trasfirìu da approcci più simplici à più cumplessi. Spessu per via di a cumplicazione, i prublemi di rapidità è stabilità di implementazione sò stati risolti, è ancu decine d'altri pruprietà da a lista di esigenze non-funzionali ( ben dettu di cuntrastà a cumplessità cù altre esigenze).
In u 2011, l'architettura Dodo IS pareva cusì:
Da 2020, hè diventatu un pocu più cumplicatu è hè diventatu cusì:
Cumu hè stata sta evoluzione ? Perchè sò necessarie diverse parti di u sistema? Chì decisioni architettoniche sò state prese è perchè? Scupritemu in questa serie di articuli.
I primi prublemi di 2016: perchè i servizii abbandunonu u monolitu
I primi articuli da u ciculu seranu nantu à i servizii chì eranu i primi à separà da u monolitu. Per mette in u cuntestu, vi dicu chì prublemi avemu avutu in u sistema à u principiu di u 2016, chì avemu avutu à trattà cù a separazione di servizii.
Una sola basa di dati MySql, in quale tutte l'applicazioni chì esistevanu à quellu tempu in Dodo IS hà scrittu i so registri. E cunsequenze eranu:
- Carica pesante (cù u 85% di e dumande cuntate per a lettura).
- A basa hè crisciutu. Per via di questu, u so costu è u sustegnu hè diventatu un prublema.
- Unicu puntu di fallimentu. Se una applicazione chì scrive à a basa di dati accuminciau di colpu à fà più attivamente, allora l'altri appricazzioni si sentenu nantu à elli stessi.
- Inefficienza in u almacenamentu è e dumande. Spessu i dati sò stati guardati in una struttura chì era cunvene per certi scenarii, ma micca adattatu per altri. L'indici acceleranu alcune operazioni, ma ponu rallentà l'altri.
- Certi di i prublemi sò stati sguassati da cache in fretta è leghje-repliche à e basi (questu serà un articulu separatu), ma solu permettenu di guadagnà u tempu è ùn anu micca risolve u prublema fundamentale.
U prublema era a prisenza di u monolitu stessu. I cunsiquenzi eranu:
- Edizioni uniche è rare.
- Difficultà in u sviluppu cumuni di un gran numaru di persone.
- Incapacità di purtà novi tecnulugii, novi quadri è biblioteche.
I prublemi cù a basa è u monolitu sò stati descritti parechje volte, per esempiu, in u cuntestu di crashes in principiu di 2018 (, и ), cusì ùn aghju micca troppu. Lasciami dì solu chì vulemu dà più flessibilità in u sviluppu di servizii. Prima di tuttu, questu cuncernava quelli chì eranu i più carichi è root in tuttu u sistema - Auth and Tracker.
U Back Office Path: Basi separati è Bus
Navigazione di u capitulu
Schema monolitu 2016
Eccu i blocchi principali di u monolitu Dodo IS 2016, è ghjustu sottu hè una trascrizione di e so funzioni principali.
Consegna cassiera. Contabilità per i corrieri, emette ordini à i corrieri.
Centru di cuntattu. Accettazione di ordini attraversu l'operatore.
di u situ. I nostri siti web (dodopizza.ru, dodopizza.co.uk, dodopizza.by, etc.).
Aut. U serviziu d'autorizazione è autentificazione per u back office.
tracker. Tracker d'ordine in cucina. Serviziu per marcà i stati di prontezza quandu preparanu un ordine.
Cash desk di u Restaurant. Piglià ordini in un ristorante, interfaccia di cassiere.
Esporta. Caricà rapporti in 1C per a cuntabilità.
Notifiche è fatture. Cumandamenti di voce in cucina (per esempiu, "A nova pizza hè ghjunta") + stampa di fattura per i corrieri.
Manager di turnu. Interfacce per u travagliu di u shift manager: lista di ordini, grafici di rendiment, trasferimentu di l'impiegati à u turnu.
Manager di l'uffiziu. Interfacce per u travagliu di u franchisee è u manager: ricezione di l'impiegati, rapporti nantu à u travagliu di a pizzeria.
Tabellone di u ristorante. Visualizzazione di menu in TV in pizzeria.
amministratore. Paràmetri in una pizzeria specifica: menu, prezzi, contabilità, codici promo, prumuzioni, banners di u situ web, etc.
Cuntu persunale di l'impiegatu. Programmi di travagliu di l'impiegati, infurmazione nantu à i travagliati.
Cunsigliu di motivazione di a cucina. Un schermu separatu chì pende in a cucina è mostra a velocità di i pizzaioli.
Communication. Mandendu sms è email.
File Storage. Serviziu propiu per riceve è emette file statici.
I primi tentativi di risolve i prublemi ci anu aiutatu, ma eranu solu un tempurale. Ùn sò micca diventati suluzioni di u sistema, cusì era chjaru chì qualcosa deve esse fattu cù e basi. Per esempiu, per dividisce a basa di dati generale in parechje più specializate.
Accuminciamu à Scaricatu u Monolitu: Separazione di l'Auth and Tracker
I servizii principali chì dopu arregistratu è leghje da a basa di dati più cà l'altri:
- Auth. U serviziu d'autorizazione è autentificazione per u back office.
- Tracker. Tracker d'ordine in cucina. Serviziu per marcà i stati di prontezza quandu preparanu un ordine.
Chì face Auth?
Auth hè un serviziu per mezu di quale l'utilizatori accede à u back office (ci hè una entrata indipendente separata da u cliente). Hè ancu chjamatu in a dumanda per assicurà chì i diritti d'accessu necessarii sò prisenti è chì questi diritti ùn anu micca cambiatu da l'ultimu login. À traversu, i dispositi entranu in a pizzeria.
Per esempiu, vulemu apre una mostra cù i stati di ordini finiti nantu à a TV appesa in a sala. Dopu avemu apertu auth.dodopizza.ru, selezziunà "Login cum'è un dispositivu", appare un codice chì pò esse inseritu in una pagina speciale in l'urdinatore di u shift manager, indicà u tipu di dispusitivu (dispositivu). A TV stessu hà da passà à l'interfaccia desiderata di a so pizzeria è cumincianu à vede i nomi di i clienti chì l'ordine sò pronti.
Da induve sò i carichi?
Ogni utilizatore registratu di u back office va à a basa di dati, à a tavola di l'utilizatori per ogni dumanda, tira l'utilizatore per una dumanda sql è verifica s'ellu hà l'accessu è i diritti necessarii à sta pagina.
Ognunu di i dispusitivi faci u listessu solu cù a tavola di u dispusitivu, cuntrollà u so rolu è u so accessu. Un gran numaru di dumande à a basa di dati maestru porta à a so carica è u perdu di risorse di a basa di dati cumuni per queste operazioni.
Scaricamentu Auth
Auth hà un duminiu isolatu, vale à dì, dati nantu à l'utilizatori, logins o dispositi entra in u serviziu (per u mumentu) è ferma quì. Sè qualchissia hà bisognu di elli, allora andarà à stu serviziu per i dati.
ERA. U schema uriginale di u travagliu era cusì:
Vogliu spiegà un pocu cumu hà travagliatu:
- Una dumanda da l'esternu vene à u backend (ci hè Asp.Net MVC), porta cun ellu una cookie di sessione, chì hè utilizata per uttene dati di sessione da Redis (1). Hè o cuntene infurmazioni nantu à l'accessi, è dopu l'accessu à u controller hè apertu (3,4), o micca.
- Se ùn ci hè micca accessu, avete bisognu di passà per a prucedura d'autorizazione. Quì, per simplicità, hè mostratu cum'è parte di a strada in u stessu attributu, ancu s'ellu hè una transizione à a pagina di login. In u casu di un scenariu pusitivu, averemu una sessione cumpleta currettamente è andemu à u Backoffice Controller.
- Se ci sò dati, allora avete bisognu di verificà per a pertinenza in a basa di l'utilizatori. Hè cambiatu u so rolu, ùn deve micca esse permessu in a pagina avà? In questu casu, dopu avè ricivutu a sessione (1), avete bisognu di andà direttamente à a basa di dati è verificate l'accessu di l'utilizatori cù a strata di logica di autentificazione (2). Dopu, sia à a pagina di login, o andate à u controller. Un sistema cusì simplice, ma micca abbastanza standard.
- Se tutte e prucedure sò passate, allora saltamu più in a logica in i cuntrolli è i metudi.
I dati di l'utilizatori sò separati da tutti l'altri dati, sò almacenati in una tabella di appartenenza separata, e funzioni da a capa logica AuthService pò esse diventate metudi api. I limiti di u duminiu sò definiti abbastanza chjaramente: l'utilizatori, i so roli, i dati d'accessu, cuncede è revoca l'accessu. Tuttu pare cusì ch'ellu pò esse pigliatu in un serviziu separatu.
DIVENTA. Allora anu fattu:
Stu approcciu hà una quantità di prublemi. Per esempiu, chjamà un metudu in un prucessu ùn hè micca listessu chì chjamà un serviziu esternu via http. Latenza, affidabilità, mantenimentu, trasparenza di l'operazione sò completamente diffirenti. Andrey Morevskiy hà parlatu in più dettagliu di tali prublemi in u so rapportu. .
U serviziu di autentificazione è, cun ellu, u serviziu di u dispositivu sò usati per u back office, vale à dì per i servizii è l'interfacce utilizati in a produzzione. L'autentificazione per i servizii di u cliente (cum'è un situ web o una applicazione mobile) si trova separatamente senza aduprà Auth. A siparazione hà pigliatu circa un annu, è avà avemu trattatu di novu cù questu tema, trasferendu u sistema à novi servizii di autentificazione (cù protokolli standard).
Perchè a separazione hà pigliatu tantu tempu?
Ci era parechje prublemi in a strada chì ci rallentavanu:
- Vulemu spustà l'utilizatori, i dispositi è i dati di autentificazione da basa di dati specifichi di u paese in una sola. Per fà questu, avemu avutu a traduzzione di tutte e tavule è l'usu da l'identificatore int à l'identificatore UUId glubale (ricerca rielaboratu stu codice è prughjettu open source ). L'almacenamiento di dati d'utilizatori (perchè hè infurmazione persunale) hà e so limitazioni è per certi paesi hè necessariu di guardà separatamente. Ma l'ID globale di l'utilizatore deve esse.
- Parechje tavule in a basa di dati anu infurmazione di auditu nantu à l'utilizatore chì hà realizatu l'operazione. Questu hà bisognu di un mecanismu supplementu per a coerenza.
- Dopu à a creazione di api-services, ci hè statu un periodu longu è graduale di transizione à un altru sistema. U cambiamentu duvia esse senza soluzione per l'utilizatori è hà bisognu di travagliu manuale.
Schema di registrazione di u dispositivu in una pizzeria:
Architettura generale dopu l'estrazione di u serviziu Auth and Devices:
Vita. Per u 2020, avemu travagliatu nantu à una nova versione di Auth, chì hè basatu annantu à u standard d'autorizazione OAuth 2.0. Stu standard hè abbastanza cumplessu, ma hè utile per sviluppà un serviziu di autentificazione pass-through. In l'articulu "» Noi Alexey Chernyaev hà pruvatu à parlà di u standard u più simplice è chjaramente pussibule per risparmià u tempu di studià.
Cosa faci Tracker?
Avà circa u sicondu di i servizii caricati. U tracker svolge un rolu duplice:
- Da una banda, u so compitu hè di mustrà à l'impiegati in a cucina ciò chì l'ordine sò attualmente in travagliu, chì prudutti deve esse cotti avà.
- Per d 'altra banda, per digitalizà tutti i prucessi in a cucina.
Quandu un novu pruduttu appare in un ordine (per esempiu, pizza), si va à a stazione di tracker Rolling out. In questa stazione, ci hè un pizzaiolo chì piglia un pane di a dimensione necessaria è u stende, dopu chì nota nantu à a tavuletta di tracker chì hà finitu u so compitu è trasferisce a basa di pasta rotulata à a prossima stazione - "Iniziazione". .
Quì, u prossimu pizzaiolo riempie a pizza, poi nota nantu à a tavuletta chì hà finitu u so compitu è mette a pizza in u fornu (questu hè ancu una stazione separata chì deve esse nutata nantu à a tavuletta). Un tali sistema era da u principiu in Dodo è da u principiu di l'esistenza di Dodo IS. Permette di seguità cumplettamente è digitalizà tutte e transazzione. Inoltre, u tracker suggerisce cumu si coce un pruduttu particulari, guida ogni tipu di pruduttu secondu i so schemi di fabricazione, guarda u tempu di coccia ottima per u pruduttu, è traccia tutte l'operazioni nantu à u pruduttu.
Hè cusì chì u screnu di a tableta pare à a stazione di u tracker "Raskatka"
Da induve sò i carichi?
Ogni pizzeria hà circa cinque pasticchi cù un tracker. In u 2016, avemu avutu più di 100 pizzeria (è avà più di 600). Ciascuna di e pasticchi fa una dumanda à u backend una volta ogni 10 seconde è scrapes data da a tavola di l'ordine (cunnessu cù u cliente è l'indirizzu), a cumpusizioni di l'ordine (cunnessione cù u pruduttu è l'indicazione di a quantità), a tavola di cuntabilità di motivazione (u u tempu di pressa hè tracciatu in questu). Quandu una pizzeria cliccà nantu à un pruduttu nantu à u tracker, l'entrata in tutti sti tavulini sò aghjurnati. A tavula di l'ordine hè generale, cuntene ancu inseriti quandu accetta un ordine, aghjurnamenti da altre parte di u sistema è numerosi letture, per esempiu, in una TV chì si ferma in una pizzeria è mostra l'ordine finitu à i clienti.
Duranti u periodu di lotta cù carichi, quandu tuttu è tuttu era cache è trasferitu à a replica asincrona di a basa, queste operazioni cù u tracker cuntinuavanu à andà à a basa maestru. Ùn ci deve esse alcunu lag, i dati deve esse up-to-date, fora di sincronia hè inacceptable.
Inoltre, a mancanza di propri tabelle è indici nantu à elli ùn permettenu micca di scrive dumande più specifiche adattate per u so usu. Per esempiu, puderia esse efficace per un tracker per avè un indice per una pizzeria nantu à una tavola di ordine. Sempre eliminemu l'ordine di pizzeria da a basa di dati di tracker. À u listessu tempu, per riceve un ordine, ùn hè micca cusì impurtante in quale pizzeria cade, hè più impurtante chì cliente hà fattu questu ordine. È significa chì l'indici nantu à u cliente hè necessariu. Ùn hè ancu necessariu per u tracker per almacenà l'id di u ricivutu stampatu o promozioni bonus associate à l'ordine in a tavola di l'ordine. Questa infurmazione ùn hè micca d'interessu per u nostru serviziu di tracker. In una basa di dati monolitica cumuni, i tavulini puderanu esse solu un cumprumissu trà tutti l'utilizatori. Questu era unu di i prublemi originali.
ERA. L'architettura originale era:
Ancu dopu esse siparati in prucessi separati, a maiò parte di a basa di codice hè stata cumuna per diversi servizii. Tuttu sottu à i cuntrolli era unicu è campava in u stessu repository. Avemu usatu metudi cumuni di servizii, repository, una basa cumuna, in quale si trovanu tavule cumuni.
Scaricamentu Tracker
U prublema principali cù u tracker hè chì i dati devenu esse sincronizati trà e diverse basa di dati. Questu hè ancu a so diferenza principale da a siparazione di u serviziu Auth, l'ordine è u so status pò cambià è deve esse affissatu in diversi servizii.
Accettamu un ordine à u Checkout di u Restaurant (questu hè un serviziu), hè guardatu in a basa di dati in u statu "Accettatu". Dopu quì, deve ghjunghje à u tracker, induve ellu hà da cambià u so status parechje volte più: da "Cucina" à "Packed". À u listessu tempu, alcune influenze esterne da u Cashier o l'interfaccia di Shift Manager ponu accade cù l'ordine. Daraghju i stati di l'ordine cù a so descrizzione in a tavola:
U schema per cambià u statu di l'ordine hè cusì:
I statuti cambianu trà i diversi sistemi. E quì u tracker ùn hè micca un sistema finali in quale i dati sò chjusi. Avemu vistu parechji approcci pussibuli per a particione in un tali casu:
- Concentremu tutte l'azzioni di ordine in un serviziu. In u nostru casu, sta opzione richiede troppu serviziu per travaglià cù l'ordine. S'ellu ci fermamu, avemu da ottene u sicondu monolitu. Ùn avemu micca risolve u prublema.
- Un sistema face una chjama à un altru. A seconda opzione hè digià più interessante. Ma cun ella, catene di chjama sò pussibuli (), a cunnessione di i cumpunenti hè più altu, hè più difficiule di gestisce.
- Organizemu avvenimenti, è ogni serviziu cumunicà cù l'altru attraversu questi avvenimenti. In u risultatu, era a terza opzione chì hè stata scelta, secondu chì tutti i servizii cumincianu à scambià avvenimenti cù l'altri.
U fattu chì avemu sceltu a terza opzione significava chì u tracker avarà a so propria basa di dati, è per ogni cambiamentu di l'ordine, mandava un avvenimentu annantu à questu, à quale altri servizii abbonate è chì cade ancu in a basa di dati maestru. Per fà questu, avemu bisognu di qualchì serviziu chì assicurassi a spedizione di missaghji trà servizii.
À quellu tempu, avemu digià avutu RabbitMQ in a pila, da quì a decisione finale di usà cum'è broker di messagi. U diagramma mostra a transizione di un ordine da u Restaurant Cashier à traversu u Tracker, induve cambia u so statutu è a so visualizazione nantu à l'interfaccia di l'Ordini di u Manager. DIVENTA:
Ordine strada passu à passu
U percorsu di l'ordine principia à unu di i servizii d'origine di l'ordine. Eccu u Cassiere di u Restaurant:
- À u checkout, l'ordine hè cumplettamente prontu, è hè ora di mandà à u tracker. L'avvenimentu à quale u tracker hè abbonatu hè ghjittatu.
- U tracker, accettendu un ordine per ellu stessu, u salva in a so propria basa di dati, facendu l'avvenimentu "Ordine Acceptatu da u Tracker" è mandendu à RMQ.
- Ci sò parechji gestori digià abbonati à l'autobus di l'eventi per ordine. Per noi, quellu chì faci a sincronizazione cù una basa monolitica hè impurtante.
- U gestore riceve un avvenimentu, selezziunate da ellu dati chì hè significativu per ellu: in u nostru casu, questu hè u statutu di l'ordine "Accettatu da u Tracker" è aghjurnà a so entità di ordine in a basa di dati principale.
Se qualchissia hà bisognu di un ordine da l'ordini di a tavola monolitica, pudete leghje ancu da quì. Per esempiu, l'interfaccia Ordini in u Shift Manager hà bisognu di questu:
Tutti l'altri servizii ponu ancu abbunà per ordini avvenimenti da u tracker per aduprà per elli.
Se dopu un pocu tempu l'ordine hè pigliatu in u travagliu, u so status cambia prima in a so basa di dati (base di dati Tracker), è dopu l'avvenimentu "OrderIn Progress" hè subitu generatu. Entra ancu in RMQ, da induve hè sincronizatu in una basa di dati monolitica è furnita à altri servizii. Ci ponu esse parechji prublemi in u caminu, più dettagli nantu à elli ponu esse truvati in u rapportu di Zhenya Peshkov .
Architettura finale dopu cambiamenti in Auth and Tracker
Riassuntu u risultatu intermediu: In principiu, aghju avutu l'idea di imballà a storia di nove anni di u sistema Dodo IS in un articulu. Vuliu parlà rapidamente è solu di e tappe di l'evoluzione. In ogni casu, pusendu per u materiale, aghju realizatu chì tuttu hè assai più complicatu è interessante di ciò chì pare.
Riflettendu nantu à i benefizii (o a mancanza di questu) di tali materiale, aghju ghjuntu à a cunclusione chì u sviluppu cuntinuu hè impussibile senza annali cumpletu di avvenimenti, retrospettivi detallati è analisi di e mo decisione passate.
Spergu chì hè stata utile è interessante per voi per amparà nantu à a nostra strada. Avà sò affruntatu à una scelta chì parte di u sistema Dodo IS per discrive in u prossimu articulu: scrivite in i cumenti o votu.
Solu l'utilizatori registrati ponu participà à l'indagine. , per piacè.
Chì parte di Dodo IS vulete sapè in u prossimu articulu ?
-
24,1%Primu monolitu in Dodo IS (2011-2015)14
-
24,1%Primi prublemi è e so suluzione (2015-2016)14
-
20,7%U percorsu di u cliente: facciata sopra a basa (2016-2017)12
-
36,2%A storia di i veri microservizi (2018-2019)21
-
44,8%Sega cumpleta di u monolitu è stabilizazione di l'architettura26
-
29,3%Circa più piani per u sviluppu di u sistema17
-
19,0%Ùn vogliu micca sapè nunda di Dodo IS11
58 utilizatori anu vutatu. 6 utilizatori si sò astenuti.
Source: www.habr.com