Istorija Dodo IS arhitekture: Put u pozadinu

Habr mijenja svijet. Blogiramo više od godinu dana. Prije otprilike šest mjeseci dobili smo sasvim logičnu povratnu informaciju od stanovnika Khabrovska: „Dodo, svuda govoriš da imaš svoj sistem. Kakav je ovo sistem? A zašto je to potrebno lancu picerija?”

Sedeli smo i razmišljali i shvatili da ste u pravu. Pokušavamo sve da objasnimo prstima, ali izlazi u pocepanim komadima i nigde nema punog opisa sistema. Tako je započeo dug put prikupljanja informacija, traženja autora i pisanja serije članaka o Dodo IS. Idemo!

Priznanja: Hvala vam što ste podijelili svoje povratne informacije s nama. Zahvaljujući njemu, konačno smo opisali sistem, sastavili tehnoradar i uskoro ćemo izbaciti veliki opis naših procesa. Bez vas bismo sedeli ovako još 5 godina.

Serija članaka "Šta je Dodo IS?" govori o:

1. Rani monolit u Dodo IS (2011-2015). (U toku...)
2. Backoffice put: odvojene baze i autobus. (Ti si ovdje)
3. Putanja na strani klijenta: fasada preko baze (2016-2017). (U toku...)
4. Istorija pravih mikroservisa. (2018-2019). (U toku...)
5. Završeno piljenje monolita i stabilizacija arhitekture. (U toku...)

Ako vas zanima nešto drugo, pišite u komentarima.

Mišljenje autora o hronološkom opisu
Redovno održavam sastanke za novozaposlene na temu „Arhitektura sistema“. Mi to zovemo “Uvod u Dodo IS arhitekturu” i dio je procesa ugradnje novih programera. Govoreći u ovom ili onom obliku o našoj arhitekturi, o njenim karakteristikama, razvio sam određeni istorijski pristup opisu.

Tradicionalno, na sistem gledamo kao na skup komponenti (tehničkih ili višeg nivoa), poslovnih modula koji međusobno komuniciraju kako bi postigli neki cilj. I dok je takav pogled opravdan za dizajn, nije u potpunosti pogodan za opis i razumijevanje. Postoji nekoliko razloga:

• Stvarnost je drugačija od onoga što je na papiru. Ne ide sve kako je planirano. I zanima nas kako je sve zapravo ispalo i funkcionira.
• Dosljedno predstavljanje informacija. U stvari, možete ići hronološki od početka do trenutnog stanja.
• Od jednostavnog do složenog. Nije univerzalno, ali u našem slučaju je tako. Arhitektura je prešla sa jednostavnijih pristupa na složenije. Često se, kroz komplikacije, javljaju problemi brzine i stabilnosti implementacije, kao i desetine drugih svojstava sa liste nefunkcionalnih zahtjeva (ovdje dobro se govorilo o kontrastu složenosti s drugim zahtjevima).

Godine 2011. Dodo IS arhitektura je izgledala ovako:

Do 2020. je postalo malo komplikovanije i postalo je ovako:

Kako je došlo do ove evolucije? Zašto su potrebni različiti dijelovi sistema? Koje su arhitektonske odluke donesene i zašto? Hajde da saznamo u ovoj seriji članaka.

Prvi problemi 2016: zašto bi službe napustile monolit?

Prvi članci u serijalu bit će o servisima koji su se prvi odvojili od monolita. Da vas stavim u kontekst, reći ću vam kakve smo probleme imali u sistemu početkom 2016. godine, da smo morali da se bavimo razdvajanjem usluga.

Jedinstvena MySql baza podataka u koju su sve aplikacije koje su postojale u to vrijeme u Dodo IS-u upisivale svoje zapise. Posljedice su bile:

