Povijest Dodo IS arhitekture: Put do ureda

Habr mijenja svijet. Blogiramo više od godinu dana. Prije nekih šest mjeseci dobili smo sasvim logičnu povratnu informaciju od Khabrovitesa: “Dodo, svugdje govoriš da imaš svoj sustav. A kakav je to sustav? A zašto to treba lancu pizzerija?

Sjedili smo, razmišljali i shvatili da si u pravu. Pokušavamo sve objasniti na prstima, ali izlazi u komadima i nigdje nema cjelovitog opisa sustava. Tako je započeo dugi put prikupljanja informacija, traženja autora i pisanja niza članaka o Dodo IS-u. Idemo!

Zahvale: zahvaljujemo što ste s nama podijelili svoje povratne informacije. Zahvaljujući njemu, konačno smo opisali sustav, sastavili tehnički radar i uskoro ćemo izbaciti veliki opis naših procesa. Bez vas sjedili bismo još 5 godina.

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

1. Rani monolit u Dodo IS (2011.-2015.). (U nastajanju...)
2. Staza stražnjeg ureda: odvojene baze i autobus. (ti si ovdje)
3. Put sa strane klijenta: fasada preko baze (2016-2017). (U nastajanju...)
4. Povijest pravih mikroservisa. (2018.-2019.). (U nastajanju...)
5. Završeno piljenje monolita i stabilizacija arhitekture. (U nastajanju...)

Ako vas zanima još nešto - napišite u komentarima.

Mišljenje o kronološkom opisu od autora
Redovito održavam sastanak za nove zaposlenike na temu „Arhitektura sustava“. Zovemo ga "Uvod u Dodo IS arhitekturu" i dio je procesa uključivanja novih programera. Govoreći na ovaj ili onaj način o našoj arhitekturi, o njezinim značajkama, rodio sam određeni povijesni pristup opisu.

Tradicionalno, sustav promatramo kao skup komponenti (tehničke ili više razine), poslovnih modula koji međusobno djeluju kako bi postigli neki cilj. A ako je takav pogled opravdan za dizajn, onda nije sasvim prikladan za opis i razumijevanje. Ovdje postoji nekoliko razloga:

• Stvarnost je drugačija od onoga što je na papiru. Ne ide sve kako je planirano. A nas zanima kako je to zapravo ispalo i funkcionira.
• Dosljedno predstavljanje informacija. Zapravo, možete ići kronološki od početka do trenutnog stanja.
• Od jednostavnog do složenog. Ne univerzalno, ali u našem slučaju jest. Arhitektura je prešla s jednostavnijih pristupa na složenije. Često kompliciranjem rješavani su problemi brzine i stabilnosti implementacije, kao i deseci drugih svojstava s popisa nefunkcionalnih zahtjeva (ovdje dobro rečeno o kontrastu složenosti s drugim zahtjevima).

2011. Dodo IS arhitektura je izgledala ovako:

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

Kako je došlo do te evolucije? Zašto su potrebni različiti dijelovi sustava? Koje su arhitektonske odluke donesene i zašto? Otkrijmo u ovoj seriji članaka.

Prvi problemi 2016.: zašto bi servisi trebali napustiti monolit

Prvi članci iz ciklusa 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 sustavu do početka 2016. godine, da smo se morali baviti razdvajanjem usluga.

Jedinstvena MySql baza podataka, u koju su zapisivale sve aplikacije koje su tada postojale u Dodo IS-u. Posljedice su bile:

• Veliko opterećenje (s 85% zahtjeva odnosi se na čitanje).
• Baza je narasla. Zbog toga su njegova cijena i podrška postali problem.
• Jedna točka kvara. Ako je jedna aplikacija počela pisati u bazu podataka odjednom to aktivnije, onda su druge aplikacije to osjetile na sebi.
• Neučinkovitost u pohrani i upitima. Često su podaci bili pohranjeni u nekoj strukturi koja je bila prikladna za neke scenarije, ali nije prikladna za druge. Indeksi ubrzavaju neke operacije, ali mogu usporiti druge.
• Neki od problema su otklonjeni na brzinu napravljenim predmemorijama i read-replikama na baze (ovo će biti poseban članak), ali samo su im omogućili da dobiju na vremenu, a nisu suštinski riješili problem.

Problem je bila prisutnost samog monolita. Posljedice su bile:

• Pojedinačna i rijetka izdanja.
• Poteškoće u zajedničkom razvoju velikog broja ljudi.
• Nemogućnost uvođenja novih tehnologija, novih okvira i knjižnica.

