Historia e Arkitekturës Dodo IS: Rruga e Zyrës së Prapave

Habr po ndryshon botën. Ne kemi bërë blog për më shumë se një vit. Rreth gjashtë muaj më parë morëm reagime mjaft logjike nga banorët e Khabrovsk: “Dodo, ti thua kudo se ke sistemin tënd. Çfarë lloj sistemi është ky? Dhe pse i duhet zinxhirit të picerisë?”

U ulëm dhe menduam dhe kuptuam që keni të drejtë. Ne po mundohemi të shpjegojmë gjithçka me gishta, por ajo del në copa të grisura dhe nuk ka askund përshkrim të plotë të sistemit. Kështu filloi një rrugëtim i gjatë për mbledhjen e informacionit, kërkimin e autorëve dhe shkrimin e një serie artikujsh rreth Dodo IS. Shkojme!

Mirënjohje: Faleminderit që ndatë komentet tuaja me ne. Falë tij, më në fund përshkruam sistemin, përpiluam një teknikodar dhe së shpejti do të nxjerrim një përshkrim të madh të proceseve tona. Pa ty do kishim ndenjur keshtu edhe 5 vjet te tjera.

Seria e artikujve "Çfarë është Dodo IS?" tregon për:

1. Monoliti i hershëm në Dodo IS (2011-2015). (Në vazhdim...)
2. Rruga e Backoffice: baza të veçanta dhe autobus. (Ti je ketu)
3. Rruga nga ana e klientit: fasada mbi bazën (2016-2017). (Në vazhdim...)
4. Historia e mikroshërbimeve reale. (2018-2019). (Në vazhdim...)
5. Përfundoi sharrimi i monolitit dhe stabilizimi i arkitekturës. (Në vazhdim...)

Nëse jeni të interesuar të mësoni diçka tjetër, shkruani në komente.

Opinion mbi përshkrimin kronologjik nga autori
Unë mbaj rregullisht një takim për punonjësit e rinj me temën "Arkitektura e Sistemit". Ne e quajmë atë "Hyrje në Dodo IS Architecture" dhe është pjesë e procesit të hyrjes për zhvilluesit e rinj. Duke folur në një formë ose në një tjetër për arkitekturën tonë, për veçoritë e saj, kam zhvilluar një qasje të caktuar historike ndaj përshkrimit.

Tradicionalisht, ne e shikojmë një sistem si një grup përbërësish (teknik ose të nivelit më të lartë), module biznesi që ndërveprojnë me njëri-tjetrin për të arritur një qëllim. Dhe ndërsa një pamje e tillë justifikohet për dizajn, ajo nuk është plotësisht e përshtatshme për përshkrim dhe kuptim. Ka disa arsye:

• Realiteti është i ndryshëm nga ai që është në letër. Jo gjithçka funksionon siç është planifikuar. Dhe ne jemi të interesuar se si gjithçka doli dhe funksionon në të vërtetë.
• Paraqitja e vazhdueshme e informacionit. Në fakt, ju mund të shkoni në mënyrë kronologjike nga fillimi në gjendjen aktuale.
• Nga e thjeshta në komplekse. Jo universale, por në rastin tonë është kështu. Arkitektura kaloi nga qasjet më të thjeshta në ato më komplekse. Shpesh, për shkak të ndërlikimeve, problemet e shpejtësisë dhe qëndrueshmërisë së zbatimit, si dhe dhjetëra prona të tjera nga lista e kërkesave jofunksionale (këtu flitet mirë për ndryshimin e kompleksitetit me kërkesat e tjera).

Në vitin 2011, arkitektura Dodo IS dukej kështu:

Deri në vitin 2020, ajo u bë pak më e ndërlikuar dhe u bë kështu:

Si ndodhi ky evolucion? Pse nevojiten pjesë të ndryshme të sistemit? Cilat vendime arkitekturore u morën dhe pse? Le të zbulojmë në këtë seri artikujsh.

Problemet e para të 2016: pse shërbimet duhet të largohen nga monoliti?