• Veliko opterećenje (sa 85% pročitanih zahtjeva).
• Baza je rasla. Zbog toga su troškovi i podrška postali problem.
• Jedna tačka kvara. Ako je jedna aplikacija koja piše u bazu podataka odjednom počela da to čini aktivnije, onda su druge aplikacije osjetile utjecaj.
• Neefikasnost skladištenja i upita. Često su podaci bili pohranjeni u nekoj strukturi koja je bila zgodna za neke scenarije, ali ne i za druge. Indeksi ubrzavaju neke operacije, ali mogu usporiti druge.
• Neki od problema riješeni su na brzinu napravljenim kešovima i replikama za čitanje baza podataka (o tome će biti riječi u posebnom članku), ali su nam samo omogućili da dobijemo na vremenu i nisu suštinski riješili problem.

Problem je bilo prisustvo samog monolita. Posljedice su bile:

• Jedinstvena i rijetka izdanja.
• Teškoća je u zajedničkom razvoju velikog broja ljudi.
• Nemogućnost uvođenja novih tehnologija, novih okvira i biblioteka.

Problemi sa bazom i monolitom opisani su mnogo puta, na primjer, u kontekstu padova početkom 2018.Budite kao Munch, ili nekoliko riječi o tehničkom dugu, Dan kada je Dodo IS stao. Asinhrona skripta и Priča o ptici Dodo iz porodice Feniks. Veliki pad Dodo IS), tako da se neću previše zadržavati. Dozvolite mi samo da kažem da smo željeli dati veću fleksibilnost pri razvoju usluga. Prije svega, to se ticalo onih koji su bili najviše opterećeni i root u cijelom sistemu - Auth i Tracker.

Putanja pozadinske kancelarije: odvojene baze i sabirnica

Poglavlje Navigacija

1. Šema monolita 2016
2. Počinjemo da rasterećujemo monolit: razdvajanje Auth-a i Tracker-a
   
3. Šta radi Auth?
4. Odakle dolaze opterećenja?
5. Unloading Auth
6. Šta Tracker radi?
7. Odakle dolaze opterećenja?
8. Istovar Tracker

Šema monolita 2016

Evo glavnih blokova Dodo IS monolita iz 2016., a odmah ispod je pregled njihovih glavnih zadataka.

Blagajna za dostavu. Računovodstvo kurira, izdavanje naloga kuririma.
Kontakt centar. Prihvatanje narudžbi preko operatera.
site. Naše web stranice (dodopizza.ru, dodopizza.co.uk, dodopizza.by, itd.).
Auth. Usluga autorizacije i autentifikacije za backoffice.
Tracker. Praćenje narudžbi u kuhinji. Usluga označavanja statusa spremnosti prilikom pripreme narudžbe.
Blagajna restorana. Primanje narudžbi u restoranu, sučelja blagajne.
izvoz. Prijenos izvještaja u 1C za računovodstvo.
Upozorenja i fakture. Glasovne komande u kuhinji (na primjer, “Nova pica je stigla”) + štampanje računa za kurire.
Shift Manager. Interfejsi za rad voditelja smjena: lista narudžbi, grafikoni produktivnosti, dovođenje radnika u smjene.
Office Manager. Interfejsi za rad primaoca franšize i menadžera: prijem zaposlenih, izvještaji o radu picerije.
Restaurant board. Prikaz menija na televizorima u picerijama.
Admin. Postavke za određenu pizzeriju: meni, cijene, računovodstvo, promotivni kodovi, promocije, baneri za stranicu itd.
Lični račun zaposlenika. Raspored rada zaposlenih, podaci o zaposlenima.
Motivacija kuhinje. Zaseban ekran koji visi u kuhinji i prikazuje brzinu pizzara.
komunikacija. Slanje sms-a i email-a.
FileStorage. Vlastiti servis za prijem i izdavanje statičkih fajlova.

Prvi pokušaji rješavanja problema su nam pomogli, ali su bili samo privremeni predah. Nisu postala sistemska rješenja, pa je bilo jasno da se sa bazama mora nešto raditi. Na primjer, podijelite opću bazu podataka na nekoliko više specijaliziranih.

Počinjemo da rasterećujemo monolit: razdvajanje Auth-a i Tracker-a

