Habr ændrer verden. Vi har blogget i over et år nu. For omkring seks måneder siden modtog vi en fuldstændig logisk tilbagemelding fra Khabrovites: "Dodo, du siger overalt, at du har dit eget system. Og hvad er dette system? Og hvorfor har en pizzakæde brug for det?
Vi sad, tænkte og indså, at du har ret. Vi forsøger at forklare alt på fingrene, men det kommer ud i iturevne stykker og ingen steder er der en komplet beskrivelse af systemet. Således begyndte en lang rejse med at indsamle information, søge efter forfattere og skrive en række artikler om Dodo IS. Lad os gå!
Tak: Tak fordi du deler din feedback med os. Takket være ham beskrev vi endelig systemet, kompilerede en teknisk radar og vil snart udrulle en stor beskrivelse af vores processer. Uden jer havde vi siddet der i yderligere 5 år.
Artikelserie "Hvad er Dodo IS?" fortæller om:
- Tidlig monolit i Dodo IS (2011-2015). (I gang...)
- Back office-stien: separate baser og bus. (du er her)
- Bygherrens sidesti: facade over basen (2016-2017). (I gang...)
- Historien om rigtige mikrotjenester. (2018-2019). (I gang...)
- Færdig savning af monolitten og stabilisering af arkitekturen. (I gang...)
Hvis du er interesseret i at vide noget andet - skriv i kommentarerne.
Udtalelse om den kronologiske beskrivelse fra forfatteren
Jeg holder løbende et møde for nye medarbejdere om emnet "Systemarkitektur". Vi kalder det "Intro til Dodo IS Architecture", og det er en del af onboarding-processen for nye udviklere. Ved at fortælle i en eller anden form om vores arkitektur, om dens træk, har jeg født en vis historisk tilgang til beskrivelsen.
Traditionelt ser vi på systemet som et sæt af komponenter (tekniske eller højere niveau), forretningsmoduler, der interagerer med hinanden for at nå et eller andet mål. Og hvis en sådan udsigt er berettiget til design, så er den ikke helt egnet til beskrivelse og forståelse. Der er flere grunde her:
- Virkeligheden er anderledes end på papiret. Ikke alt fungerer efter hensigten. Og vi er interesserede i, hvordan det rent faktisk blev og fungerer.
- Konsekvent præsentation af information. Faktisk kan du gå kronologisk fra begyndelsen til den nuværende tilstand.
- Fra simpelt til komplekst. Ikke universelt, men i vores tilfælde er det det. Arkitekturen bevægede sig fra enklere tilgange til mere komplekse. Ofte gennem komplikationer blev problemer med implementeringshastighed og stabilitet løst, såvel som snesevis af andre egenskaber fra listen over ikke-funktionelle krav ( godt fortalt om kontrasterende kompleksitet med andre krav).
I 2011 så Dodo IS-arkitekturen sådan ud:
I 2020 er det blevet lidt mere kompliceret og er blevet sådan her:
Hvordan fandt denne udvikling sted? Hvorfor er der behov for forskellige dele af systemet? Hvilke arkitektoniske beslutninger blev truffet og hvorfor? Lad os finde ud af det i denne serie af artikler.
De første problemer i 2016: hvorfor skulle tjenester forlade monolitten
De første artikler fra cyklussen vil handle om de tjenester, der var de første til at adskille fra monolitten. For at sætte dig i kontekst vil jeg fortælle dig, hvilke problemer vi havde i systemet i begyndelsen af 2016, at vi skulle håndtere adskillelse af tjenester.
En enkelt MySql-database, hvor alle applikationer, der eksisterede på det tidspunkt i Dodo IS, skrev deres optegnelser. Konsekvenserne var:
- Tung belastning (med 85 % af anmodningerne udgjorde læsning).
- Basen er vokset. På grund af dette blev dets omkostninger og support et problem.
- Enkelt point of failure. Hvis en applikation, der skriver til databasen, pludselig begyndte at gøre det mere aktivt, så mærkede andre applikationer det på sig selv.
- Ineffektivitet i opbevaring og forespørgsler. Ofte blev dataene gemt i en struktur, der var praktisk for nogle scenarier, men ikke egnet til andre. Indekser fremskynder nogle operationer, men kan bremse andre.
- Nogle af problemerne blev fjernet af hastigt fremstillede caches og læsereplikaer til baserne (dette vil være en separat artikel), men de tillod dem kun at vinde tid og løste ikke grundlæggende problemet.
Problemet var tilstedeværelsen af selve monolitten. Konsekvenserne var:
- Single og sjældne udgivelser.
- Svært ved fælles udvikling af et stort antal mennesker.
- Manglende evne til at bringe nye teknologier, nye rammer og biblioteker ind.
Problemer med basen og monolitten er blevet beskrevet mange gange, for eksempel i forbindelse med nedbrud i begyndelsen af 2018 (, и ), så jeg vil ikke dvæle for meget. Lad mig bare sige, at vi ønskede at give mere fleksibilitet, når vi udviklede tjenester. Først og fremmest vedrørte dette dem, der var mest indlæst og root i hele systemet - Auth og Tracker.
Back Office-stien: Separate baser og bus
Kapitel Navigation
Monolith ordning 2016
Her er hovedblokkene i Dodo IS 2016-monolitten, og lige nedenfor er en udskrift af deres hovedopgaver.
Kasserer levering. Regnskab for kurerer, udstedelse af ordrer til kurerer.
Kontakt center. Accept af ordrer gennem operatøren.
Webstedet. Vores hjemmesider (dodopizza.ru, dodopizza.co.uk, dodopizza.by osv.).
Auth. Autorisations- og autentificeringsservice for backoffice.
Трекер. Bestil tracker i køkkenet. Service til markering af klarhedsstatus ved udarbejdelse af en ordre.
Restaurantens kasse. Modtagelse af bestillinger i en restaurant, kassegrænseflader.
eksport. Upload af rapporter i 1C til regnskab.
Meddelelser og fakturaer. Stemmekommandoer i køkkenet (f.eks. “Ny pizza ankommet”) + fakturaudskrivning for kurerer.
Skifteleder. Grænseflader til vagtlederens arbejde: ordreliste, præstationsgrafer, overflytning af medarbejdere til skiftet.
Kontorchef. Grænseflader for franchisetagerens og lederens arbejde: modtagelse af medarbejdere, rapporter om pizzeriaets arbejde.
Restaurant resultattavle. Menuvisning på tv i pizzeriaer.
admin. Indstillinger i et bestemt pizzeria: menu, priser, regnskab, kampagnekoder, kampagner, hjemmesidebannere mv.
Medarbejders personlige konto. Arbejdsplaner for medarbejdere, information om medarbejdere.
Køkken Motivation Board. En separat skærm, der hænger i køkkenet og viser pizzabrødrenes hastighed.
Kommunikation. Sender sms og mail.
FileStorage. Egen service til modtagelse og udsendelse af statiske filer.
De første forsøg på at løse problemerne hjalp os, men de var kun et midlertidigt pusterum. De blev ikke til systemløsninger, så det var klart, at der skulle gøres noget med baserne. For eksempel at opdele den generelle database i flere mere specialiserede.
Begynder at fjerne monolitten: Auth and Tracker Separation
De vigtigste tjenester, der derefter optog og læste fra databasen mere end andre:
- Auth. Autorisations- og autentificeringsservice for backoffice.
- Tracker. Bestil tracker i køkkenet. Service til markering af klarhedsstatus ved udarbejdelse af en ordre.
Hvad laver Auth?
Auth er en tjeneste, hvorigennem brugere logger ind på backoffice (der er en separat uafhængig indgang på klientsiden). Det opfordres også til i anmodningen at sikre sig, at de nødvendige adgangsrettigheder er til stede, og at disse rettigheder ikke er ændret siden sidste login. Gennem det kommer enheder ind i pizzeriaet.
For eksempel vil vi åbne et display med status for færdige ordrer på tv'et, der hænger i hallen. Derefter åbner vi auth.dodopizza.ru, vælg "Login som en enhed", en kode vises, der kan indtastes på en speciel side på skiftlederens computer, der angiver typen af enhed (enhed). Selve tv'et skifter til den ønskede grænseflade på sit pizzeria og begynder at vise navnene på kunder, hvis ordrer er klar der.
Hvor er belastningerne fra?
Hver logget ind bruger af backoffice går til databasen, til brugertabellen for hver anmodning, trækker brugeren ud gennem en sql-forespørgsel og tjekker, om han har den nødvendige adgang og rettigheder til denne side.
Hver af enhederne gør kun det samme med enhedstabellen og kontrollerer dens rolle og adgang. Et stort antal anmodninger til masterdatabasen fører til dens indlæsning og spild af ressourcer i den fælles database til disse operationer.
Aflæsning Auth
Auth har et isoleret domæne, det vil sige, at data om brugere, logins eller enheder kommer ind i tjenesten (indtil videre) og forbliver der. Hvis nogen har brug for dem, vil han gå til denne service for at få data.
VAR. Den oprindelige arbejdsplan var som følger:
Jeg vil gerne forklare lidt hvordan det fungerede:
- En anmodning udefra kommer til backend (der er Asp.Net MVC), medbringer en sessionscookie, som bruges til at hente sessionsdata fra Redis(1). Den indeholder enten information om adgange, og så er adgangen til controlleren åben (3,4), eller ej.
- Hvis der ikke er adgang, skal du gennemgå godkendelsesproceduren. Her er det for nemheds skyld vist som en del af stien i samme attribut, selvom det er en overgang til login-siden. I tilfælde af et positivt scenarie får vi en korrekt gennemført session og går til Backoffice-controlleren.
- Hvis der er data, så skal du tjekke det for relevans i brugerbasen. Har hans rolle ændret sig, skal han ikke have lov på siden nu? I dette tilfælde, efter at have modtaget sessionen (1), skal du gå direkte til databasen og kontrollere brugerens adgang ved hjælp af godkendelseslogiklaget (2). Dernæst enten til login-siden eller gå til controlleren. Sådan et simpelt system, men ikke helt standard.
- Hvis alle procedurer er bestået, så springer vi videre i logikken i controllere og metoder.
Brugerdata er adskilt fra alle andre data, de gemmes i en separat medlemstabel, funktioner fra AuthService-logiklaget kan meget vel blive til api-metoder. Domænegrænser er defineret ganske klart: brugere, deres roller, adgangsdata, tildeling og tilbagekaldelse af adgang. Alt ser ud, så det kan tages ud i en separat service.
BLIVE. Så de gjorde:
Denne tilgang har en række problemer. For eksempel er det ikke det samme at kalde en metode inde i en proces som at kalde en ekstern tjeneste via http. Latency, pålidelighed, vedligeholdelse, gennemsigtighed af operationen er helt anderledes. Andrey Morevskiy talte mere detaljeret om sådanne problemer i sin rapport. .
Autentificeringstjenesten og dermed enhedstjenesten bruges til backoffice, det vil sige tjenester og grænseflader, der bruges i produktionen. Godkendelse af klienttjenester (som et websted eller en mobilapplikation) sker separat uden brug af Auth. Adskillelsen tog omkring et år, og nu beskæftiger vi os igen med dette emne, og overfører systemet til nye godkendelsestjenester (med standardprotokoller).
Hvorfor tog adskillelsen så lang tid?
Der var mange problemer undervejs, der bremsede os:
- Vi ønskede at flytte bruger-, enheds- og godkendelsesdata fra landespecifikke databaser til én. For at gøre dette var vi nødt til at oversætte alle tabeller og brug fra int identifikatoren til den globale UUId identifikator (for nylig omarbejdet denne kode og open source-projekt ). Lagring af brugerdata (da det er personlige oplysninger) har sine begrænsninger, og for nogle lande er det nødvendigt at opbevare dem separat. Men brugerens globale id skal være.
- Mange tabeller i databasen har revisionsoplysninger om den bruger, der udførte handlingen. Dette krævede en yderligere mekanisme for sammenhæng.
- Efter oprettelsen af api-tjenester var der en lang og gradvis overgang til et andet system. Skiftet skulle være problemfrit for brugerne og krævede manuelt arbejde.
Enhedsregistreringsskema i et pizzeria:
Generel arkitektur efter udtrækning af Auth and Devices service:
Bemærk. For 2020 arbejder vi på en ny version af Auth, som er baseret på OAuth 2.0-autorisationsstandarden. Denne standard er ret kompleks, men den er nyttig til at udvikle en pass-through-godkendelsestjeneste. I artiklen "» vi Alexey Chernyaev forsøgte at fortælle om standarden så enkelt og klart som muligt, så du sparer tid på at studere den.
Hvad gør Tracker?
Nu om den anden af de indlæste tjenester. Trackeren udfører en dobbeltrolle:
- På den ene side er dens opgave at vise medarbejderne i køkkenet, hvilke ordrer der er i gang i øjeblikket, hvilke produkter der skal tilberedes nu.
- På den anden side at digitalisere alle processerne i køkkenet.
Når et nyt produkt dukker op i en ordre (for eksempel pizza), går det til udrulningssporingsstationen. På denne station er der en pizzabager, som tager en bolle af den ønskede størrelse og ruller den ud, hvorefter han noterer på tracker-tabletten, at han har udført sin opgave og overfører den rullede dejbund til næste station - "Initiation" .
Der fylder den næste pizzamager pizzaen, noterer derefter på tabletten, at han har udført sin opgave og sætter pizzaen i ovnen (dette er også en separat station, der skal noteres på tabletten). Et sådant system var fra begyndelsen i Dodo og helt fra begyndelsen af Dodo IS' eksistens. Det giver dig mulighed for fuldt ud at spore og digitalisere alle transaktioner. Derudover foreslår trackeren, hvordan man tilbereder et bestemt produkt, guider hver type produkt i henhold til dets fremstillingsskemaer, gemmer den optimale tilberedningstid for produktet og sporer alle handlinger på produktet.
Sådan ser skærmen på tabletten ud på stationen for trackeren "Raskatka"
Hvor er belastningerne fra?
Hver af pizzeriaerne har omkring fem tabletter med en tracker. I 2016 havde vi mere end 100 pizzeriaer (og nu mere end 600). Hver af tabletterne sender en anmodning til backend en gang hvert 10. sekund og skraber data fra ordretabellen (forbindelse til klient og adresse), ordresammensætning (forbindelse til produktet og angivelse af mængde), motivationsregnskabstabellen (den tidspunktet for tryk spores i den). Når en pizzamager klikker på et produkt på trackeren, opdateres indtastningerne i alle disse tabeller. Ordretabellen er generel, den indeholder også indlæg ved accept af en ordre, opdateringer fra andre dele af systemet og talrige aflæsninger, for eksempel på et tv, der hænger i et pizzeria og viser færdige ordrer til kunderne.
I perioden med kamp med belastninger, hvor alt og alt blev cachelagret og overført til den asynkrone kopi af basen, fortsatte disse operationer med trackeren med at gå til masterbasen. Der bør ikke være nogen forsinkelse, dataene skal være up-to-date, ude af synkronisering er uacceptabelt.
Desuden tillod manglen på egne tabeller og indekser på dem ikke at skrive mere specifikke forespørgsler, der var skræddersyet til deres brug. For eksempel kan det være effektivt for en tracker at have et indeks for et pizzeria på et ordrebord. Vi fjerner altid pizzeriaordrer fra trackerdatabasen. For at modtage en ordre er det samtidig ikke så vigtigt, hvilket pizzeria det falder ind i, det er vigtigere, hvilken kunde der har lavet denne ordre. Og det betyder, at indekset på klienten er nødvendigt. Det er heller ikke nødvendigt for trackeren at gemme id'et for den udskrevne kvittering eller bonuskampagner forbundet med ordren i ordretabellen. Disse oplysninger er ikke af interesse for vores tracker-tjeneste. I en fælles monolitisk database kunne tabeller kun være et kompromis mellem alle brugere. Dette var et af de oprindelige problemer.
VAR. Den oprindelige arkitektur var:
Selv efter at være blevet adskilt i separate processer, forblev det meste af kodebasen fælles for forskellige tjenester. Alt under controllerne var single og boede i det samme depot. Vi brugte almindelige metoder til tjenester, repositories, en fælles base, hvori fælles tabeller lå.
Aflæsning Tracker
Det største problem med trackeren er, at dataene skal synkroniseres mellem forskellige databaser. Dette er også dens væsentligste forskel fra adskillelsen af Auth-tjenesten, ordren og dens status kan ændres og bør vises i forskellige tjenester.
Vi accepterer en ordre ved Restaurantens Kasse (dette er en service), den gemmes i databasen i statussen "Accepteret". Derefter skal han komme til trackeren, hvor han vil ændre sin status flere gange: fra "Køkken" til "Packet". Samtidig kan nogle eksterne påvirkninger fra Kassereren eller Shift Manager-grænsefladen forekomme med ordren. Jeg vil give ordrestatusserne med deres beskrivelse i tabellen:
Skemaet for ændring af ordrestatus ser således ud:
Statusser skifter mellem forskellige systemer. Og her er trackeren ikke et endeligt system, hvor dataene lukkes. Vi har set flere mulige tilgange til opdeling i et sådant tilfælde:
- Vi koncentrerer alle ordrehandlinger i én service. I vores tilfælde kræver denne mulighed for meget service for at fungere med ordren. Hvis vi stoppede ved det, ville vi få den anden monolit. Vi ville ikke løse problemet.
- Et system ringer til et andet. Den anden mulighed er allerede mere interessant. Men med det er kæder af opkald mulige (), komponenternes tilslutningsmuligheder er højere, det er sværere at administrere.
- Vi arrangerer arrangementer, og hver tjeneste kommunikerer med en anden gennem disse arrangementer. Som et resultat var det den tredje mulighed, der blev valgt, ifølge hvilken alle tjenester begynder at udveksle begivenheder med hinanden.
At vi valgte den tredje mulighed betød, at trackeren ville have sin egen database, og for hver ændring i ordren ville den sende en begivenhed om dette, som andre tjenester abonnerer på, og som også falder ind i masterdatabasen. For at gøre dette havde vi brug for en tjeneste, der ville sikre levering af beskeder mellem tjenester.
På det tidspunkt havde vi allerede RabbitMQ i stakken, og derfor den endelige beslutning om at bruge det som en meddelelsesmægler. Diagrammet viser overgangen af en ordre fra Restaurant Kassereren gennem Trackeren, hvor den ændrer sin status og dens visning på Managerens Ordrer interface. BLIVE:
Bestil sti trin for trin
Ordrestien starter ved en af ordrekildetjenesterne. Her er kassereren i restauranten:
- Ved kassen er ordren helt klar, og det er tid til at sende den til trackeren. Hændelsen, som trackeren er abonneret på, kastes.
- Trackeren, der accepterer en ordre for sig selv, gemmer den i sin egen database, gør begivenheden "Order Accepted by Tracker" og sender den til RMQ.
- Der er allerede flere handlere, der abonnerer på hændelsesbussen pr. ordre. For os er den, der laver synkronisering med en monolitisk base, vigtig.
- Behandleren modtager en hændelse, vælger data fra den, der er væsentlige for den: i vores tilfælde er dette status for ordren "Accepteret af Trackeren" og opdaterer sin ordreenhed i hoveddatabasen.
Hvis nogen har brug for en ordre fra de monolitiske bordbestillinger, så kan du også læse den derfra. For eksempel har ordregrænsefladen i Shift Manager brug for dette:
Alle andre tjenester kan også abonnere på at bestille begivenheder fra trackeren for at bruge dem selv.
Hvis ordren efter et stykke tid tages i brug, ændres dens status først i dens database (Tracker-database), og derefter genereres "OrderIn Progress"-hændelsen straks. Det kommer også ind i RMQ, hvorfra det synkroniseres i en monolitisk database og leveres til andre tjenester. Der kan være forskellige problemer undervejs, flere detaljer om dem kan findes i rapporten fra Zhenya Peshkov .
Endelig arkitektur efter ændringer i Auth og Tracker
Opsummering af mellemresultatet: Til at begynde med havde jeg den idé at pakke Dodo IS-systemets ni år lange historie i én artikel. Jeg ville hurtigt og enkelt tale om evolutionens stadier. Men da jeg satte mig ned for materialet, indså jeg, at alt er meget mere kompliceret og interessant, end det ser ud til.
Efter at have reflekteret over fordelene (eller mangel på samme) ved sådant materiale, kom jeg til den konklusion, at kontinuerlig udvikling er umulig uden fuldgyldige annaler af begivenheder, detaljerede tilbageblik og analyse af mine tidligere beslutninger.
Jeg håber, at det var nyttigt og interessant for dig at lære om vores vej. Nu står jeg over for et valg, hvilken del af Dodo IS-systemet jeg skal beskrive i den næste artikel: skriv i kommentarerne eller stem.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Hvilken del af Dodo IS vil du gerne vide om i den næste artikel?
-
24,1 %Tidlig monolit i Dodo IS (2011-2015)14
-
24,1 %De første problemer og deres løsninger (2015-2016)14
-
20,7 %Stien på klientsiden: facade over base (2016-2017)12
-
36,2 %Historien om ægte mikrotjenester (2018-2019)21
-
44,8 %Komplet savning af monolitten og stabilisering af arkitekturen26
-
29,3 %Om videre planer for udviklingen af systemet17
-
19,0 %Jeg vil ikke vide noget om Dodo IS11
58 brugere stemte. 6 brugere undlod at stemme.
Kilde: www.habr.com