Artikujt e parë në seri do të jenë për shërbimet që ishin të parët që u ndanë nga monoliti. Për t'ju vënë në kontekst, do t'ju tregoj se çfarë problemesh kishim në sistem në fillim të vitit 2016, që duhej të merreshim me ndarjen e shërbimeve.

Një bazë e vetme e të dhënave MySql në të cilën të gjitha aplikacionet që ekzistonin në atë kohë në Dodo IS shkruan të dhënat e tyre. Pasojat ishin:

• Ngarkesa e rëndë (me 85% të kërkesave të lexuara).
• Baza po rritej. Për shkak të kësaj, kostoja dhe mbështetja u bënë problem.
• Pika e vetme e dështimit. Nëse një aplikacion që shkruante në bazën e të dhënave papritmas filloi ta bënte këtë në mënyrë më aktive, atëherë aplikacionet e tjera e ndjenë ndikimin.
• Joefikasiteti në ruajtje dhe pyetje. Shpesh të dhënat ruheshin në një strukturë që ishte e përshtatshme për disa skenarë, por jo për të tjerët. Indekset përshpejtojnë disa operacione, por mund të ngadalësojnë të tjerat.
• Disa nga problemet u zgjidhën me cache të bëra me nxitim dhe kopje të leximit në bazat e të dhënave (kjo do të diskutohet në një artikull të veçantë), por ato na lejuan vetëm të fitonim kohë dhe nuk e zgjidhën rrënjësisht problemin.

Problemi ishte prania e vetë monolitit. Pasojat ishin:

• Publikime unike dhe të rralla.
• Vështirësia qëndron në zhvillimin bashkëpunues të një numri të madh njerëzish.
• Pamundësia për të prezantuar teknologji të reja, korniza të reja dhe biblioteka.

Problemet me bazën dhe monolitin janë përshkruar shumë herë, për shembull, në kontekstin e përplasjeve në fillim të vitit 2018 (Bëhu si Munch, ose disa fjalë për borxhin teknik, Ditën kur Dodo u ndal. Skript asinkron и Historia e zogut Dodo nga familja Phoenix. Rënia e madhe e Dodo IS), kështu që nuk do të ndalem shumë. Më lejoni të them vetëm se ne donim të jepnim më shumë fleksibilitet gjatë zhvillimit të shërbimeve. Para së gjithash, kjo kishte të bënte me ata që ishin më të ngarkuarit dhe rrënjët në të gjithë sistemin - Auth dhe Tracker.

Rruga e zyrës së pasme: baza dhe autobus të ndara

Navigimi i kapitullit

1. Skema e monolitit 2016
2. Ne fillojmë të shkarkojmë monolitin: ndarja e Auth dhe Tracker
   
3. Çfarë bën Auth?
4. Nga vijnë ngarkesat?
5. Po shkarkon Auth
6. Çfarë bën Tracker?
7. Nga vijnë ngarkesat?
8. Shkarkimi i gjurmuesit

Skema e monolitit 2016

Këtu janë blloqet kryesore të monolitit Dodo IS 2016, dhe pak më poshtë është një përmbledhje e detyrave të tyre kryesore.

Arkë e dorëzimit. Kontabiliteti për korrierët, lëshimi i porosive për korrierët.
Qendra e kontaktit. Pranimi i porosive përmes operatorit.
Faqe. Faqet tona të internetit (dodopizza.ru, dodopizza.co.uk, dodopizza.by, etj.).
Autori. Shërbimi i autorizimit dhe autentifikimit për backoffice.
ndjekës. Gjurmues i porosive të kuzhinës. Shërbim për shënimin e statuseve të gatishmërisë gjatë përgatitjes së një porosie.
Arkë e restorantit. Marrja e porosive në një restorant, ndërfaqet e arkëtarit.
Eksport. Ngarkimi i raporteve në 1C për kontabilitet.
Alarmet dhe faturat. Komandat zanore në kuzhinë (për shembull, "Ka mbërritur pica e re") + printimi i faturave për korrierët.
Menaxher i ndërrimit. Ndërfaqet për punën e një menaxheri turni: lista e porosive, grafikët e produktivitetit, sjellja e punonjësve në turne.
Menaxher zyre. Ndërfaqet për punën e franshizave dhe menaxherëve: pritja e punonjësve, raporte për punën e picerisë.
Bordi i restorantit. Shfaqja e menyve në TV në piceri.
Admin. Cilësimet për një piceri specifike: meny, çmime, kontabilitet, kode promocionale, promovime, banderola për sitin, etj.
Llogaria personale e punonjësit. Oraret e punës së punonjësve, informacione për punonjësit.
Bordi i motivimit të kuzhinës. Një ekran i veçantë që varet në kuzhinë dhe tregon shpejtësinë e prodhuesve të picave.
Komunikim. Dërgimi i sms dhe email.
Ruajtja e skedarëve. Shërbimi i vet për marrjen dhe lëshimin e skedarëve statikë.