Glavni servisi koji su tada pisali i čitali iz baze podataka više od ostalih:

1. Auth. Usluga autorizacije i autentifikacije za backoffice.
2. Tracker. Praćenje narudžbi u kuhinji. Usluga označavanja statusa spremnosti prilikom pripreme narudžbe.

Šta radi Auth?

Auth je usluga preko koje se korisnici prijavljuju u back office (postoji zasebna nezavisna prijava na strani klijenta). Također se navodi u zahtjevu kako bi se osiguralo da postoje ispravna prava pristupa i da se ta prava nisu promijenila od posljednje prijave. Preko njega uređaji ulaze u picerije.

Na primjer, želimo da otvorimo displej sa statusom izvršenih narudžbi na TV-u koji visi u hodniku. Zatim otvaramo auth.dodopizza.ru, odabiremo "Prijavite se kao uređaj", pojavljuje se kod koji se može unijeti na posebnu stranicu na računalu upravitelja smjena, koji označava vrstu uređaja (uređaja). Sam TV će otići do željenog interfejsa svoje picerije i tamo početi da prikazuje imena kupaca čije su narudžbe spremne.

Odakle dolaze opterećenja?

Svaki prijavljen backoffice korisnik za svaki zahtjev odlazi u bazu podataka, u korisničku tablicu, izvlači korisnika odatle kroz sql upit i provjerava da li ima potreban pristup i prava na ovu stranicu.

Svaki od uređaja radi isto samo sa tablicom uređaja, provjeravajući svoju ulogu i pristupe. Veliki broj zahtjeva prema glavnoj bazi podataka dovodi do njenog učitavanja i rasipanja općih resursa baze podataka na ove operacije.

Unloading Auth

Auth ima izoliranu domenu, odnosno podaci o korisnicima, loginovima ili uređajima ulaze u servis (trenutno budući) i tamo ostaju. Ako nekom zatrebaju, otići će u ovaj servis po podatke.

BIO. U početku je tok rada bio ovakav:

Želio bih malo objasniti kako je to funkcioniralo:

1. Eksterni zahtjev dolazi u pozadinu (Asp.Net MVC tamo), donoseći sa sobom kolačić sesije, koji se koristi za dobijanje podataka o sesiji iz Redis(1). Ili sadrži informacije o pristupima, a onda je pristup kontroleru otvoren (3,4), ili ne.
2. Ako nema pristupa, potrebno je proći proceduru autorizacije. Ovdje je, radi jednostavnosti, prikazan kao dio putanje u istom atributu, iako je ovo prijelaz na stranicu za prijavu. U slučaju pozitivnog scenarija, primit ćemo ispravno popunjenu sesiju i otići na Backoffice Controller.
3. Ako postoje podaci, onda ih trebate provjeriti da li su relevantni u korisničkoj bazi podataka. Da li se njegova uloga promijenila, da li ga sada ne treba pustiti na stranicu? U ovom slučaju, nakon primanja sesije (1), trebate direktno otići u bazu podataka i provjeriti pristup korisnika pomoću logičkog sloja autentikacije (2). Zatim ili idite na stranicu za prijavu ili idite na kontroler. Ovo je jednostavan sistem, ali nije sasvim standardan.
4. Ako su sve procedure završene, onda preskačemo dalje u logici u kontrolerima i metodama.

Korisnički podaci su odvojeni od svih ostalih podataka, pohranjeni su u zasebnoj tablici članstva, funkcije iz AuthService logičkog sloja mogu postati API metode. Granice domena su prilično jasno definisane: korisnici, njihove uloge, pristupni podaci, izdavanje i ukidanje pristupa. Sve izgleda kao da bi se moglo premjestiti u poseban servis.

POSTAO. To su uradili:

Ovaj pristup ima niz problema. Na primjer, pozivanje metode unutar procesa nije isto što i pozivanje eksterne usluge putem http. Latencija, pouzdanost, podrška i transparentnost operacije su potpuno različite. Andrey Morevsky je detaljnije govorio o upravo ovim problemima u svom izvještaju "50 nijansi mikroservisa".

