Habr spreminja svet. Blog pišemo že več kot eno leto. Pred približno pol leta smo od Khabrovcev prejeli povsem logično povratno informacijo: »Dodo, povsod govoriš, da imaš svoj sistem. In kaj je ta sistem? In zakaj ga veriga picerij potrebuje?
Sedela sva, razmišljala in ugotovila, da imaš prav. Poskušamo vse razložiti na prste, a pride ven raztrgano in nikjer ni popolnega opisa sistema. Tako se je začela dolga pot zbiranja informacij, iskanja avtorjev in pisanja serije člankov o Dodo IS. Pojdimo!
Zahvala: hvala, ker ste z nami delili povratne informacije. Po njegovi zaslugi smo končno opisali sistem, sestavili tehnični radar in kmalu bomo izdali obsežen opis naših procesov. Brez vas bi sedeli tam še 5 let.
Serija člankov "Kaj je Dodo IS?" pripoveduje o:
- Zgodnji monolit v Dodo IS (2011-2015). (V delu...)
- Pot zaledne pisarne: ločene baze in avtobus. (tukaj ste)
- Pot s strani naročnika: fasada nad podstavkom (2016-2017). (V delu...)
- Zgodovina pravih mikrostoritev. (2018-2019). (V delu...)
- Končano žaganje monolita in stabilizacija arhitekture. (V delu...)
Če vas zanima še kaj - napišite v komentarje.
Mnenje avtorja o kronološkem opisu
Redno organiziram srečanja za nove sodelavce na temo "Sistemska arhitektura". Imenujemo ga »Uvod v arhitekturo Dodo IS« in je del procesa vkrcanja za nove razvijalce. Ko sem v takšni ali drugačni obliki pripovedoval o naši arhitekturi, o njenih značilnostih, sem rodil določen zgodovinski pristop k opisu.
Tradicionalno gledamo na sistem kot na niz komponent (tehničnih ali višjih), poslovnih modulov, ki medsebojno delujejo, da bi dosegli nek cilj. In če je tak pogled upravičen za oblikovanje, potem ni povsem primeren za opis in razumevanje. Tukaj je več razlogov:
- Realnost je drugačna od tistega, kar je na papirju. Ne gre vse po načrtih. In nas zanima, kako se je dejansko izkazalo in deluje.
- Dosledno podajanje informacij. Pravzaprav greste lahko kronološko od začetka do trenutnega stanja.
- Od enostavnega do kompleksnega. Ne univerzalno, ampak v našem primeru je. Arhitektura je prešla od enostavnejših pristopov k kompleksnejšim. Pogosto z zapletom so bili rešeni problemi hitrosti in stabilnosti implementacije ter na desetine drugih lastnosti s seznama nefunkcionalnih zahtev ( dobro povedano o kontrastu kompleksnosti z drugimi zahtevami).
Leta 2011 je bila arhitektura Dodo IS videti takole:
Do leta 2020 je postalo malo bolj zapleteno in je postalo takole:
Kako je potekala ta evolucija? Zakaj so potrebni različni deli sistema? Kakšne arhitekturne odločitve so bile sprejete in zakaj? Ugotovimo v tej seriji člankov.
Prvi problemi leta 2016: zakaj naj storitve zapustijo monolit
Prvi članki iz cikla bodo o storitvah, ki so se prve ločile od monolita. Če vas postavim v kontekst, vam povem, kakšne težave smo imeli v sistemu do začetka leta 2016, da smo se morali ukvarjati z ločevanjem storitev.
Enotna baza podatkov MySql, v katero so svoje zapise zapisale vse aplikacije, ki so takrat obstajale v Dodo IS. Posledice so bile:
- Velika obremenitev (pri čemer je 85 % zahtev predstavljalo branje).
- Osnova je zrasla. Zaradi tega so njegovi stroški in podpora postali problem.
- Ena sama točka napake. Če je ena aplikacija začela pisati v bazo podatkov nenadoma bolj aktivno, so druge aplikacije to občutile na sebi.
- Neučinkovitost shranjevanja in poizvedb. Pogosto so bili podatki shranjeni v neki strukturi, ki je bila primerna za nekatere scenarije, vendar ni bila primerna za druge. Indeksi nekatere operacije pospešijo, druge pa lahko upočasnijo.
- Nekatere težave so odpravili na hitro izdelani predpomnilniki in branje-replike na baze (to bo ločen članek), vendar so jim le omogočili pridobitev časa in niso bistveno rešili problema.
Težava je bila prisotnost samega monolita. Posledice so bile:
- Posamezne in redke izdaje.
- Težave pri skupnem razvoju velikega števila ljudi.
- Nezmožnost uvajanja novih tehnologij, novih ogrodij in knjižnic.
Težave z bazo in monolitom so bile večkrat opisane, na primer v kontekstu nesreč v začetku leta 2018 (, и ), zato ne bom preveč razglabljal. Naj povem le, da smo želeli dati večjo prilagodljivost pri razvoju storitev. Najprej je to zadevalo tiste, ki so bili najbolj obremenjeni in korenski v celotnem sistemu - Auth in Tracker.
Pot zaledne pisarne: ločene baze in avtobus
Krmarjenje po poglavjih
Monolitna shema 2016
Tukaj so glavni bloki monolita Dodo IS 2016, tik spodaj pa je prepis njihovih glavnih nalog.
Blagajniška dostava. Obračun kurirjem, izdajanje naročil kurirjem.
Kontaktni center. Sprejemanje naročil prek operaterja.
Stran. Naše spletne strani (dodopizza.ru, dodopizza.co.uk, dodopizza.by itd.).
Auth. Storitev avtorizacije in avtentikacije za zaledno pisarno.
Sledilnik. Sledilnik naročil v kuhinji. Storitev za označevanje statusov pripravljenosti pri pripravi naročila.
Blagajna restavracije. Sprejemanje naročil v restavraciji, blagajniški vmesniki.
izvoz. Nalaganje poročil v 1C za računovodstvo.
Obvestila in računi. Glasovni ukazi v kuhinji (npr. “Nova pica je prispela”) + tiskanje računov za kurirje.
Vodja izmene. Vmesniki za delo izmenskega vodje: seznam naročil, grafi uspešnosti, premestitev zaposlenih v izmeno.
Vodja pisarne. Vmesniki za delo franšizije in upravnika: sprejem zaposlenih, poročila o delu picerije.
Restavracija Semafor. Prikaz menija na televizorjih v picerijah.
admin. Nastavitve v določeni piceriji: meni, cene, računovodstvo, promocijske kode, akcije, bannerji na spletni strani itd.
Osebni račun zaposlenega. Razporedi dela zaposlenih, podatki o zaposlenih.
Kuhinjska motivacijska tabla. Ločen zaslon, ki visi v kuhinji in prikazuje hitrost picemarjev.
Komunikacija. Pošiljanje sms in e-pošte.
FileStorage. Lasten servis za sprejem in izdajo statičnih datotek.
Prvi poskusi reševanja težav so nam pomagali, vendar so bili le začasen oddih. Niso postale sistemske rešitve, zato je bilo jasno, da je treba z osnovami nekaj narediti. Na primer, razdeliti splošno bazo podatkov na več bolj specializiranih.
Začetek razkladanja monolita: ločitev avtorizacije in sledilnika
Glavne storitve, ki so takrat posnele in prebrale iz baze podatkov več kot druge:
- Auth. Storitev avtorizacije in avtentikacije za zaledno pisarno.
- Sledilnik. Sledilnik naročil v kuhinji. Storitev za označevanje statusov pripravljenosti pri pripravi naročila.
Kaj naredi Auth?
Auth je storitev, preko katere se uporabniki prijavijo v zaledno pisarno (na strani odjemalca je ločen neodvisen vhod). V zahtevi je tudi zahtevano, da se prepriča, ali so zahtevane pravice dostopa prisotne in da se te pravice niso spremenile od zadnje prijave. Preko njega naprave vstopajo v picerijo.
Na televizorju, ki visi v predsobi, želimo na primer odpreti prikaz statusov dokončanih naročil. Nato odpremo auth.dodopizza.ru, izberemo "Prijava kot naprava", prikaže se koda, ki jo lahko vnesete na posebno stran v računalniku vodje izmene, ki označuje vrsto naprave (naprave). Televizor bo sam preklopil na želeni vmesnik svoje picerije in začel prikazovati imena strank, katerih naročila so tam pripravljena.
Od kod so tovori?
Vsak prijavljeni uporabnik zaledne pisarne gre za vsako zahtevo v bazo podatkov, v tabelo uporabnikov, preko sql poizvedbe izvleče uporabnika in preveri, ali ima potreben dostop in pravice do te strani.
Vsaka od naprav naredi isto le s tabelo naprav, preveri svojo vlogo in dostop. Veliko število zahtev glavni bazi podatkov vodi do njenega nalaganja in zapravljanja virov skupne baze podatkov za te operacije.
Razkladanje avt
Auth ima izolirano domeno, to pomeni, da podatki o uporabnikih, prijavah ali napravah vstopijo v storitev (zaenkrat) in tam ostanejo. Če jih kdo potrebuje, bo šel po podatke na ta servis.
BILO. Prvotna shema dela je bila naslednja:
Rad bi malo pojasnil, kako je delovalo:
- Zahteva od zunaj pride v zaledje (tam je Asp.Net MVC), s seboj prinese sejni piškotek, ki se uporablja za pridobivanje podatkov o seji iz Redisa(1). Vsebuje informacije o dostopih in je dostop do krmilnika odprt (3,4) ali pa ne.
- Če dostopa ni, morate iti skozi postopek avtorizacije. Tukaj je zaradi poenostavitve prikazan kot del poti v istem atributu, čeprav gre za prehod na stran za prijavo. V primeru pozitivnega scenarija bomo dobili pravilno zaključeno sejo in šli v Backoffice Controller.
- Če obstajajo podatki, jih morate preveriti glede ustreznosti v bazi uporabnikov. Se je njegova vloga spremenila, ali naj zdaj ne bi smel biti na strani? V tem primeru morate po prejemu seje (1) iti neposredno v bazo podatkov in preveriti dostop uporabnika z uporabo logične plasti preverjanja pristnosti (2). Nato pojdite na stran za prijavo ali pojdite na krmilnik. Tako preprost sistem, vendar ne povsem standarden.
- Če so vsi postopki opravljeni, potem preskočimo naprej v logiki v krmilnikih in metodah.
Uporabniški podatki so ločeni od vseh drugih podatkov, shranjeni so v ločeni članski tabeli, funkcije iz logične plasti AuthService lahko postanejo metode api. Meje domene so jasno določene: uporabniki, njihove vloge, podatki o dostopu, odobritev in preklic dostopa. Vse izgleda tako, da se da vzeti v ločenem servisu.
POSTANI. Tako so storili:
Ta pristop ima številne težave. Na primer, klicanje metode znotraj procesa ni isto kot klicanje zunanje storitve prek http. Latenca, zanesljivost, vzdržljivost, preglednost delovanja so popolnoma drugačne. Andrey Morevskiy je v svojem poročilu podrobneje govoril o tovrstnih težavah. .
Storitev avtentikacije in z njo storitev naprave se uporabljata za zaledje, torej za storitve in vmesnike, ki se uporabljajo v proizvodnji. Preverjanje pristnosti za odjemalske storitve (kot je spletno mesto ali mobilna aplikacija) poteka ločeno brez uporabe Auth. Ločitev je trajala približno eno leto, zdaj pa se spet ukvarjamo s to tematiko, prenos sistema na nove storitve avtentikacije (s standardnimi protokoli).
Zakaj je ločitev trajala tako dolgo?
Na poti je bilo veliko težav, ki so nas upočasnile:
- Podatke o uporabnikih, napravah in preverjanju pristnosti smo želeli premakniti iz zbirk podatkov za posamezne države v eno. Da bi to naredili, smo morali vse tabele in uporabo prevesti iz identifikatorja int v globalni identifikator UUId (pred kratkim predelali to kodo in odprtokodni projekt ). Shranjevanje uporabniških podatkov (ker gre za osebne podatke) ima svoje omejitve in jih je v nekaterih državah potrebno shranjevati ločeno. Toda globalni ID uporabnika mora biti.
- Številne tabele v bazi podatkov imajo revizijske informacije o uporabniku, ki je izvedel operacijo. To je zahtevalo dodaten mehanizem za doslednost.
- Po nastanku api-storitev je sledilo dolgo in postopoma obdobje prehoda na drug sistem. Preklapljanje je moralo biti za uporabnike nemoteno in je zahtevalo ročno delo.
Shema registracije naprave v piceriji:
Splošna arhitektura po ekstrakciji storitve Auth and Devices:
Obvestilo. Za leto 2020 delamo na novi različici Auth, ki temelji na avtorizacijskem standardu OAuth 2.0. Ta standard je precej zapleten, vendar je uporaben za razvoj storitve preverjanja pristnosti skozi prehod. V članku "» Alexey Chernyaev smo poskušali čim bolj preprosto in jasno povedati o standardu, da bi prihranili čas pri njegovem preučevanju.
Kaj počne Tracker?
Zdaj o drugi od naloženih storitev. Sledilnik ima dvojno vlogo:
- Po eni strani je njegova naloga pokazati zaposlenim v kuhinji, katera naročila so trenutno v delu, katere izdelke je treba zdaj kuhati.
- Po drugi strani pa digitalizirati vse procese v kuhinji.
Ko se v naročilu pojavi nov izdelek (na primer pica), gre na sledilno postajo Rolling out. Na tej postaji je picopek, ki vzame žemljico želene velikosti in jo razvalja, nato pa na sledilni tablici zabeleži, da je svojo nalogo opravil in vlečeno testeno osnovo prenese na naslednjo postajo – “Iniciacija” .
Tam naslednji picopek napolni pico, nato pa na tablici zabeleži, da je svojo nalogo opravil in da pico v peč (to je tudi ločena postaja, ki mora biti zapisana na tablici). Takšen sistem je bil od vsega začetka v Dodu in od samega začetka obstoja Dodo IS. Omogoča vam popolno sledenje in digitalizacijo vseh transakcij. Poleg tega sledilnik predlaga, kako kuhati določen izdelek, vodi vsako vrsto izdelka glede na proizvodne sheme, shrani optimalen čas kuhanja za izdelek in spremlja vse operacije na izdelku.
Tako izgleda zaslon tablice na postaji sledilnika "Raskatka"
Od kod so tovori?
Vsaka od picerij ima približno pet tablic s sledilnikom. Leta 2016 smo imeli več kot 100 picerij (zdaj pa že več kot 600). Vsaka od tablic vsakih 10 sekund pošlje zahtevo zaledju in postrga podatke iz tabele naročil (povezava z naročnikom in naslovom), sestava naročila (povezava z izdelkom in navedba količine), motivacijska tabela računovodstva ( v njej se spremlja čas stiskanja). Ko izdelovalec pice klikne izdelek na sledilniku, se vnosi v vseh teh tabelah posodobijo. Tabela naročil je splošna, vsebuje tudi vstavke ob sprejemu naročila, posodobitve iz drugih delov sistema in številne odčitke, na primer na TV-ju, ki visi v piceriji in strankam prikazuje dokončana naročila.
V obdobju boja z obremenitvami, ko je bilo vse in vse predpomnjeno in preneseno v asinhrono repliko baze, so te operacije s sledilnikom še naprej potekale v glavni bazi. Ne sme biti zamikov, podatki morajo biti ažurni, nesinhronizacija je nesprejemljiva.
Prav tako pomanjkanje lastnih tabel in indeksov na njih ni omogočalo pisanja bolj specifičnih poizvedb, prilagojenih njihovi uporabi. Na primer, morda bi bilo učinkovito, če ima sledilnik v tabeli naročil indeks za picerijo. Naročila picerije vedno odstranimo iz podatkovne baze sledilnika. Pri tem pa za prejem naročila ni tako pomembno, v katero picerijo spada, bolj pomembno je, katera stranka je to naročilo oddala. In pomeni, da je potreben indeks na stranki. Prav tako ni potrebno, da sledilnik shrani ID natisnjenega potrdila ali bonus promocij, povezanih z naročilom, v tabeli naročil. Te informacije niso zanimive za našo storitev sledenja. V skupni monolitni bazi podatkov so lahko tabele le kompromis med vsemi uporabniki. To je bil eden od prvotnih problemov.
BILO. Prvotna arhitektura je bila:
Tudi po ločitvi v ločene procese je večina kodne baze ostala skupna za različne storitve. Vse pod krmilniki je bilo eno in je živelo v istem skladišču. Uporabili smo skupne metode storitev, repozitorije, skupno bazo, v kateri so ležale skupne tabele.
Sledilnik raztovarjanja
Glavna težava sledilnika je, da morajo biti podatki sinhronizirani med različnimi zbirkami podatkov. To je tudi njegova glavna razlika od ločitve storitve Auth, naročilo in njegov status se lahko spremenita in morata biti prikazana v različnih storitvah.
Naročilo sprejmemo na blagajni Restavracije (to je storitev), v bazi se shrani v statusu "Sprejeto". Po tem bi moral priti do sledilnika, kjer bo še večkrat spremenil svoj status: iz »Kuhinja« v »Zapakirano«. Hkrati se lahko pri naročilu pojavijo zunanji vplivi blagajne ali vmesnika izmene. Statuse naročil z opisom bom podal v tabeli:
Shema spreminjanja statusov naročil je videti takole:
Statusi se med različnimi sistemi spreminjajo. In tukaj sledilnik ni končni sistem, v katerem so podatki zaprti. Videli smo več možnih pristopov za particioniranje v takem primeru:
- Vsa naročila združimo v eno storitev. V našem primeru ta možnost zahteva preveč storitev za delo z naročilom. Če bi se ustavili pri njem, bi dobili drugi monolit. Težave ne bi rešili.
- En sistem kliče drugega. Druga možnost je že bolj zanimiva. Toda z njim so možne verige klicev (), je povezljivost komponent večja, težje jo je upravljati.
- Organiziramo dogodke in vsaka služba prek teh dogodkov komunicira z drugo. Posledično je bila izbrana tretja možnost, po kateri vse storitve začnejo izmenjevati dogodke med seboj.
Dejstvo, da smo izbrali tretjo možnost, je pomenilo, da bo sledilnik imel svojo bazo in bo za vsako spremembo vrstnega reda o tem poslal dogodek, na katerega so naročene druge storitve in ki prav tako spada v glavno bazo. Za to smo potrebovali neko storitev, ki bi zagotavljala dostavo sporočil med storitvami.
Do takrat smo RabbitMQ že imeli v skladu, zato smo se dokončno odločili, da ga uporabimo kot posrednika sporočil. Diagram prikazuje prehod naročila iz Restavracijske blagajne skozi Sledilnik, kjer spremeni svoj status in prikaz na vmesniku Naročila upravitelja. POSTANI:
Pot naročila korak za korakom
Pot naročila se začne pri eni od storitev vira naročila. Tukaj je blagajna restavracije:
- Na blagajni je naročilo popolnoma pripravljeno in čas je, da ga pošljete v sledilnik. Dogodek, na katerega je naročen sledilnik, se vrže.
- Sledilnik, ki zase sprejme naročilo, ga shrani v lastno zbirko podatkov, s čimer naredi dogodek »Naročilo sprejeto s strani sledilnika« in ga pošlje v RMQ.
- Na vodilo dogodkov je na naročilo že naročenih več upravljavcev. Za nas je pomemben tisti, ki naredi sinhronizacijo z monolitno bazo.
- Upravljavec prejme dogodek, izbere iz njega podatke, ki so zanj pomembni: v našem primeru je to status naročila »Sprejel sledilnik« in posodobi svojo entiteto naročila v glavni bazi podatkov.
Če nekdo potrebuje naročilo iz monolitne tabele naročil, potem ga lahko prebere tudi od tam. Na primer, vmesnik Naročila v upravitelju izmene potrebuje to:
Vse druge storitve se lahko tudi naročijo na naročanje dogodkov iz sledilnika in jih uporabljajo zase.
Če se čez nekaj časa naročilo prevzame v delo, se njegov status najprej spremeni v njegovi bazi podatkov (baza sledilnika), nato pa se takoj ustvari dogodek "OrderIn Progress". Prav tako pride v RMQ, od koder se sinhronizira v monolitno bazo podatkov in dostavi drugim storitvam. Na poti se lahko pojavijo različne težave, več podrobnosti o njih najdete v poročilu Ženje Peškova .
Končna arhitektura po spremembah v Auth in Trackerju
Če povzamemo vmesni rezultat: Sprva sem imel idejo, da bi devetletno zgodovino sistema Dodo IS strnil v en članek. Želel sem na hitro in preprosto govoriti o stopnjah evolucije. Ko pa sem sedel za gradivo, sem ugotovil, da je vse veliko bolj zapleteno in zanimivo, kot se zdi.
Ko sem razmišljal o koristih (ali pomanjkanju le-teh) takega gradiva, sem prišel do zaključka, da je nenehen razvoj nemogoč brez polnih analov dogodkov, podrobnih retrospektiv in analiz mojih preteklih odločitev.
Upam, da vam je bilo koristno in zanimivo izvedeti o naši poti. Sedaj sem pred izbiro, kateri del sistema Dodo IS naj opišem v naslednjem članku: zapiši v komentar ali glasuj.
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
O katerem delu Dodo IS bi radi izvedeli v naslednjem članku?
-
24,1%Zgodnji monolit v Dodo IS (2011-2015)14
-
24,1%Prve težave in njihove rešitve (2015-2016)14
-
20,7%Pot na strani naročnika: fasada čez podstavek (2016-2017)12
-
36,2%Zgodovina pravih mikrostoritev (2018-2019)21
-
44,8%Kompletno razžaganje monolita in stabilizacija arhitekture26
-
29,3%O nadaljnjih načrtih za razvoj sistema17
-
19,0%Nočem vedeti ničesar o Dodo IS11
Glasovalo je 58 uporabnikov. 6 uporabnikov se je vzdržalo.
Vir: www.habr.com