Problemi s bazom i monolitom opisani su mnogo puta, na primjer, u kontekstu sudara početkom 2018. (Budite kao Munch, ili nekoliko riječi o tehničkom dugu, Dan kada je Dodo zaustavljen. Asinkrona skripta и Priča o ptici Dodo iz obitelji Phoenix. Veliki pad Dodoa IS), pa neću previše duljiti. Dopustite mi samo da kažem da smo željeli dati više fleksibilnosti pri razvoju usluga. Prije svega, to se odnosilo na one koji su bili najviše opterećeni i root u cijelom sustavu - Auth i Tracker.

Put do ureda: odvojene baze i autobus

Navigacija poglavlja

1. Monolitna shema 2016
2. Početak pražnjenja monolita: Odvajanje autentifikacije i praćenja
   
3. Što Auth radi?
4. Odakle su tereti?
5. Istovar Auth
6. Što Tracker radi?
7. Odakle su tereti?
8. Tragač za istovar

Monolitna shema 2016

Ovdje su glavni blokovi monolita Dodo IS 2016, a odmah ispod je transkript njihovih glavnih zadataka.

Blagajnička dostava. Obračun kurira, izdavanje naloga kuririma.
Kontaktni centar. Prihvaćanje narudžbi preko operatera.
mjesto. Naše web stranice (dodopizza.ru, dodopizza.co.uk, dodopizza.by itd.).
auth. Usluga autorizacije i autentifikacije za back office.
tragač. Pratilac narudžbi u kuhinji. Servis za označavanje statusa spremnosti prilikom izrade narudžbe.
Blagajna restorana. Primanje narudžbi u restoranu, blagajnička sučelja.
Izvoz. Prijenos izvješća u 1C za računovodstvo.
Obavijesti i fakture. Glasovne komande u kuhinji (npr. “Stigla nova pizza”) + ispis računa za dostavljače.
Šef smjene. Sučelja za rad voditelja smjene: popis naloga, grafikoni učinka, prijenos zaposlenika u smjenu.
Upravitelj ureda. Sučelja za rad primatelja franšize i voditelja: prijem zaposlenika, izvješća o radu pizzerije.
Semafor restorana. Prikaz jelovnika na televizorima u pizzerijama.
admin. Postavke u određenoj pizzeriji: jelovnik, cijene, računovodstvo, promo kodovi, promocije, web banneri itd.
Osobni račun zaposlenika. Rasporedi rada zaposlenika, podaci o zaposlenicima.
Kuhinjska motivacijska ploča. Poseban ekran koji visi u kuhinji i prikazuje brzinu pizza makera.
komunikacija. Slanje sms-a i e-maila.
FileStorage. Vlastiti servis za prijem i izdavanje statičkih datoteka.

Prvi pokušaji rješavanja problema pomogli su nam, ali bili su samo privremeni predah. Nisu postale sistemska rješenja pa je bilo jasno da se s bazama mora nešto učiniti. Na primjer, podijeliti opću bazu podataka u nekoliko specijaliziranih.

Početak pražnjenja monolita: Odvajanje autentifikacije i praćenja

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

1. Auth. Usluga autorizacije i autentifikacije za back office.
2. Tragač. Pratilac narudžbi u kuhinji. Servis za označavanje statusa spremnosti prilikom izrade narudžbe.

Što Auth radi?

Auth je usluga putem koje se korisnici prijavljuju u back office (na klijentskoj strani postoji zaseban samostalan ulaz). U zahtjevu se također traži da se uvjerite da su potrebna prava pristupa prisutna i da se ta prava nisu promijenila od posljednje prijave. Preko njega uređaji ulaze u pizzeriju.

Na primjer, želimo na televizoru koji visi u hodniku otvoriti displej sa statusima gotovih narudžbi. Zatim otvaramo auth.dodopizza.ru, odabiremo "Prijava kao uređaj", pojavljuje se kod koji se može unijeti na posebnu stranicu na računalu voditelja smjene, označavajući vrstu uređaja (uređaja). TV će se sam prebaciti na željeno sučelje svoje pizzerije i početi prikazivati ​​imena kupaca čije su narudžbe tamo spremne.

Odakle su tereti?

Svaki prijavljeni korisnik back office-a ide u bazu podataka, u tablicu korisnika za svaki zahtjev, izvlači korisnika kroz sql upit i provjerava ima li potreban pristup i prava ovoj stranici.

Svaki od uređaja čini isto samo s tablicom uređaja, provjeravajući njegovu ulogu i pristup. Velik broj zahtjeva prema glavnoj bazi podataka dovodi do njenog učitavanja i rasipanja resursa zajedničke baze podataka za ove operacije.

