Habras keičia pasaulį. Tinklaraštį rašome jau daugiau nei metus. Maždaug prieš šešis mėnesius iš chabrovičių gavome visiškai logišką atsiliepimą: „Dodo, tu visur sakai, kad turi savo sistemą. Ir kas tai per sistema? O kam to reikia picų tinklui?
Sėdėjome, galvojome ir supratome, kad tu teisus. Bandome viską išaiškinti ant pirštų, bet išeina suplėšyti gabaliukai ir niekur nėra pilno sistemos aprašymo. Taip prasidėjo ilgas informacijos rinkimo, autorių paieškos ir straipsnių ciklas apie Dodo IS rašymas. Eime!
Padėka: Dėkojame, kad pasidalinote atsiliepimais su mumis. Jo dėka mes pagaliau aprašėme sistemą, sudarėme techninį radarą ir netrukus išleisime didelį mūsų procesų aprašymą. Be jūsų būtume sėdėję dar 5 metus.
Straipsnių ciklas "Kas yra Dodo IS?" pasakoja apie:
- Ankstyvasis monolitas Dodo IS (2011-2015). (Vykdoma...)
- Back office kelias: atskiros bazės ir autobusas. (tu esi čia)
- Kliento pusės takas: fasadas virš pagrindo (2016-2017). (Vykdoma...)
- Tikrų mikropaslaugų istorija. (2018–2019 m.). (Vykdoma...)
- Baigtas monolito pjovimas ir architektūros stabilizavimas. (Vykdoma...)
Jei jus domina kažkas kita - rašykite komentaruose.
Autoriaus nuomonė dėl chronologinio aprašymo
Reguliariai rengiu susitikimą naujiems darbuotojams tema „Sistemos architektūra“. Mes tai vadiname „Dodo IS architektūros įvadu“ ir tai yra naujų kūrėjų priėmimo proceso dalis. Vienaip ar kitaip pasakodamas apie mūsų architektūrą, apie jos ypatybes, man yra gimęs tam tikras istorinis aprašymo požiūris.
Tradiciškai į sistemą žiūrime kaip į komponentų (techninių ar aukštesnio lygio) rinkinį, verslo modulius, kurie sąveikauja tarpusavyje, kad pasiektų kokį nors tikslą. Ir jei toks požiūris yra pagrįstas dizainui, jis nėra visiškai tinkamas aprašymui ir supratimui. Čia yra keletas priežasčių:
- Realybė skiriasi nuo to, kas yra popieriuje. Ne viskas pavyksta taip, kaip numatyta. Ir mus domina, kaip tai iš tikrųjų pasirodė ir veikia.
- Nuoseklus informacijos pateikimas. Tiesą sakant, galite pereiti chronologiškai nuo pradžios iki dabartinės būsenos.
- Nuo paprasto iki sudėtingo. Ne visuotinai, bet mūsų atveju taip. Architektūra nuo paprastesnių požiūrių perėjo prie sudėtingesnių. Dažnai dėl komplikacijų buvo išspręstos diegimo greičio ir stabilumo problemos, taip pat dešimtys kitų savybių iš nefunkcinių reikalavimų sąrašo ( gerai pasakyta apie sudėtingumo kontrastą su kitais reikalavimais).
2011 m. Dodo IS architektūra atrodė taip:
Iki 2020 m. ji tapo šiek tiek sudėtingesnė ir tapo tokia:
Kaip įvyko ši evoliucija? Kodėl reikalingos skirtingos sistemos dalys? Kokie architektūriniai sprendimai buvo priimti ir kodėl? Išsiaiškinkime šioje straipsnių serijoje.
Pirmosios 2016 metų problemos: kodėl tarnybos turėtų palikti monolitą
Pirmieji ciklo straipsniai bus apie paslaugas, kurios pirmosios atsiskyrė nuo monolito. Į kontekstą papasakosiu, kokių problemų turėjome sistemoje iki 2016 metų pradžios, kad teko susidurti su paslaugų atskyrimu.
Viena MySql duomenų bazė, kurioje visos tuo metu Dodo IS buvusios programos rašė savo įrašus. Pasekmės buvo:
- Didelė apkrova (85 % užklausų sudarė skaitymas).
- Bazė išaugo. Dėl šios priežasties jo kaina ir palaikymas tapo problema.
- Vienas nesėkmės taškas. Jei viena programa, rašanti į duomenų bazę, staiga pradėjo tai daryti aktyviau, kitos programos tai pajuto pačios.
- Neefektyvus saugojimas ir užklausos. Dažnai duomenys buvo saugomi tam tikroje struktūroje, kuri buvo patogi kai kuriems scenarijams, bet netinkama kitiems. Indeksai paspartina kai kurias operacijas, bet gali sulėtinti kitas.
- Kai kurias problemas pašalino paskubomis padarytos talpyklos ir skaitymo-reprodukcijos į bazes (tai bus atskiras straipsnis), tačiau jos tik leido laimėti laiko ir problemos iš esmės neišsprendė.
Problema buvo paties monolito buvimas. Pasekmės buvo:
- Pavieniai ir reti leidimai.
- Daugelio žmonių bendro vystymosi sunkumai.
- Nesugebėjimas įdiegti naujų technologijų, naujų sistemų ir bibliotekų.
Problemos su pagrindu ir monolitu buvo aprašytos daugybę kartų, pavyzdžiui, 2018 m. pradžioje įvykusių avarijų kontekste (, и ), todėl per daug nesigilinsiu. Tik pasakysiu, kad kurdami paslaugas norėjome suteikti daugiau lankstumo. Visų pirma, tai buvo susiję su tais, kurie buvo labiausiai įkelti ir šakniniai visoje sistemoje - Auth ir Tracker.
„Back Office“ kelias: atskiros bazės ir autobusas
Skyrius Navigacija
Monolitinė schema 2016 m
Čia yra pagrindiniai Dodo IS 2016 monolito blokai, o žemiau yra jų pagrindinių užduočių nuorašas.
Pristatymas kasoje. Kurjerių apskaita, užsakymų išdavimas kurjeriams.
Kontaktų centras. Užsakymų priėmimas per operatorių.
vieta. Mūsų svetainės (dodopizza.ru, dodopizza.co.uk, dodopizza.by ir kt.).
Aut. Autorizacijos ir autentifikavimo paslauga „back office“.
Tracker. Užsakymų sekiklis virtuvėje. Pasirengimo būsenų žymėjimo paslauga rengiant užsakymą.
Restorano kasa. Užsakymų priėmimas restorane, kasininkų sąsajos.
Eksportuoti. Ataskaitų įkėlimas 1C apskaitai.
Pranešimai ir sąskaitos faktūros. Balso komandos virtuvėje (pvz. „Atkeliavo nauja pica“) + kurjeriams sąskaitos faktūros spausdinimas.
Pamainos vadovas. Pamainos vadovo darbo sąsajos: užsakymų sąrašas, veiklos grafikai, darbuotojų perkėlimas į pamainą.
Biuro vadovas. Franšizės gavėjo ir vadovo darbo sąsajos: darbuotojų priėmimas, ataskaitos apie picerijos darbą.
Restorano rezultatų suvestinė. Meniu rodymas televizoriuose picerijose.
admin. Nustatymai konkrečioje picerijoje: meniu, kainos, apskaita, reklamos kredito kodai, akcijos, interneto reklamjuostės ir kt.
Darbuotojo asmeninė sąskaita. Darbuotojų darbo grafikai, informacija apie darbuotojus.
Virtuvės motyvacijos lenta. Atskiras ekranas, kuris kabo virtuvėje ir rodo picų kūrėjų greitį.
Bendravimas. Siunčiu sms ir el.
Failų saugykla. Nuosavo statinių failų priėmimo ir išdavimo paslauga.
Pirmieji bandymai spręsti problemas mums padėjo, tačiau tai buvo tik laikinas atokvėpis. Sisteminiais sprendimais jie netapo, tad buvo aišku, kad su bazėmis reikia kažką daryti. Pavyzdžiui, padalyti bendrą duomenų bazę į keletą labiau specializuotų.
Monolito iškrovimo pradžia: autentifikavimo ir sekimo atskyrimas
Pagrindinės paslaugos, kurios vėliau įrašė ir skaito iš duomenų bazės daugiau nei kitos:
- Aut. Autorizacijos ir autentifikavimo paslauga „back office“.
- Tracker. Užsakymų sekiklis virtuvėje. Pasirengimo būsenų žymėjimo paslauga rengiant užsakymą.
Ką daro Auth?
Auth yra paslauga, per kurią vartotojai prisijungia prie „back office“ (kliento pusėje yra atskiras nepriklausomas įėjimas). Prašyme taip pat raginama įsitikinti, ar yra reikiamos prieigos teisės ir ar šios teisės nepasikeitė nuo paskutinio prisijungimo. Per ją įrenginiai patenka į piceriją.
Pavyzdžiui, salėje kabančiame televizoriuje norime atidaryti ekraną su įvykdytų užsakymų būsenomis. Tada atidarome auth.dodopizza.ru, pasirenkame „Prisijungti kaip įrenginį“, pasirodo kodas, kurį galima įvesti specialiame pamainos vadovo kompiuterio puslapyje, nurodant įrenginio (įrenginio) tipą. Pats televizorius persijungs į norimą picerijos sąsają ir pradės rodyti klientų, kurių užsakymai ten paruošti, vardus.
Iš kur kroviniai?
Kiekvienas prisijungęs „back office“ vartotojas eina į duomenų bazę, prie kiekvienos užklausos vartotojų lentelės, ištraukia vartotoją per sql užklausą ir patikrina, ar jis turi reikiamą prieigą ir teises į šį puslapį.
Kiekvienas įrenginys tą patį daro tik su įrenginių lentele, tikrindamas savo vaidmenį ir prieigą. Dėl didelio užklausų skaičiaus pagrindinei duomenų bazei ji įkeliama ir eikvojami bendros duomenų bazės ištekliai šioms operacijoms.
Iškrovimo autent
Auth turi izoliuotą domeną, tai yra, duomenys apie vartotojus, prisijungimus ar įrenginius patenka į paslaugą (kol kas) ir ten lieka. Jei kam jų prireiks, jis kreipsis į šią tarnybą duomenų.
TAI BUVO. Pradinė darbo schema buvo tokia:
Norėčiau šiek tiek paaiškinti, kaip tai veikė:
- Užklausa iš išorės ateina į backend (yra Asp.Net MVC), atsineša sesijos slapuką, kuris naudojamas sesijos duomenims gauti iš Redis(1). Jame arba yra informacija apie prieigas, tada prieiga prie valdiklio yra atidaryta (3,4, XNUMX), arba ne.
- Jei prieigos nėra, turite atlikti leidimo procedūrą. Čia, siekiant paprastumo, jis rodomas kaip kelio dalis tame pačiame atribute, nors tai yra perėjimas į prisijungimo puslapį. Esant teigiamam scenarijui, gausime teisingai užbaigtą seansą ir eisime į „Backoffice Controller“.
- Jei yra duomenų, turite patikrinti jų tinkamumą vartotojų bazėje. Ar pasikeitė jo vaidmuo, ar dabar jo negalima leisti į puslapį? Tokiu atveju, gavus seansą (1), reikia eiti tiesiai į duomenų bazę ir patikrinti vartotojo prieigą naudojant autentifikavimo logikos sluoksnį (2). Tada eikite į prisijungimo puslapį arba eikite į valdiklį. Tokia paprasta sistema, bet ne visai standartinė.
- Jei visos procedūros praeinamos, toliau praleidžiame valdiklių ir metodų logiką.
Vartotojo duomenys yra atskirti nuo visų kitų duomenų, jie saugomi atskiroje narystės lentelėje, funkcijos iš AuthService loginio sluoksnio gali tapti api metodais. Gana aiškiai apibrėžtos domenų ribos: vartotojai, jų vaidmenys, prieigos duomenys, prieigos suteikimas ir atšaukimas. Viskas atrodo taip, kad būtų galima išvežti į atskirą servisą.
TAPTI. Taigi jie padarė:
Šis požiūris turi daug problemų. Pavyzdžiui, iškviesti metodą procese nėra tas pats, kas iškviesti išorinę paslaugą per http. Latencija, patikimumas, prižiūrimumas, operacijos skaidrumas yra visiškai skirtingi. Andrejus Morevskis plačiau apie tokias problemas kalbėjo savo pranešime. .
Autentifikavimo paslauga, o kartu ir įrenginių paslauga, naudojama „back office“, tai yra, gamyboje naudojamoms paslaugoms ir sąsajoms. Klientų paslaugų (pvz., svetainės ar programos mobiliesiems) autentifikavimas atliekamas atskirai, nenaudojant autentifikavimo. Atskyrimas užtruko apie metus, o dabar vėl užsiimame šia tema, perkeldami sistemą į naujas autentifikavimo paslaugas (su standartiniais protokolais).
Kodėl išsiskyrimas užtruko taip ilgai?
Kelyje buvo daug problemų, kurios mus sulėtino:
- Norėjome perkelti naudotojo, įrenginio ir autentifikavimo duomenis iš konkrečios šalies duomenų bazių į vieną. Norėdami tai padaryti, turėjome išversti visas lenteles ir naudojimą iš int identifikatoriaus į visuotinį UUId identifikatorių (neseniai perdarytas šis kodas ir atvirojo kodo projektas ). Vartotojo duomenų saugojimas (kadangi tai yra asmeninė informacija) turi savo apribojimų ir kai kuriose šalyse juos būtina saugoti atskirai. Tačiau vartotojo visuotinis ID turi būti.
- Daugelyje duomenų bazės lentelių yra audito informacija apie operaciją atlikusį vartotoją. Tam reikėjo papildomo nuoseklumo mechanizmo.
- Sukūrus api paslaugas, buvo ilgas ir laipsniškas perėjimo prie kitos sistemos laikotarpis. Perjungimas turėjo būti sklandus vartotojams ir reikalauti rankinio darbo.
Įrenginio registravimo picerijoje schema:
Bendroji architektūra po autentifikavimo ir įrenginių paslaugos išskleidimo:
Atkreipti dėmesį. 2020 m. dirbame su nauja Auth versija, pagrįsta OAuth 2.0 prieigos standartu. Šis standartas yra gana sudėtingas, tačiau jis yra naudingas kuriant perdavimo autentifikavimo paslaugą. Straipsnyje "» Aleksejus Černiajevas stengėmės kuo paprasčiau ir aiškiau papasakoti apie standartą, kad sutaupytumėte laiko jį studijuojant.
Ką veikia Tracker?
Dabar apie antrą iš įkeltų paslaugų. Stebėtojas atlieka dvigubą vaidmenį:
- Viena vertus, jos užduotis – parodyti darbuotojams virtuvėje, kokie užsakymai šiuo metu veikia, kokius produktus reikia virti dabar.
- Kita vertus, suskaitmeninti visus virtuvėje vykstančius procesus.
Kai užsakyme atsiranda naujas produktas (pavyzdžiui, pica), jis patenka į „Rolling out tracker“ stotį. Šioje stotelėje yra picų gamintojas, kuris paima reikiamo dydžio bandelę ir ją iškočioja, po to sekimo planšetėje pažymi, kad atliko savo užduotį ir perkelia iškočiotą tešlos pagrindą į kitą stotį - „Iniciacija“. .
Ten kitas picos gamintojas užpildo picą, tada planšetėje pažymi, kad atliko savo užduotį ir įdeda picą į orkaitę (tai taip pat yra atskira stotelė, kurią reikia pažymėti planšetėje). Tokia sistema buvo nuo pat Dodo pradžios ir nuo pat Dodo IS egzistavimo pradžios. Tai leidžia visiškai sekti ir skaitmeninti visas operacijas. Be to, seklys siūlo, kaip gaminti konkretų produktą, vadovauja kiekvienos rūšies gaminiui pagal jo gamybos schemas, išsaugo optimalų gaminio gaminimo laiką ir seka visas su gaminiu susijusias operacijas.
Taip atrodo planšetinio kompiuterio ekranas seklio „Raskatka“ stotyje
Iš kur kroviniai?
Kiekvienoje picerijoje yra maždaug penkios tabletės su sekikliu. 2016 metais turėjome daugiau nei 100 picerijų (o dabar jau daugiau nei 600). Kiekviena planšetė kartą per 10 sekundžių pateikia užklausą atgalinei sistemai ir nubraukia duomenis iš užsakymų lentelės (ryšys su klientu ir adresas), užsakymo sudėties (ryšis su preke ir kiekio nurodymas), motyvacijos apskaitos lentelės ( joje sekamas spaudimo laikas). Picų gamintojui spustelėjus produktą sekimo priemonėje, įrašai visose šiose lentelėse atnaujinami. Užsakymų lentelė yra bendra, joje taip pat yra intarpų priimant užsakymą, naujinimai iš kitų sistemos dalių ir daugybė rodmenų, pavyzdžiui, televizoriuje, kuris kabo picerijoje ir klientams rodo baigtus užsakymus.
Kovos su apkrovomis laikotarpiu, kai viskas ir viskas buvo saugoma talpykloje ir perkelta į asinchroninę bazės kopiją, šios operacijos su sekikliu ir toliau vykdavo į pagrindinę bazę. Neturėtų būti jokio vėlavimo, duomenys turi būti atnaujinti, nesinchronizavimas yra nepriimtinas.
Taip pat nuosavų lentelių ir rodyklių trūkumas neleido rašyti konkretesnių jų naudojimui pritaikytų užklausų. Pavyzdžiui, gali būti efektyvu, kad sekimo priemonė užsakymų lentelėje turėtų picerijos indeksą. Picerijų užsakymus visada pašaliname iš sekimo duomenų bazės. Tuo pačiu, norint gauti užsakymą, ne taip svarbu, į kokią piceriją jis patenka, svarbiau, kuris klientas padarė šį užsakymą. Ir reiškia, kad kliento indeksas yra būtinas. Taip pat nebūtina, kad stebėjimo priemonė užsakymų lentelėje saugotų atspausdinto kvito ar premijų akcijų, susijusių su užsakymu, ID. Ši informacija mūsų sekimo tarnybai nedomina. Bendroje monolitinėje duomenų bazėje lentelės gali būti tik visų vartotojų kompromisas. Tai buvo viena iš pirminių problemų.
TAI BUVO. Originali architektūra buvo:
Net ir išskaidžius į atskirus procesus, didžioji kodo bazės dalis išliko bendra skirtingoms paslaugoms. Viskas, kas buvo žemiau valdiklių, buvo viena ir gyveno toje pačioje saugykloje. Naudojome bendrus paslaugų metodus, saugyklas, bendrą bazę, kurioje gulėjo bendros lentelės.
Tracker iškrovimas
Pagrindinė sekimo įrenginio problema yra ta, kad duomenys turi būti sinchronizuojami tarp skirtingų duomenų bazių. Tai taip pat yra pagrindinis jos skirtumas nuo autentifikavimo paslaugos atskyrimo, užsakymas ir jo būsena gali keistis ir turėtų būti rodomi įvairiose paslaugose.
Užsakymą priimame Restorano Kasoje (tai paslauga), jis saugomas duomenų bazėje statusu „Priimta“. Po to jis turėtų patekti į sekiklį, kur dar kelis kartus pakeis savo statusą: iš „Virtuvė“ į „Supakuota“. Tuo pačiu metu su užsakymu gali atsirasti tam tikrų išorinių poveikių iš Kasos arba Shift Manager sąsajos. Lentelėje pateiksiu užsakymų būsenas su jų aprašymu:
Užsakymo būsenų keitimo schema atrodo taip:
Būsenos keičiasi tarp skirtingų sistemų. Ir čia trackeris nėra galutinė sistema, kurioje duomenys yra uždaryti. Matėme kelis galimus skaidymo būdus tokiu atveju:
- Visus užsakymo veiksmus sutelkiame į vieną paslaugą. Mūsų atveju, norint dirbti su užsakymu, ši parinktis reikalauja per daug paslaugų. Jei sustotume ties juo, gautume antrą monolitą. Mes problemos neišspręstume.
- Viena sistema skambina kitai. Antras variantas jau įdomesnis. Tačiau su juo galimos skambučių grandinės (), komponentų jungiamumas didesnis, jį sunkiau valdyti.
- Organizuojame renginius, per šiuos renginius kiekviena tarnyba bendrauja su kita. Dėl to buvo pasirinktas trečiasis variantas, pagal kurį visos tarnybos pradeda keistis įvykiais.
Tai, kad pasirinkome trečią variantą, reiškė, kad trackeris turės savo duomenų bazę, o kiekvienam užsakymo pakeitimui atsiųs įvykį apie tai, kurį užsiprenumeruoja kitos paslaugos ir kuris taip pat patenka į pagrindinę duomenų bazę. Tam mums reikėjo kokios nors paslaugos, kuri užtikrintų pranešimų siuntimą tarp tarnybų.
Iki to laiko mes jau turėjome RabbitMQ, todėl buvo priimtas galutinis sprendimas naudoti jį kaip pranešimų tarpininką. Diagramoje parodytas užsakymo perėjimas iš restorano kasos per Tracker, kur pakeičiama jo būsena ir rodomas vadybininko užsakymų sąsajoje. TAPTI:
Užsisakykite kelią žingsnis po žingsnio
Užsakymo kelias prasideda vienoje iš užsakymo šaltinio paslaugų. Štai restorano kasininkė:
- Kasoje užsakymas yra visiškai paruoštas ir laikas išsiųsti jį į sekiklį. Įvykis, kuriam prenumeruojamas seklys, yra išmestas.
- Stebėtojas, priimdamas užsakymą sau, išsaugo jį savo duomenų bazėje, padarydamas įvykį „Užsakymas priimtas sekimo“ ir išsiųsdamas RMQ.
- Vieno užsakymo renginių magistralę jau užsiprenumeravo keli tvarkytojai. Mums svarbus tas, kuris atlieka sinchronizaciją su monolitine baze.
- Valdytojas gauna įvykį, atrenka iš jo jam reikšmingus duomenis: mūsų atveju tokia yra užsakymo būsena „Priimta Stebėtojo“ ir atnaujina jo užsakymo objektą pagrindinėje duomenų bazėje.
Jei kam reikia užsakymo iš monolitinių stalų užsakymų, tai galite perskaityti ir iš ten. Pavyzdžiui, „Shift Manager“ užsakymų sąsajai reikia:
Visos kitos paslaugos taip pat gali užsiprenumeruoti įvykius iš stebėjimo priemonės, kad galėtų jais naudotis.
Jei po kurio laiko užsakymas pradedamas veikti, tada jo būsena pirmiausia pasikeičia jo duomenų bazėje (Tracker duomenų bazėje), o tada iškart sugeneruojamas įvykis „OrderIn Progress“. Jis taip pat patenka į RMQ, iš kur yra sinchronizuojamas monolitinėje duomenų bazėje ir pristatomas į kitas paslaugas. Kelyje gali kilti įvairių problemų, daugiau informacijos apie jas rasite Ženios Peškovo pranešime .
Galutinė architektūra po Auth ir Tracker pakeitimų
Apibendrinant tarpinį rezultatą: Iš pradžių man kilo mintis devynerių metų Dodo IS sistemos istoriją sutalpinti į vieną straipsnį. Norėjau greitai ir paprastai pakalbėti apie evoliucijos etapus. Tačiau atsisėdusi prie medžiagos supratau, kad viskas yra daug sudėtingiau ir įdomiau, nei atrodo.
Mąstydamas apie tokios medžiagos naudą (ar jos nebuvimą), priėjau prie išvados, kad nuolatinis tobulėjimas neįmanomas be pilnaverčių įvykių metraščių, išsamių retrospektyvų ir mano praeities sprendimų analizės.
Tikiuosi, kad jums buvo naudinga ir įdomu sužinoti apie mūsų kelią. Dabar turiu pasirinkimą, kurią Dodo IS sistemos dalį aprašyti kitame straipsnyje: rašyk komentaruose arba balsuok.
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Apie kokią Dodo IS dalį norėtumėte sužinoti kitame straipsnyje?
-
24,1%Ankstyvasis monolitas Dodo IS (2011-2015)14
-
24,1%Pirmosios problemos ir jų sprendimai (2015-2016)14
-
20,7%Kliento pusės kelias: fasadas per pagrindą (2016-2017)12
-
36,2%Tikrų mikropaslaugų istorija (2018-2019)21
-
44,8%Baigtas monolito pjovimas ir architektūros stabilizavimas26
-
29,3%Apie tolimesnius sistemos plėtros planus17
-
19,0%Nenoriu nieko žinoti apie Dodo IS11
Balsavo 58 vartotojų. 6 vartotojai susilaikė.
Šaltinis: www.habr.com