Servis autentifikacije i sa njim servis uređaja koriste se za back office, odnosno za servise i interfejse koji se koriste u proizvodnji. Provjera autentičnosti za klijentske usluge (kao što je web stranica ili mobilna aplikacija) se odvija zasebno bez korištenja Auth. Razdvajanje je trajalo oko godinu dana, a sada ponovo radimo na ovoj temi, prenoseći sistem na nove servise za autentifikaciju (sa standardnim protokolima).

Zašto je razdvajanje trajalo toliko dugo?
Bilo je mnogo problema na putu koji su nas usporavali:

1. Željeli smo prenijeti podatke o korisnicima, uređajima i autentifikaciji iz baza podataka zemalja u jednu. Da bismo to učinili, morali smo prenijeti sve tabele i upotrebu sa int identifikatora na globalni UUId identifikator (nedavno smo preradili ovaj kod Roman Bukin “Uuid - velika priča o maloj građevini” i projekat otvorenog koda Primitivci). Čuvanje korisničkih podataka (budući da se radi o ličnim podacima) ima svoja ograničenja i za neke zemlje ih je potrebno posebno čuvati. Ali mora postojati globalni korisnički ID.
2. Mnoge tabele u bazi podataka imaju informacije revizije o korisniku koji je izvršio operaciju. Ovo je zahtijevalo dodatni mehanizam za osiguranje konzistentnosti.
3. Nakon kreiranja API servisa, postojao je dug i postepen period prelaska na drugi sistem. Prebacivanja su se morala odvijati bez problema za korisnike i zahtijevali su ručni rad.

Šema za registraciju uređaja u piceriji:

Opća arhitektura nakon razdvajanja usluge Auth i Devices:

primjedba. Za 2020. radimo na novoj verziji Auth-a, koja je bazirana na OAuth 2.0 standardu autorizacije. Ovaj standard je prilično složen, ali koristan za razvoj usluge autentifikacije s kraja na kraj. U članku "Suptilnosti autorizacije: pregled OAuth 2.0 tehnologije» mi, Aleksej Černjajev, pokušali smo da pričamo o standardu što jednostavnije i jasnije kako biste uštedeli vreme na njegovom proučavanju.

Šta Tracker radi?

Sada o drugom od učitanih servisa. Traker ima dvostruku ulogu:

• S jedne strane, njegov zadatak je da pokaže zaposlenima u kuhinji koje su narudžbe trenutno u toku, koje proizvode sada treba pripremiti.
• S druge strane, digitalizirajte sve procese u kuhinji.

Kada se novi proizvod (na primjer, pica) pojavi u narudžbi, on ide na stanicu za praćenje „Rolling“. Na ovoj stanici nalazi se pizzadžija koji uzima lepinju potrebne veličine i razvaljuje je, nakon čega na tabletu za praćenje označava da je obavio svoj zadatak i predaje razvaljanu podlogu od tijesta na sljedeću stanicu - “Pilnjenje” .

Tamo, sljedeći pizzeri na vrhu pizze, zatim označava na tabletu da je obavio svoj zadatak i stavlja pizzu u pećnicu (ovo je također posebna stanica koju treba označiti na tabletu). Takav sistem je bio prisutan od samog početka u Dodou i od samog početka Dodo IS-a. Omogućava vam da u potpunosti pratite i digitalizirate sve operacije. Osim toga, tracker predlaže kako pripremiti određeni proizvod, izvodi svaku vrstu proizvoda prema vlastitim proizvodnim shemama, pohranjuje optimalno vrijeme kuhanja za proizvod i prati sve operacije na proizvodu.

Ovako izgleda ekran tableta na stanici za praćenje Raskatka.

Odakle dolaze opterećenja?