Istovar Auth

Auth ima izoliranu domenu, odnosno podaci o korisnicima, prijavama ili uređajima ulaze u servis (trenutno) i tamo ostaju. Ako nekome trebaju, onda će otići u ovaj servis po podatke.

BILO JE. Prvobitna shema rada bila je sljedeća:

Želio bih malo objasniti kako je to funkcioniralo:

1. Zahtjev izvana dolazi u backend (postoji Asp.Net MVC), sa sobom donosi kolačić sesije, koji se koristi za dobivanje podataka o sesiji od Redisa(1). Ili sadrži informacije o pristupima, a onda je pristup kontroleru otvoren (3,4), ili nije.
2. Ako nema pristupa, morate proći kroz postupak autorizacije. Ovdje je, zbog jednostavnosti, prikazan kao dio staze u istom atributu, iako je prijelaz na stranicu za prijavu. U slučaju pozitivnog scenarija, dobit ćemo ispravno završenu sesiju i otići do Backoffice Controllera.
3. Ako postoje podaci, trebate provjeriti njihovu relevantnost u bazi podataka korisnika. Je li mu se promijenila uloga, ne bi li ga sada trebalo pustiti na stranicu? U tom slučaju, nakon primanja sesije (1), trebate otići izravno u bazu podataka i provjeriti pristup korisnika pomoću logičkog sloja provjere autentičnosti (2). Zatim ili na stranicu za prijavu ili idite na kontroler. Tako jednostavan sustav, ali ne sasvim standardan.
4. Ako su svi postupci prošli, onda preskačemo dalje u logici u kontrolerima i metodama.

Korisnički podaci odvojeni su od svih ostalih podataka, pohranjuju se u zasebnu tablicu članstva, funkcije iz logičkog sloja AuthService mogu postati api metode. Granice domene definirane su vrlo jasno: korisnici, njihove uloge, pristupni podaci, odobravanje i opoziv pristupa. Sve izgleda tako da se može izvaditi u posebnom servisu.

POSTATI. Pa su učinili:

Ovaj pristup ima niz problema. Na primjer, pozivanje metode unutar procesa nije isto što i pozivanje vanjske usluge putem http-a. Latencija, pouzdanost, mogućnost održavanja, transparentnost rada su potpuno drugačiji. Andrey Morevskiy je detaljnije govorio o takvim problemima u svom izvješću. "50 nijansi mikroservisa".

Servis autentifikacije, a time i servis uređaja, koristi se za back office, odnosno za servise i sučelja koja se koriste u proizvodnji. Provjera autentičnosti za klijentske usluge (kao što je web mjesto ili mobilna aplikacija) odvija se zasebno bez upotrebe Auth. Razdvajanje je trajalo oko godinu dana, a sada se ponovno bavimo tom tematikom, prebacivanjem sustava na nove autentifikacijske servise (sa standardnim protokolima).

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

1. Htjeli smo premjestiti podatke o korisnicima, uređajima i autentifikaciji iz baza podataka za pojedinu zemlju u jednu. Da bismo to učinili, morali smo prevesti sve tablice i upotrebu iz int identifikatora u globalni UUId identifikator (nedavno smo preradili ovaj kod Roman Bukin "Uuid - velika priča male strukture" i projekt otvorenog koda primitivci). Pohranjivanje korisničkih podataka (budući da se radi o osobnim podacima) ima svoja ograničenja te ih je za neke zemlje potrebno odvojeno pohranjivati. Ali globalni ID korisnika mora biti.
2. Mnoge tablice u bazi podataka imaju revizijske informacije o korisniku koji je izvršio operaciju. Ovo je zahtijevalo dodatni mehanizam za dosljednost.
3. Nakon stvaranja api-servisa uslijedio je dug i postupan period prelaska na drugi sustav. Prebacivanje je moralo biti besprijekorno za korisnike i zahtijevalo je ručni rad.

Shema registracije uređaja u pizzeriji:

Opća arhitektura nakon ekstrakcije usluge Auth and Devices:

Primijetiti. Za 2020. radimo na novoj verziji Auth-a koja se temelji na standardu autorizacije OAuth 2.0. Ovaj standard je prilično složen, ali je koristan za razvoj usluge provjere autentičnosti prolaza. U članku "Suptilnosti autorizacije: pregled OAuth 2.0 tehnologije» mi Alexey Chernyaev pokušali smo ispričati o standardu što je moguće jednostavnije i jasnije kako biste uštedjeli vrijeme na njegovom proučavanju.