Përpjekjet e para për të zgjidhur problemet na ndihmuan, por ato ishin vetëm një pushim i përkohshëm. Nuk u bënë zgjidhje sistemore, ndaj ishte e qartë se diçka duhej bërë me bazat. Për shembull, ndajeni bazën e të dhënave të përgjithshme në disa më të specializuara.

Ne fillojmë të shkarkojmë monolitin: ndarja e Auth dhe Tracker

Shërbimet kryesore që më pas shkruan dhe lexuan nga baza e të dhënave më shumë se të tjerët:

1. Auth. Shërbimi i autorizimit dhe autentifikimit për backoffice.
2. Gjurmues. Gjurmues i porosive të kuzhinës. Shërbim për shënimin e statuseve të gatishmërisë gjatë përgatitjes së një porosie.

Çfarë bën Auth?

Auth është një shërbim përmes të cilit përdoruesit hyjnë në zyrën e pasme (ekziston një hyrje e veçantë e pavarur në anën e klientit). Gjithashtu në kërkesë përmendet për të siguruar që të drejtat e sakta të aksesit janë të pranishme dhe se këto të drejta nuk kanë ndryshuar që nga identifikimi i fundit. Nëpërmjet tij hyjnë pajisjet në piceri.

Për shembull, ne duam të hapim një ekran me statusin e porosive të përfunduara në televizorin e varur në sallë. Pastaj hapim auth.dodopizza.ru, zgjedhim "Hyrja si pajisje", shfaqet një kod që mund të futet në një faqe të veçantë në kompjuterin e menaxherit të ndërrimit, duke treguar llojin e pajisjes (pajisjes). Vetë televizori do të shkojë në ndërfaqen e dëshiruar të picerisë së tij dhe do të fillojë të shfaqë atje emrat e klientëve, porositë e të cilëve janë gati.

Nga vijnë ngarkesat?

Çdo përdorues i backoffice i regjistruar shkon në bazën e të dhënave për çdo kërkesë, në tabelën e përdoruesve, e tërheq përdoruesin prej andej përmes një pyetjeje sql dhe kontrollon nëse ai ka aksesin dhe të drejtat e nevojshme në këtë faqe.

Secila prej pajisjeve bën të njëjtën gjë vetëm me tabelën e pajisjes, duke kontrolluar rolin e saj dhe akseset e saj. Një numër i madh kërkesash për bazën e të dhënave kryesore çon në ngarkimin e saj dhe humbjen e burimeve të përgjithshme të bazës së të dhënave për këto operacione.

Po shkarkon Auth

Auth ka një domen të izoluar, domethënë, të dhënat për përdoruesit, hyrjet ose pajisjet hyjnë në shërbim (aktualisht në të ardhmen) dhe mbeten atje. Nëse dikush ka nevojë për to, ai do të shkojë në këtë shërbim për të dhëna.

ISHTE. Rrjedha e punës fillimisht ishte si kjo:

Do të doja të shpjegoja pak se si funksionoi:

1. Një kërkesë e jashtme vjen në backend (Asp.Net MVC atje), duke sjellë me vete një skedar sesioni, i cili përdoret për të marrë të dhënat e sesionit nga Redis(1). Ai ose përmban informacione rreth akseseve, dhe më pas qasja në kontrollues është e hapur (3,4), ose jo.
2. Nëse nuk ka akses, duhet të kaloni procedurën e autorizimit. Këtu, për thjeshtësi, tregohet si pjesë e shtegut në të njëjtin atribut, megjithëse ky është një kalim në faqen e hyrjes. Në rastin e një skenari pozitiv, ne do të marrim një seancë të plotësuar saktë dhe do të shkojmë te Backoffice Controller.
3. Nëse ka të dhëna, atëherë duhet t'i kontrolloni ato për rëndësinë në bazën e të dhënave të përdoruesit. A ka ndryshuar roli i tij, nuk duhet të lejohet në faqe tani? Në këtë rast, pas marrjes së seancës (1), duhet të shkoni drejtpërdrejt në bazën e të dhënave dhe të kontrolloni aksesin e përdoruesit duke përdorur shtresën logjike të vërtetimit (2). Tjetra, ose shkoni te faqja e hyrjes ose shkoni te kontrolluesi. Ky është një sistem i thjeshtë, por jo plotësisht standard.
4. Nëse të gjitha procedurat janë përfunduar, atëherë ne kalojmë më tej në logjikën në kontrollues dhe metoda.

Të dhënat e përdoruesit janë të ndara nga të gjitha të dhënat e tjera, ato ruhen në një tabelë të veçantë anëtarësimi, funksionet nga shtresa logjike AuthService mund të bëhen metoda API. Kufijtë e domenit përcaktohen mjaft qartë: përdoruesit, rolet e tyre, të dhënat e aksesit, lëshimi dhe revokimi i aksesit. Gjithçka duket sikur mund të zhvendoset në një shërbim të veçantë.

U BËHET. Kështu bënë:

Kjo qasje ka një sërë problemesh. Për shembull, thirrja e një metode brenda një procesi nuk është e njëjtë me thirrjen e një shërbimi të jashtëm nëpërmjet http. Vonesa, besueshmëria, mbështetshmëria dhe transparenca e operacionit janë krejtësisht të ndryshme. Andrey Morevsky foli më në detaje pikërisht për këto probleme në raportin e tij "50 hije të mikroshërbimeve".

Shërbimi i vërtetimit dhe bashkë me të edhe shërbimi i pajisjes përdoren për back office, pra për shërbimet dhe ndërfaqet e përdorura në prodhim. Vërtetimi për shërbimet e klientit (të tilla si një faqe interneti ose aplikacioni celular) ndodh veçmas pa përdorur Auth. Ndarja zgjati rreth një vit, dhe tani ne po punojmë përsëri në këtë temë, duke e transferuar sistemin në shërbime të reja të vërtetimit (me protokolle standarde).

Pse zgjati kaq shumë ndarja?
Kishte shumë probleme gjatë rrugës që na ngadalësuan:

1. Ne donim të transferonim të dhënat për përdoruesit, pajisjet dhe vërtetimin nga bazat e të dhënave të vendit në një. Për ta bërë këtë, na u desh të transferonim të gjitha tabelat dhe përdorimin nga identifikuesi int në identifikuesin global UUId (ne kemi ripunuar së fundi këtë kod Roman Bukin "Uuid - historia e madhe e një strukture të vogël" dhe projekt me burim të hapur primitivë). Ruajtja e të dhënave të përdoruesit (pasi ky është informacion personal) ka kufizimet e veta dhe për disa vende është e nevojshme që ato të ruhen veçmas. Por duhet të ketë një ID globale të përdoruesit.
2. Shumë tabela në bazën e të dhënave kanë informacion auditimi për përdoruesin që ka kryer operacionin. Kjo kërkonte një mekanizëm shtesë për të siguruar qëndrueshmëri.
3. Pas krijimit të shërbimeve API, pati një periudhë të gjatë dhe graduale transferimi në një sistem tjetër. Ndërprerësit duhej të ndodhnin pa probleme për përdoruesit dhe kërkonin punë manuale.

Skema për regjistrimin e një pajisjeje në një piceri:

Arkitektura e përgjithshme pas ndarjes së shërbimit Auth dhe Devices:

Shënim. Për vitin 2020, ne po punojmë për një version të ri të Auth, i cili bazohet në standardin e autorizimit OAuth 2.0. Ky standard është mjaft kompleks, por i dobishëm për zhvillimin e një shërbimi vërtetimi nga fundi në fund. Në artikullin "Hollësitë e autorizimit: përmbledhje e teknologjisë OAuth 2.0» ne Alexey Chernyaev u përpoqëm të flasim për standardin sa më thjesht dhe qartë që të jetë e mundur, në mënyrë që të kurseni kohë për ta studiuar atë.

Çfarë bën Tracker?

Tani për të dytin nga shërbimet e ngarkuara. Gjurmuesi kryen një rol të dyfishtë:

• Nga njëra anë, detyra e saj është t'u tregojë punonjësve në kuzhinë se cilat porosi janë aktualisht në proces, cilat produkte duhet të përgatiten tani.
• Nga ana tjetër, dixhitalizoni të gjitha proceset në kuzhinë.

Kur një produkt i ri (për shembull, pica) shfaqet në një porosi, ai shkon në stacionin e gjurmimit "Rolling". Në këtë stacion është një prodhues picash që merr një simite të madhësisë së kërkuar dhe e rrotullon, pas së cilës shënon në tabletin gjurmues që e ka përfunduar detyrën dhe e kalon bazën e brumit të mbështjellë në stacionin tjetër - "Mbushja" .

Atje, prodhuesi tjetër i picës e vendos sipër picën, më pas shënon në tabletë se ka përfunduar detyrën e tij dhe e vendos picën në furrë (ky është gjithashtu një stacion i veçantë që duhet të shënohet në tablet). Një sistem i tillë ishte i pranishëm që në fillim në Dodo dhe që nga fillimi i Dodo IS. Kjo ju lejon të gjurmoni dhe dixhitalizoni plotësisht të gjitha operacionet. Përveç kësaj, gjurmuesi sugjeron se si të përgatitet një produkt i caktuar, kryen çdo lloj produkti sipas skemave të veta të prodhimit, ruan kohën optimale të gatimit për produktin dhe gjurmon të gjitha operacionet në produkt.

Kështu duket ekrani i tabletit në stacionin gjurmues Raskatka.

Nga vijnë ngarkesat?

Çdo piceri ka rreth pesë tableta me një gjurmues. Në vitin 2016 kishim më shumë se 100 piceri (dhe tani janë më shumë se 600). Secili prej tabletave bën një kërkesë në backend çdo 10 sekonda dhe mbledh të dhëna nga tabela e porosive (lidhja me klientin dhe adresa), përbërja e porosisë (lidhja me produktin dhe treguesi i sasisë) dhe tabela e motivimit (ajo gjurmon koha e shtypjes). Kur një prodhues picash klikon mbi një produkt në gjurmues, të dhënat në të gjitha këto tabela përditësohen. Tabela e porosive është e përgjithshme; ajo përmban njëkohësisht futje kur pranoni një porosi, përditësime nga pjesë të tjera të sistemit dhe lexime të shumta, për shembull, në një televizor që varet në një piceri dhe tregon porositë e gatshme për klientët.

Gjatë periudhës së luftës me ngarkesat, kur gjithçka dhe të gjithë u ruajtën dhe u transferuan në një kopje asinkrone të bazës së të dhënave, këto operacione me gjurmuesin vazhduan të shkonin në bazën e të dhënave master. Këtu nuk duhet të ketë vonesë, të dhënat duhet të jenë të përditësuara, të pa sinkronizuara janë të papranueshme.