Svaka picerija ima oko pet tableta sa trackerom. U 2016. godini imali smo više od 100 picerija (a sada ih ima više od 600). Svaki od tableta svakih 10 sekundi šalje zahtjev backendu i prikuplja podatke iz tabele narudžbi (veza sa klijentom i adresom), sastava narudžbe (veza sa proizvodom i naznakom količine) i tabele motivacije (prati vreme pritiska). Kada proizvođač pizze klikne na proizvod na trackeru, zapisi u svim ovim tabelama se ažuriraju. Tabela narudžbi je opšta, istovremeno sadrži umetanja prilikom prihvatanja narudžbine, ažuriranja iz drugih delova sistema i brojna očitavanja, na primer, na televizoru koji visi u piceriji i prikazuje gotove narudžbe kupcima.

Tokom perioda borbe sa opterećenjima, kada je sve i svako keširano i prebačeno u asinhronu repliku baze podataka, ove operacije sa trackerom su nastavile da idu u glavnu bazu podataka. Ovdje ne bi trebalo biti kašnjenja, podaci moraju biti ažurirani, neusklađenost je neprihvatljiva.

Također, nedostatak vlastitih tabela i indeksa na njima nije nam dozvolio da napišemo konkretnije upite prilagođene našoj upotrebi. Na primjer, moglo bi biti efikasno da pratilac ima indeks za piceriju u svojoj tabeli narudžbi. Narudžbe picerije uvijek prikupljamo iz baze podataka za praćenje. Pri tome, za prihvatanje porudžbine nije toliko važno u koju piceriju spada, važnije je koji klijent je napravio ovu narudžbu. To znači da na klijentu mora postojati indeks. Također nije potrebno da uređaj za praćenje pohranjuje ID odštampanog računa ili bonus promocije povezane s narudžbom u tabeli narudžbi. Naš servis za praćenje nije zainteresiran za ove informacije. U zajedničkoj monolitnoj bazi podataka, tabele mogu biti samo kompromis između svih korisnika. Ovo je bio jedan od prvobitnih problema.

BIO. U početku je arhitektura bila ovakva:

Čak i nakon što je razdvojen u zasebne procese, većina kodne baze je ostala zajednička za različite usluge. Sve ispod kontrolora bilo je objedinjeno i živelo u jednom spremištu. Korištene su uobičajene metode servisa, spremišta i zajednička baza podataka koja sadrži zajedničke tabele.

Istovar Tracker

Glavni problem sa trackerom je taj što podaci moraju biti sinhronizovani između različitih baza podataka. To je ujedno i njegova glavna razlika u odnosu na podjelu Auth servisa; nalog i njegov status se mogu mijenjati i treba ih prikazati u raznim servisima.

Narudžbine primamo na blagajni restorana (ovo je usluga), pohranjuje se u bazi podataka u statusu „Prihvaćeno“. Nakon toga, trebao bi otići u tracker, gdje će još nekoliko puta promijeniti svoj status: iz "Kuhinja" u "Upakovano". U tom slučaju, neki vanjski utjecaji iz blagajne ili sučelja Shift Managera mogu se pojaviti s nalogom. Dat ću statuse narudžbi sa njihovim opisima u tabeli:

Šema promjene statusa narudžbe izgleda ovako:

Statusi se mijenjaju između različitih sistema. I ovdje tracker nije konačni sistem u kojem su podaci zaključani. Videli smo nekoliko mogućih pristupa za razdvajanje u takvom slučaju:

1. Sve radnje narudžbe koncentrišemo u jednu uslugu. U našem slučaju, ova opcija zahtijeva previše usluge za obradu narudžbe. Da smo tu stali, završili bismo sa drugim monolitom. Probleme ne bismo riješili.
2. Jedan sistem poziva drugi. Druga opcija je zanimljivija. Ali uz to su mogući lanci poziva (kaskadni kvarovi), povezanost komponenti je veća i teže je upravljati.
3. Organizujemo događaje, a svaka usluga se razmjenjuje s drugom kroz ove događaje. Kao rezultat toga, izabrana je treća opcija, prema kojoj sve usluge počinju međusobno razmjenjivati ​​događaje.