Što Tracker radi?

Sada o drugoj od učitanih usluga. Tragač ima dvostruku ulogu:

• S jedne strane, njegov zadatak je pokazati zaposlenicima u kuhinji koji su narudžbe trenutno u radu, koje proizvode sada treba kuhati.
• S druge strane, digitalizirati sve procese u kuhinji.

Kada se novi proizvod pojavi u narudžbi (na primjer, pizza), on ide na Rolling out tracker stanicu. Na ovoj stanici nalazi se pizzadžija koji uzima pecivo željene veličine i razvalja ga, nakon čega na tracker tabletu bilježi da je obavio svoj zadatak i prebacuje razvaljanu podlogu od tijesta na sljedeću stanicu – “Inicijacija”. .

Tamo sljedeći pizzadžija puni pizzu, zatim na tabletu bilježi da je završio svoj zadatak i stavlja pizzu u pećnicu (ovo je također zasebna stanica koja se mora zabilježiti na tabletu). Takav sustav je bio od samog početka u Dodu i od samog početka postojanja Dodo IS-a. Omogućuje vam potpuno praćenje i digitalizaciju svih transakcija. Osim toga, tracker predlaže kako kuhati određeni proizvod, vodi svaku vrstu proizvoda prema proizvodnim shemama, pohranjuje optimalno vrijeme kuhanja za proizvod i prati sve operacije na proizvodu.

Ovako izgleda ekran tableta na stanici trackera "Raskatka"

Odakle su tereti?

Svaka od pizzerija ima oko pet tableta s trackerom. U 2016. godini imali smo više od 100 pizzerija (a sada više od 600). Svaki od tableta postavlja zahtjev backendu svakih 10 sekundi i struže podatke iz tablice narudžbi (veza s klijentom i adresa), sastava narudžbe (veza s proizvodom i naznaka količine), tablice motivacijskog računovodstva ( u njemu se prati vrijeme prešanja). Kada proizvođač pizze klikne na proizvod na alatu za praćenje, unosi u svim tim tablicama se ažuriraju. Tablica narudžbi je opća, sadrži i umetke prilikom prihvaćanja narudžbe, ažuriranja iz drugih dijelova sustava i brojna očitavanja, na primjer, na TV-u koji visi u pizzeriji i prikazuje gotove narudžbe kupcima.

Tijekom razdoblja borbe s opterećenjem, kada je sve i svašta predmemorirano i prebačeno u asinkronu repliku baze, te operacije s trackerom nastavile su ići u glavnu bazu. Ne smije biti kašnjenja, podaci trebaju biti ažurni, neusklađenost je nedopustiva.

Također, nedostatak vlastitih tablica i indeksa na njima nije dopuštao pisanje specifičnijih upita prilagođenih njihovoj upotrebi. Na primjer, za praćenje bi moglo biti učinkovito imati indeks za pizzeriju na tablici narudžbi. Uvijek uklanjamo narudžbe iz pizzerije iz baze podataka za praćenje. Pritom, za primanje narudžbe nije toliko važno u koju pizzeriju spada, važnije je koji je klijent napravio tu narudžbu. A znači da je potreban indeks na klijentu. Također nije potrebno da uređaj za praćenje pohranjuje ID ispisane potvrde ili bonus promocije povezane s narudžbom u tablici narudžbi. Ova informacija nije od interesa za našu uslugu praćenja. U zajedničkoj monolitnoj bazi podataka, tablice mogu biti samo kompromis između svih korisnika. Ovo je bio jedan od izvornih problema.

BILO JE. Izvorna arhitektura bila je:

Čak i nakon razdvajanja u zasebne procese, većina baze koda ostala je zajednička za različite usluge. Sve ispod kontrolera bilo je pojedinačno i živjelo je u istom spremištu. Koristili smo zajedničke metode servisa, repozitorije, zajedničku bazu, u kojoj su ležale zajedničke tablice.

Tragač za istovar

Glavni problem s trackerom je taj što se podaci moraju sinkronizirati između različitih baza podataka. Ovo je ujedno i njegova glavna razlika od odvajanja Auth servisa, nalog i njegov status se mogu mijenjati i trebaju biti prikazani u različitim servisima.

Narudžbu prihvaćamo na blagajni restorana (ovo je usluga), pohranjuje se u bazi podataka u statusu "Prihvaćeno". Nakon toga bi trebao doći do trackera, gdje će još nekoliko puta promijeniti svoj status: iz “Kuhinja” u “Spakirano”. U isto vrijeme, s narudžbom se mogu pojaviti neki vanjski utjecaji blagajnika ili sučelja voditelja smjene. Dat ću statuse naloga s njihovim opisom u tablici:

Shema za promjenu statusa naloga izgleda ovako:

Statusi se mijenjaju između različitih sustava. I ovdje tracker nije konačni sustav u kojem su podaci zatvoreni. Vidjeli smo nekoliko mogućih pristupa za particioniranje u takvom slučaju:

1. Sve radnje narudžbi koncentriramo u jednu uslugu. U našem slučaju, ova opcija zahtijeva previše usluge za rad s narudžbom. Kad bismo stali na tome, dobili bismo drugi monolit. Ne bismo riješili problem.
2. Jedan sustav poziva drugi. Druga opcija je već zanimljivija. Ali s njim su mogući lanci poziva (kaskadni kvarovi), povezanost komponenti je veća, teže je upravljati.
3. Organiziramo događaje, a svaka služba kroz te događaje komunicira s drugom. Kao rezultat toga, odabrana je treća opcija, prema kojoj sve službe počinju međusobno razmjenjivati ​​događaje.

To što smo odabrali treću opciju značilo je da će tracker imati svoju bazu podataka, te će za svaku promjenu redoslijeda o tome slati događaj na koji se pretplaćuju ostali servisi i koji također spada u master bazu. Da bismo to učinili, trebala nam je neka usluga koja bi osigurala isporuku poruka između usluga.

Do tog vremena već smo imali RabbitMQ u stogu, stoga je konačna odluka da ga koristimo kao brokera poruka. Dijagram prikazuje prijelaz narudžbe iz Blagajne restorana preko Trackera, gdje mijenja status i prikaz na sučelju Narudžbe upravitelja. POSTATI:

Put narudžbe korak po korak
Put narudžbe počinje na jednoj od usluga izvora narudžbe. Ovdje je blagajnica restorana:

1. Na blagajni je narudžba potpuno spremna i vrijeme je da je pošaljete na tracker. Izbacuje se događaj na koji je tracker pretplaćen.
2. Tragač, prihvaćajući narudžbu za sebe, sprema je u vlastitu bazu podataka, čineći događaj "Narudžbu prihvatio Tragač" i šaljući je u RMQ.
3. Postoji nekoliko rukovatelja koji su već pretplaćeni na sabirnicu događaja po narudžbi. Za nas je bitan onaj koji radi sinkronizaciju s monolitnom bazom.
4. Rukovatelj prima događaj, iz njega odabire podatke koji su za njega značajni: u našem slučaju to je status naloga "Prihvaćen od strane Trackera" i ažurira svoj entitet naloga u glavnoj bazi podataka.

Ako nekome treba narudžba iz monolitne tablice narudžbi, onda je možete pročitati i od tamo. Na primjer, sučelje Narudžbe u Shift Manageru treba ovo:

Sve druge usluge također se mogu pretplatiti na naručivanje događaja iz trackera kako bi ih koristili za sebe.

Ako se nakon nekog vremena narudžba pusti u rad, tada se najprije promijeni status u svojoj bazi podataka (Tracker database), a zatim se odmah generira događaj "OrderIn Progress". Također ulazi u RMQ, odakle se sinkronizira u monolitnu bazu podataka i isporučuje drugim servisima. Na putu se mogu pojaviti različiti problemi, više detalja o njima možete pronaći u izvješću Ženje Peškova o detaljima implementacije Eventualne dosljednosti u Trackeru.

Konačna arhitektura nakon promjena u Auth i Trackeru

Sumirajući međurezultat: U početku sam imao ideju spakirati devetogodišnju povijest Dodo IS sustava u jedan članak. Želio sam brzo i jednostavno govoriti o fazama evolucije. Međutim, sjedajući za gradivo, shvatio sam da je sve puno kompliciranije i zanimljivije nego što se čini.

Razmišljajući o prednostima (ili nedostatku) takvog materijala, došao sam do zaključka da je kontinuirani razvoj nemoguć bez cjelovitih anala događaja, detaljnih retrospektiva i analiza mojih prošlih odluka.

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

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.

O kojem biste dijelu Dodo IS-a željeli saznati 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%Put na strani klijenta: fasada preko baze (2016.-2017.)12

• 36,2%Povijest pravih mikroservisa (2018.-2019.)21

• 44,8%Kompletno piljenje monolita i stabilizacija arhitekture26

• 29,3%O daljnjim planovima razvoja sustava17

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

Glasovalo je 58 korisnika. Suzdržano je bilo 6 korisnika.

Izvor: www.habr.com