Gjithashtu, mungesa e tabelave dhe indekseve tona në to nuk na lejoi të shkruanim pyetje më specifike të përshtatura për përdorimin tonë. Për shembull, mund të jetë efektive që një gjurmues të ketë një indeks për një piceri në tabelën e porosive të tij. Ne fshijmë gjithmonë porositë e picerisë nga baza e të dhënave të gjurmuesit. Në të njëjtën kohë, për të pranuar një porosi, nuk është aq e rëndësishme se në cilën piceri bie, ajo që është më e rëndësishme është se cili klient e ka bërë këtë porosi. Kjo do të thotë që duhet të ketë një indeks për klientin. Gjithashtu nuk është e nevojshme që gjurmuesi të ruajë ID-në e faturës së printuar ose promovimet e bonusit që lidhen me porosinë në tabelën e porosive. Shërbimi ynë gjurmues nuk është i interesuar për këtë informacion. Në një bazë të dhënash të përbashkët monolit, tabelat mund të jenë vetëm një kompromis midis të gjithë përdoruesve. Ky ishte një nga problemet fillestare.

ISHTE. Fillimisht arkitektura ishte si kjo:

Edhe pasi u nda në procese të veçanta, shumica e bazës së kodit mbeti e përbashkët për shërbime të ndryshme. Gjithçka poshtë kontrollorëve ishte unifikuar dhe jetonte në një depo. U përdorën metoda të përbashkëta shërbimesh, depo dhe një bazë të dhënash të përbashkët që përmban tabela të përbashkëta.

Shkarkimi i gjurmuesit

Problemi kryesor me gjurmuesin është se të dhënat duhet të sinkronizohen midis bazave të të dhënave të ndryshme. Ky është gjithashtu ndryshimi kryesor i tij nga ndarja e shërbimit Auth; rendi dhe statusi i tij mund të ndryshojnë dhe duhet të shfaqen në shërbime të ndryshme.

Ne pranojmë porosi në arkën e restorantit (ky është një shërbim), ai ruhet në bazën e të dhënave në statusin "Pranuar". Pas kësaj, duhet të shkojë te gjurmuesi, ku do të ndryshojë statusin e tij edhe disa herë: nga "Kuzhina" në "E paketuar". Në këtë rast, me porosinë mund të ndodhin disa ndikime të jashtme nga ndërfaqja e Arkëtarit ose Shift Manager. Unë do të jap statuset e porosive me përshkrimet e tyre në tabelë:

Skema e ndryshimit të statusit të porosisë duket si kjo:

Statuset ndryshojnë ndërmjet sistemeve të ndryshme. Dhe këtu gjurmuesi nuk është sistemi përfundimtar në të cilin të dhënat janë të kyçura. Ne kemi parë disa qasje të mundshme për ndarje në një rast të tillë:

1. Ne i përqendrojmë të gjitha veprimet e porosisë në një shërbim. Në rastin tonë, ky opsion kërkon shumë shërbim për të përpunuar porosinë. Nëse do të kishim ndalur atje, do të kishim përfunduar me një monolit të dytë. Ne nuk do t'i kishim zgjidhur problemet.
2. Një sistem i bën thirrje një tjetri. Opsioni i dytë është më interesant. Por me të, zinxhirët e thirrjeve janë të mundshme (dështimet në kaskadë), lidhja e komponentëve është më e lartë dhe është më e vështirë për t'u menaxhuar.
3. Ne organizojmë evente dhe secili shërbim shkëmben me tjetrin përmes këtyre eventeve. Si rezultat, u zgjodh opsioni i tretë, sipas të cilit të gjitha shërbimet fillojnë të shkëmbejnë ngjarje me njëri-tjetrin.

Fakti që zgjodhëm opsionin e tretë do të thoshte që gjurmuesi do të kishte bazën e tij të të dhënave dhe për çdo ndryshim të renditjes do të dërgonte një ngjarje në lidhje me këtë, në të cilën do të abonoheshin shërbimet e tjera dhe që do të përfshihej gjithashtu në bazën e të dhënave master. Për ta bërë këtë, na duhej një shërbim që do të siguronte dërgimin e mesazheve midis shërbimeve.

Në atë kohë, ne kishim tashmë RabbitMQ në rafte, prandaj vendimi përfundimtar për ta përdorur atë si një ndërmjetës mesazhesh. Diagrami tregon kalimin e një porosie nga arkëtari i restorantit përmes Gjurmuesit, ku ndryshon statusin dhe shfaqjen e tij në ndërfaqen e porosive të menaxherit. U BËHET:

Rendit rrugën hap pas hapi
Rruga e porosisë fillon në një nga shërbimet e burimit të porosisë. Këtu është arkëtari i restorantit:

1. Porosia është plotësisht gati në Checkout dhe është koha për ta dërguar atë te gjurmuesi. Ngjarja në të cilën është abonuar gjurmuesi është hedhur.
2. Gjurmuesi, duke pranuar një porosi, e ruan atë në bazën e të dhënave të tij, duke bërë ngjarjen "Porosi u pranua nga gjurmuesi" dhe e dërgon atë në RMQ.
3. Disa mbajtës janë tashmë të abonuar në autobusin e ngjarjeve të personalizuara. Për ne është i rëndësishëm ai që sinkronizohet me bazën monolitike.
4. Trajtuesi merr ngjarjen, zgjedh prej saj të dhënat që janë të rëndësishme për të: në rastin tonë, ky është statusi i porosisë "Pranuar nga gjurmuesi" dhe përditëson entitetin e tij të porosisë në bazën e të dhënave kryesore.

Nëse dikush ka nevojë për një porosi në mënyrë specifike nga tabela e porosive monolitike, atëherë ai mund ta lexojë edhe nga atje. Për shembull, kjo është ajo që i nevojitet ndërfaqes Orders në Shift Manager:

Të gjitha shërbimet e tjera gjithashtu mund të abonohen për të porositur ngjarje nga gjurmuesi në mënyrë që t'i përdorin ato për veten e tyre.

Nëse pas njëfarë kohe një porosi merret në prodhim, statusi i tij fillimisht ndryshon në bazën e të dhënave të tij (baza e të dhënave Tracker), dhe më pas krijohet menjëherë ngjarja "OrderInWork". Ai gjithashtu futet në RMQ, nga ku sinkronizohet në një bazë të dhënash monolitike dhe dorëzohet në shërbime të tjera. Mund të ketë probleme të ndryshme përgjatë kësaj rruge; më shumë detaje rreth tyre mund të gjenden në raportin e Zhenya Peshkov në lidhje me detajet e zbatimit të Konsistencës eventuale në gjurmues.

Arkitektura përfundimtare pas ndryshimeve në Auth dhe Tracker

Për të përmbledhur: Fillimisht, pata idenë të paketoja historinë nëntëvjeçare të sistemit Dodo IS në një artikull. Doja të flisja shpejt dhe thjesht për fazat e evolucionit. Sidoqoftë, pasi u ula për të studiuar materialin, kuptova se gjithçka është shumë më komplekse dhe interesante nga sa duket.

Duke reflektuar mbi përfitimet (ose mungesën e tij) të një materiali të tillë, arrita në përfundimin se zhvillimi i vazhdueshëm është i pamundur pa kronika të plota të ngjarjeve, retrospektiva të hollësishme dhe analiza të vendimeve të së kaluarës.

Shpresoj se e keni gjetur të dobishme dhe interesante të mësoni rreth udhëtimit tonë. Tani jam përballur me një zgjedhje se cilën pjesë të sistemit Dodo IS të përshkruaj në artikullin vijues: shkruani në komente ose votoni.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

Për cilën pjesë të Dodo IS do të dëshironit të mësoni në artikullin vijues?

• 24,1%Monoliti i hershëm në Dodo IS (2011-2015)14

• 24,1%Problemet e para dhe zgjidhjet e tyre (2015-2016)14

• 20,7%Rruga e pjesës së klientit: fasada mbi bazë (2016-2017)12

• 36,2%Historia e mikroshërbimeve reale (2018-2019)21

• 44,8%Prerja e përfunduar e monolitit dhe stabilizimi i arkitekturës26

• 29,3%Rreth planeve të mëtejshme për zhvillimin e sistemit17

• 19,0%Nuk dua të di asgjë për Dodo IS11

58 përdorues votuan. 6 përdorues abstenuan.

Burimi: www.habr.com