Činjenica da smo odabrali treću opciju značila je da će tracker imati svoju bazu podataka i za svaku promjenu redoslijeda slati događaj o tome, na koji bi se drugi servisi pretplatili i koji bi također bio uključen u glavnu bazu podataka. Da bismo to učinili, bila nam je potrebna neka usluga koja bi osigurala isporuku poruka između servisa.

U to vrijeme već smo imali RabbitMQ u stogu, pa je stoga konačna odluka da ga koristimo kao posrednika za poruke. Dijagram prikazuje tranziciju narudžbe sa blagajne restorana kroz Tracker, gdje mijenja svoj status i prikaz na interfejsu za narudžbe menadžera. POSTAO:

Naručite put korak po korak
Putanja narudžbe počinje na jednoj od usluga izvora narudžbe. Evo blagajnika restorana:

1. Narudžba je u potpunosti spremna na blagajni i vrijeme je da je pošaljete na tracker. Događaj na koji je pratilac pretplaćen se baca.
2. Traker, prihvatajući narudžbu, sprema je u svoju bazu podataka, pravi događaj „Narudžbu je prihvatio Tracker“ i šalje je u RMQ.
3. Nekoliko rukovalaca je već pretplaćeno na prilagođenu sabirnicu događaja. Za nas je važan onaj koji se sinhronizuje sa monolitnom bazom podataka.
4. Rukovalac prima događaj, bira iz njega podatke koji su za njega značajni: u našem slučaju, ovo je status narudžbe „Prihvaćeno od Trackera“ i ažurira svoj entitet narudžbe u glavnoj bazi podataka.

Ako nekome treba narudžba posebno iz tabele monolitnih narudžbi, onda je može pročitati i odatle. Na primjer, ovo je ono što je potrebno interfejsu Orders u Shift Manageru:

Svi ostali servisi se također mogu pretplatiti na naručivanje događaja sa trackera kako bi ih sami koristili.

Ako se nakon nekog vremena narudžba uzme u proizvodnju, njen status se prvo mijenja u bazi podataka (Tracker baza podataka), a zatim se odmah generiše događaj “OrderInWork”. Takođe ulazi u RMQ, odakle se sinhronizuje u monolitnu bazu podataka i isporučuje drugim servisima. Na ovom putu može biti raznih problema; više detalja o njima možete pronaći u izvještaju Ženje Peškova o detaljima implementacije Eventualne konzistentnosti u Trackeru.

Konačna arhitektura nakon promjena u Auth i Tracker-u

Da rezimiramo: U početku sam imao ideju da devetogodišnju istoriju Dodo IS sistema upakujem u jedan članak. Želio sam brzo i jednostavno govoriti o fazama evolucije. Međutim, nakon što sam sjeo da proučavam gradivo, shvatio sam da je sve mnogo složenije i zanimljivije nego što se čini.

Razmišljajući o prednostima (ili nedostatku istih) takvog materijala, došao sam do zaključka da je kontinuirani razvoj nemoguć bez punopravnih kronika događaja, detaljnih retrospektiva i analize nečijih prošlih odluka.

Nadam se da vam je bilo korisno i zanimljivo saznati o našem putovanju. Sada sam pred izborom koji dio Dodo IS sistema da opišem u sljedećem članku: pišite u komentarima ili glasajte.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite semolim.

O kom dijelu Dodo IS-a biste željeli naučiti u sljedećem članku?

• 24,1%Rani monolit u Dodo IS (2011-2015)14

• 24,1%Prvi problemi i njihova rješenja (2015-2016)14

• 20,7%Staza klijentskog dijela: fasada iznad baze (2016-2017)12

• 36,2%Istorija stvarnih mikroservisa (2018-2019)21

• 44,8%Završeno sečenje monolita i stabilizacija arhitekture26

• 29,3%O daljim planovima za razvoj sistema17

• 19,0%Ne želim da znam ništa o Dodo IS11

Glasalo je 58 korisnika. Uzdržano je bilo 6 korisnika.

izvor: www.habr.com