Habr is besig om die wêreld te verander. Ons blog al meer as 'n jaar. Sowat ses maande gelede het ons redelik logiese terugvoer van inwoners van Khabrovsk gekry: “Dodo, jy sê oral dat jy jou eie stelsel het. Watter soort stelsel is dit? En hoekom het die pizzeria-ketting dit nodig?”
Ons het gesit en dink en besef dat jy reg is. Ons probeer alles met ons vingers verduidelik, maar dit kom in geskeurde stukke uit en daar is nêrens 'n volledige beskrywing van die stelsel nie. So het 'n lang reis begin om inligting te versamel, skrywers te soek en 'n reeks artikels oor Dodo IS te skryf. Kom ons gaan!
Dankbetuigings: Dankie dat jy jou terugvoer met ons deel. Danksy hom het ons uiteindelik die stelsel beskryf, 'n technoradar saamgestel en binnekort 'n groot beskrywing van ons prosesse bekendgestel. Sonder julle sou ons nog 5 jaar so gesit het.
Reeks artikels "Wat is Dodo IS?" vertel van:
- Vroeë monoliet in Dodo IS (2011-2015). (Besig om...)
- Backoffice-pad: aparte basisse en bus. (Jy is hier)
- Die kliënt sypaadjie: fasade oor die basis (2016-2017). (Besig om...)
- Die geskiedenis van ware mikrodienste. (2018-2019). (Besig om...)
- Klaar saag van die monoliet en stabilisering van die argitektuur. (Besig om...)
As jy belangstel om iets anders te weet - skryf in die kommentaar.
Mening oor die chronologiese beskrywing van die skrywer
Ek hou gereeld 'n vergadering vir nuwe werknemers oor die onderwerp "Stelselargitektuur". Ons noem dit "Intro to Dodo IS Architecture" en dit is deel van die aanboordproses vir nuwe ontwikkelaars. Deur in een of ander vorm oor ons argitektuur, oor die kenmerke daarvan te praat, het ek 'n sekere historiese benadering tot die beskrywing ontwikkel.
Tradisioneel kyk ons na 'n stelsel as 'n stel komponente (tegniese of hoërvlak), besigheidsmodules wat met mekaar in wisselwerking tree om een of ander doel te bereik. En hoewel so 'n siening geregverdig is vir ontwerp, is dit nie heeltemal geskik vir beskrywing en begrip nie. Daar is verskeie redes:
- Die werklikheid is anders as wat op papier staan. Nie alles werk uit soos beplan nie. En ons stel belang in hoe alles eintlik uitgedraai het en werk.
- Konsekwente aanbieding van inligting. Trouens, jy kan chronologies van die begin af na die huidige toestand gaan.
- Van eenvoudig tot kompleks. Nie universeel nie, maar in ons geval is dit so. Argitektuur het beweeg van eenvoudiger benaderings na meer komplekse. Dikwels, deur komplikasies, probleme van implementeringspoed en stabiliteit, sowel as dosyne ander eienskappe uit die lys van nie-funksionele vereistes ( goed vertel oor kontrasterende kompleksiteit met ander vereistes).
In 2011 het die Dodo IS-argitektuur so gelyk:
Teen 2020 het dit 'n bietjie meer ingewikkeld geword en het soos volg geword:
Hoe het hierdie evolusie plaasgevind? Hoekom is verskillende dele van die stelsel nodig? Watter argitektoniese besluite is geneem en hoekom? Kom ons vind uit in hierdie reeks artikels.
Die eerste probleme van 2016: hoekom moet dienste die monoliet verlaat
Die eerste artikels in die reeks sal handel oor die dienste wat die eerste was om van die monoliet te skei. Om jou in konteks te plaas, sal ek jou vertel watter probleme ons aan die begin van 2016 in die stelsel gehad het, dat ons die skeiding van dienste moes hanteer.
'n Enkele MySql-databasis, waarin alle toepassings wat op daardie stadium in Dodo IS bestaan het, hul rekords geskryf het. Die gevolge was:
- Swaar vrag (met 85% van versoeke vir lees).
- Die basis het gegroei. As gevolg hiervan het die koste en ondersteuning daarvan 'n probleem geword.
- Enkele punt van mislukking. As een toepassing wat na die databasis skryf, dit skielik meer aktief begin doen het, dan het ander toepassings dit op hulself gevoel.
- Ondoeltreffendheid in berging en navrae. Dikwels is die data gestoor in een of ander struktuur wat gerieflik was vir sommige scenario's, maar nie geskik vir ander nie. Indekse versnel sommige bewerkings, maar kan ander vertraag.
- Sommige van die probleme is opgelos deur haastig gemaak caches en lees-replikas na databasisse (dit sal in 'n aparte artikel bespreek word), maar dit het ons net toegelaat om tyd te wen en het nie die probleem fundamenteel opgelos nie.
Die probleem was die teenwoordigheid van die monoliet self. Die gevolge was:
- Unieke en seldsame vrystellings.
- Moeilikheid om gesamentlike ontwikkeling van 'n groot aantal mense.
- Onvermoë om nuwe tegnologieë, nuwe raamwerke en biblioteke bekend te stel.
Probleme met die basis en die monoliet is al baie keer beskryf, byvoorbeeld in die konteks van ongelukke vroeg in 2018 (, и ), so ek sal nie te veel stilstaan nie. Laat ek net sê dat ons meer buigsaamheid wou gee wanneer ons dienste ontwikkel. In die eerste plek het dit betrekking op diegene wat die meeste gelaai en wortel in die hele stelsel was - Auth en Tracker.
Die Back Office-pad: aparte basisse en bus
Hoofstuknavigasie
Monolietskema 2016
Hier is die hoofblokke van die Dodo IS 2016-monoliet, en net onder is 'n transkripsie van hul hooftake.
Kassier aflewering. Verantwoording vir koeriers, uitreiking van bestellings aan koeriers.
Kontak sentrum. Aanvaarding van bestellings deur die operateur.
Werf. Ons webwerwe (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ens.).
auth. Magtiging en stawing diens vir die back office.
spoorsnyer. Kombuis bestelling spoorsnyer. Diens vir die merk van gereedheidstatusse wanneer 'n bestelling voorberei word.
Kontanttoonbank van die Restaurant. Neem bestellings in 'n restaurant, kassier-koppelvlakke.
uitvoer. Laai verslae in 1C op vir rekeningkunde.
Waarskuwings en fakture. Stembevele in die kombuis (byvoorbeeld, "Nuwe pizza het aangekom") + faktuurdruk vir koeriers.
Skofbestuurder. Koppelvlakke vir die werk van 'n skofbestuurder: lys van bestellings, produktiwiteitskaarte, bring werknemers na skofte.
Kantoorbestuurder. Interfaces vir die werk van franchisenemers en bestuurders: ontvangs van werknemers, verslae oor die werk van die pizzeria.
Restaurant telbord. Vertoon spyskaarte op TV's in pizzeria's.
admin. Instellings vir 'n spesifieke pizzeria: spyskaart, pryse, rekeningkunde, promosiekodes, promosies, baniere vir die webwerf, ens.
Werknemer se persoonlike rekening. Werkskedules van werknemers, inligting oor werknemers.
Kombuis motiveringsbord. ’n Aparte skerm wat in die kombuis hang en die spoed van die pizzamakers vertoon.
kommunikasie. Stuur sms en e-pos.
Lêerberging. Eie diens vir die ontvangs en uitreiking van statiese lêers.
Die eerste pogings om die probleme op te los het ons gehelp, maar dit was net 'n tydelike blaaskans. Hulle het nie stelseloplossings geword nie, so dit was duidelik dat iets met die basisse gedoen moes word. Byvoorbeeld, om die algemene databasis in verskeie meer gespesialiseerdes te verdeel.
Ons begin om die monoliet af te laai: skeiding van Auth en Tracker
Die hoofdienste wat dan meer as ander van die databasis opgeneem en gelees het:
- Auth. Magtiging en stawing diens vir die back office.
- Tracker. Bestel spoorsnyer in die kombuis. Diens vir die merk van gereedheidstatusse wanneer 'n bestelling voorberei word.
Wat doen Auth?
Auth is 'n diens waardeur gebruikers by die agterkantoor aanmeld (daar is 'n aparte onafhanklike aanmelding aan die kliëntkant). Dit word ook in die versoek verwys om te verseker dat die korrekte toegangsregte teenwoordig is en dat hierdie regte nie verander het sedert die laaste aanmelding nie. Toestelle gaan daardeur pizzeria's binne.
Ons wil byvoorbeeld 'n skerm oopmaak met die status van voltooide bestellings op die TV wat in die saal hang. Dan maak ons auth.dodopizza.ru oop, kies "Teken aan as toestel", 'n kode verskyn wat in 'n spesiale bladsy op die skofbestuurder se rekenaar ingevoer kan word, wat die tipe toestel (toestel) aandui. Die TV self sal na die verlangde koppelvlak van sy pizzeria gaan en begin om die name van kliënte wie se bestellings gereed is, daar te vertoon.
Waar kom die vragte vandaan?
Elke aangemelde gebruiker van die back office gaan na die databasis, na die gebruikerstabel vir elke versoek, trek die gebruiker uit deur 'n sql-navraag en kyk of hy die nodige toegang en regte tot hierdie bladsy het.
Elkeen van die toestelle doen dieselfde net met die toesteltabel, wat die rol en toegang daarvan nagaan. 'n Groot aantal versoeke aan die meesterdatabasis lei tot die laai daarvan en die vermorsing van hulpbronne van die gemeenskaplike databasis vir hierdie bedrywighede.
Aflaai Auth
Auth het 'n geïsoleerde domein, dit wil sê data oor gebruikers, aanmeldings of toestelle gaan die diens (vir eers) binne en bly daar. As iemand hulle nodig het, sal hy na hierdie diens gaan vir data.
WAS. Die werkvloei was aanvanklik soos volg:
Ek wil graag 'n bietjie verduidelik hoe dit gewerk het:
- 'n Versoek van buite kom na die agterkant (daar is Asp.Net MVC), bring 'n sessiekoekie saam, wat gebruik word om sessiedata van Redis(1) te kry. Dit bevat óf inligting oor toegang, en dan is toegang tot die kontroleerder oop (3,4), óf nie.
- As daar geen toegang is nie, moet jy deur die magtigingsprosedure gaan. Hier word dit vir eenvoud as deel van die pad in dieselfde kenmerk gewys, hoewel dit 'n oorgang na die aanmeldbladsy is. In die geval van 'n positiewe scenario, sal ons 'n korrek voltooide sessie kry en na die Backoffice Controller gaan.
- As daar data is, moet u dit nagaan vir relevansie in die gebruikersbasis. Het sy rol verander, moet hy nie nou op die blad toegelaat word nie? In hierdie geval, nadat u die sessie (1) ontvang het, moet u direk na die databasis gaan en die gebruiker se toegang nagaan met behulp van die verifikasielogikalaag (2). Volgende, óf na die aanmeldbladsy, óf gaan na die kontroleerder. So 'n eenvoudige stelsel, maar nie heeltemal standaard nie.
- As alle prosedures geslaag is, slaan ons verder in die logika in beheerders en metodes oor.
Gebruikersdata word van alle ander data geskei, dit word in 'n aparte lidmaatskaptabel gestoor, funksies van die AuthService-logikalaag kan wel api-metodes word. Domeingrense word redelik duidelik gedefinieer: gebruikers, hul rolle, toegangsdata, toestaan en herroeping van toegang. Alles lyk so dat dit in 'n aparte diens uitgehaal kan word.
WORD. So het hulle gedoen:
Hierdie benadering het 'n aantal probleme. Byvoorbeeld, om 'n metode binne 'n proses te bel, is nie dieselfde as om 'n eksterne diens via http te bel nie. Latency, betroubaarheid, instandhouding, deursigtigheid van die operasie is heeltemal anders. Andrey Morevskiy het in meer besonderhede oor sulke probleme in sy verslag gepraat. .
Die verifikasiediens en daarmee saam die toesteldiens word vir back office gebruik, dit wil sê vir dienste en koppelvlakke wat in produksie gebruik word. Stawing vir kliëntdienste (soos 'n webwerf of mobiele toepassing) vind afsonderlik plaas sonder om Auth. Die skeiding het ongeveer 'n jaar geneem, en nou werk ons weer aan hierdie onderwerp, en dra die stelsel oor na nuwe verifikasiedienste (met standaardprotokolle).
Hoekom het die skeiding so lank geneem?
Daar was baie probleme langs die pad wat ons vertraag het:
- Ons wou data oor gebruikers, toestelle en verifikasie van landdatabasisse na een oordra. Om dit te doen, moes ons alle tabelle en gebruik van die int-identifiseerder na die globale UUId-identifiseerder oordra (ons het onlangs hierdie kode herwerk en oopbronprojek ). Die stoor van gebruikersdata (aangesien dit persoonlike inligting is) het sy beperkings en vir sommige lande is dit nodig om dit afsonderlik te stoor. Maar daar moet 'n globale gebruiker-ID wees.
- Baie tabelle in die databasis het ouditinligting oor die gebruiker wat die bewerking uitgevoer het. Dit het 'n bykomende meganisme vir konsekwentheid vereis.
- Na die skepping van API-dienste was daar 'n lang en geleidelike tydperk van oordrag na 'n ander stelsel. Skakelaars moes soomloos vir gebruikers gebeur en het handwerk vereis.
Toestelregistrasieskema in 'n pizzeria:
Algemene argitektuur na die onttrekking van Auth and Devices-diens:
Let daarop. Vir 2020 werk ons aan 'n nuwe weergawe van Auth, wat gebaseer is op die OAuth 2.0-magtigingstandaard. Hierdie standaard is redelik kompleks, maar nuttig vir die ontwikkeling van 'n end-tot-end-verifikasiediens. In die artikel "» ons Alexey Chernyaev het probeer om so eenvoudig en duidelik as moontlik oor die standaard te praat sodat jy tyd bespaar om dit te bestudeer.
Wat doen Tracker?
Nou oor die tweede van die gelaaide dienste. Die spoorsnyer speel 'n dubbele rol:
- Aan die een kant is sy taak om werknemers in die kombuis te wys watter bestellings tans aan die gang is, watter produkte nou voorberei moet word.
- Aan die ander kant, om al die prosesse in die kombuis te digitaliseer.
Wanneer 'n nuwe produk (byvoorbeeld pizza) in 'n bestelling verskyn, gaan dit na die "Rolling" spoorsnyerstasie. By hierdie stasie is daar 'n pizzamaker wat 'n broodjie van die verlangde grootte neem en dit uitrol, waarna hy op die spoorsnyer-tablet merk dat hy sy taak voltooi het en die uitgerolde deegbasis na die volgende stasie - "Vul" gee .
Daar maak die volgende pizzamaker die pizza vol, teken dan op die tablet aan dat hy sy taak voltooi het en sit die pizza in die oond (dit is ook 'n aparte stasie wat op die tablet aangeteken moet word). So 'n stelsel was van die begin af in Dodo en van die heel begin van die bestaan van Dodo IS. Dit laat jou toe om alle transaksies volledig op te spoor en te digitaliseer. Daarbenewens stel die spoorsnyer voor hoe om 'n spesifieke produk gaar te maak, lei elke tipe produk volgens sy vervaardigingskemas, stoor die optimale gaarmaaktyd vir die produk, en volg alle bewerkings op die produk.
Dit is hoe die tabletskerm by die Raskatka-spoorsnyerstasie lyk.
Waar kom die vragte vandaan?
Elke pizzeria het ongeveer vyf tablette met 'n spoorsnyer. In 2016 het ons meer as 100 pizzeria's gehad (en nou is daar meer as 600). Elkeen van die tablette rig elke 10 sekondes 'n versoek aan die agterkant en versamel data van die besteltabel (skakel met die kliënt en adres), die bestelsamestelling (skakel met die produk en aanduiding van hoeveelheid) en die motiveringstabel (dit volg die tyd van druk). Wanneer 'n pizzamaker op 'n produk op die spoorsnyer klik, word rekords in al hierdie tabelle opgedateer. Die besteltabel is algemeen; dit bevat terselfdertyd invoegings wanneer 'n bestelling aanvaar word, opdaterings van ander dele van die stelsel, en talle lesings, byvoorbeeld, op 'n TV wat in 'n pizzeria hang en klaargemaakte bestellings aan kliënte wys.
Gedurende die tydperk van stryd met vragte, toe alles en almal gekas is en na 'n asynchrone replika van die databasis oorgedra is, het hierdie bewerkings met die spoorsnyer voortgegaan om na die meesterdatabasis te gaan. Daar behoort geen vertraging hier te wees nie, die data moet op datum wees, uit sinchroniseer is onaanvaarbaar.
Die gebrek aan eie tabelle en indekse daarop het ook nie die skryf van meer spesifieke navrae toegelaat wat vir hul gebruik aangepas is nie. Dit kan byvoorbeeld doeltreffend wees vir 'n spoorsnyer om 'n indeks vir 'n pizzeria op 'n besteltafel te hê. Ons verwyder altyd pizzeria-bestellings van die spoorsnyer-databasis. Terselfdertyd, vir die ontvangs van 'n bestelling, is dit nie so belangrik in watter pizzeria dit val nie, dit is belangriker watter kliënt hierdie bestelling gemaak het. En beteken daar is die indeks op die kliënt nodig. Dit is ook nie nodig dat die spoorsnyer die ID van die gedrukte kwitansie of bonuspromosies wat met die bestelling geassosieer word, in die besteltabel stoor nie. Hierdie inligting is nie van belang vir ons spoorsnyerdiens nie. In 'n algemene monolitiese databasis kan tabelle slegs 'n kompromie tussen alle gebruikers wees. Dit was een van die oorspronklike probleme.
WAS. Aanvanklik was die argitektuur soos volg:
Selfs nadat dit in afsonderlike prosesse geskei is, het die meeste van die kodebasis gemeen aan verskillende dienste gebly. Alles onder die beheerders was verenig en het in een bewaarplek gewoon. Algemene metodes van dienste, bewaarplekke en 'n gemeenskaplike databasis wat algemene tabelle bevat, is gebruik.
Aflaai Tracker
Die grootste probleem met die spoorsnyer is dat die data tussen verskillende databasisse gesinchroniseer moet word. Dit is ook die belangrikste verskil van die verdeling van die Auth-diens; die bestelling en sy status kan verander en moet in verskeie dienste vertoon word.
Ons aanvaar 'n bestelling by die restaurant se betaalpunt (dit is 'n diens), dit word in die databasis gestoor in die "Aanvaar" status. Daarna moet hy by die spoorsnyer uitkom, waar hy nog 'n paar keer sy status sal verander: van "Kombuis" na "Verpak". Terselfdertyd kan sommige eksterne invloede van die Kassier of die Shift Manager-koppelvlak met die bestelling voorkom. Ek sal die bestellingstatusse gee met hul beskrywing in die tabel:
Die skema vir die verandering van bestellingstatusse lyk soos volg:
Statusse verander tussen verskillende stelsels. En hier is die spoorsnyer nie 'n finale stelsel waarin die data gesluit word nie. Ons het verskeie moontlike benaderings vir partisie in so 'n geval gesien:
- Ons konsentreer alle bestellingsaksies in een diens. In ons geval vereis hierdie opsie te veel diens om met die bestelling te werk. As ons daarby stop, sou ons die tweede monoliet kry. Ons sou nie die probleem oplos nie.
- Een stelsel maak 'n oproep na 'n ander. Die tweede opsie is meer interessant. Maar daarmee is kettings van oproepe moontlik (), is die konnektiwiteit van die komponente hoër, dit is moeiliker om te bestuur.
- Ons organiseer geleenthede, en elke diens kommunikeer met 'n ander deur hierdie geleenthede. Gevolglik is die derde opsie gekies, waarvolgens alle dienste gebeure met mekaar begin uitruil.
Die feit dat ons die derde opsie gekies het, het beteken dat die spoorsnyer sy eie databasis sou hê, en vir elke verandering in die bestelling sou dit 'n gebeurtenis hieroor stuur, waarop ander dienste inteken en wat ook in die meesterdatabasis val. Om dit te doen, het ons een of ander diens nodig gehad wat die aflewering van boodskappe tussen dienste sou verseker.
Teen daardie tyd het ons reeds RabbitMQ in die stapel gehad, vandaar die finale besluit om dit as 'n boodskapmakelaar te gebruik. Die diagram toon die oorgang van 'n bestelling vanaf die Restaurantkassier deur die Tracker, waar dit sy status en sy vertoning op die Bestuurder se Bestellings-koppelvlak verander. WORD:
Bestel pad stap vir stap
Die bestellingspad begin by een van die bestellingsbrondienste. Hier is die Restaurant Kassier:
- Die bestelling is heeltemal gereed by die betaalpunt, en dit is tyd om dit na die spoorsnyer te stuur. Die geleentheid waarop die spoorsnyer ingeteken is, word gegooi.
- Die spoorsnyer, wat 'n bestelling vir homself aanvaar, stoor dit in sy eie databasis, maak die geleentheid "Bestelling aanvaar deur die spoorsnyer" en stuur dit na RMQ.
- Daar is verskeie hanteerders wat reeds ingeteken is op die gebeurtenisbus per bestelling. Vir ons is die een wat sinchronisasie met 'n monolitiese basis maak belangrik.
- Die hanteerder ontvang die gebeurtenis, kies daaruit die data wat beduidend daarvoor is: in ons geval is dit die bestellingstatus "Aanvaar deur Tracker" en dateer sy bestellingsentiteit in die hoofdatabasis op.
As iemand 'n bestelling van die monolitiese tafelorders benodig, dan kan jy dit ook van daar af lees. Byvoorbeeld, die Bestellings-koppelvlak in die Shift Manager benodig dit:
Alle ander dienste kan ook inteken op bestellingsgeleenthede van die spoorsnyer om dit vir hulself te gebruik.
As die bestelling na 'n rukkie in werking geneem word, verander die status eers in sy databasis (Tracker-databasis), en dan word die "OrderIn Progress"-gebeurtenis onmiddellik gegenereer. Dit kom ook in RMQ, vanwaar dit in 'n monolitiese databasis gesinchroniseer word en aan ander dienste gelewer word. Daar kan verskeie probleme langs die pad wees, meer besonderhede daaroor kan gevind word in die verslag van Zhenya Peshkov .
Finale argitektuur na veranderinge in Auth en Tracker
Op te som: Aanvanklik het ek die idee gehad om die nege jaar lange geskiedenis van die Dodo IS-stelsel in een artikel te verpak. Ek wou vinnig en eenvoudig oor die stadiums van evolusie praat. Nadat ek egter gaan sit het om die materiaal te bestudeer, het ek besef dat alles baie meer kompleks en interessant is as wat dit lyk.
Deur na te dink oor die voordele (of gebrek daaraan) van sulke materiaal, het ek tot die gevolgtrekking gekom dat voortdurende ontwikkeling onmoontlik is sonder volwaardige kronieke van gebeure, gedetailleerde terugblikke en ontleding van 'n mens se vorige besluite.
Ek hoop dat dit nuttig en interessant was vir jou om oor ons pad te leer. Nou staan ek voor 'n keuse watter deel van die Dodo IS-stelsel om in die volgende artikel te beskryf: skryf in die kommentaar of stem.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Van watter deel van Dodo IS sal jy graag in die volgende artikel wil weet?
-
24,1%Vroeë monoliet in Dodo IS (2011-2015)14
-
24,1%Eerste probleme en hul oplossings (2015-2016)14
-
20,7%Pad van die kliëntdeel: fasade bo die basis (2016-2017)12
-
36,2%Geskiedenis van regte mikrodienste (2018-2019)21
-
44,8%Voltooide sny van die monoliet en stabilisering van die argitektuur26
-
29,3%Oor verdere planne vir die ontwikkeling van die stelsel17
-
19,0%Ek wil niks van Dodo IS11 weet nie
58 gebruikers het gestem. 6 gebruikers het buite stemming gebly.
Bron: will.com