Geschiedenis van de Dodo IS-architectuur: het backofficepad

Habr verandert de wereld. We bloggen nu ruim een ​​jaar. Een half jaar geleden kregen we een volkomen logische feedback van Khabrovites: “Dodo, je zegt overal dat je je eigen systeem hebt. En wat is dit systeem? En waarom heeft een pizzaketen het nodig?

We zaten, dachten en realiseerden ons dat je gelijk hebt. We proberen alles op onze vingers uit te leggen, maar het komt er in gescheurde stukken uit en er is nergens een volledige beschrijving van het systeem. Zo begon een lange reis van het verzamelen van informatie, het zoeken naar auteurs en het schrijven van een reeks artikelen over Dodo IS. Laten we gaan!

Dankwoord: Bedankt voor het delen van uw feedback met ons. Dankzij hem hebben we eindelijk het systeem beschreven, een technische radar samengesteld en binnenkort een grote beschrijving van onze processen uitrollen. Zonder jullie hadden we er nog 5 jaar gezeten.

Artikelreeks "Wat is Dodo IS?" vertelt over:

1. Vroege monoliet in Dodo IS (2011-2015). (Bezig…)
2. Het backofficepad: aparte bases en bus. (je bent hier)
3. Het pad aan de klantzijde: gevel over de sokkel (2016-2017). (Bezig…)
4. De geschiedenis van echte microservices. (2018-2019). (Bezig…)
5. Afgewerkt zagen van de monoliet en stabilisatie van de architectuur. (Bezig...)

Als je iets anders wilt weten, schrijf dan in de comments.

Mening over de chronologische beschrijving van de auteur
Ik houd regelmatig een bijeenkomst voor nieuwe medewerkers over het onderwerp "Systeemarchitectuur". We noemen het "Intro to Dodo IS Architecture" en het maakt deel uit van het onboardingproces voor nieuwe ontwikkelaars. Door in een of andere vorm te vertellen over onze architectuur, over de kenmerken ervan, heb ik een zekere historische benadering van de beschrijving geboren.

Traditioneel beschouwen we het systeem als een set componenten (technisch of hoger niveau), bedrijfsmodules die met elkaar communiceren om een ​​bepaald doel te bereiken. En als zo'n mening gerechtvaardigd is voor ontwerp, dan is het niet helemaal geschikt voor beschrijving en begrip. Er zijn verschillende redenen hier:

• De werkelijkheid is anders dan op papier. Niet alles loopt zoals gepland. En we zijn geïnteresseerd in hoe het daadwerkelijk is geworden en werkt.
• Consistente presentatie van informatie. U kunt zelfs chronologisch van het begin naar de huidige staat gaan.
• Van eenvoudig tot complex. Niet universeel, maar in ons geval wel. De architectuur ging van eenvoudigere naar meer complexe benaderingen. Vaak werden door complicaties problemen met implementatiesnelheid en stabiliteit opgelost, evenals tientallen andere eigenschappen uit de lijst met niet-functionele vereisten (hier goed verteld over het contrasteren van complexiteit met andere vereisten).

In 2011 zag de Dodo IS-architectuur er zo uit:

In 2020 is het iets gecompliceerder geworden en is het zo geworden:

Hoe is deze evolutie verlopen? Waarom zijn verschillende delen van het systeem nodig? Welke architectonische beslissingen zijn er genomen en waarom? Laten we erachter komen in deze reeks artikelen.

De eerste problemen van 2016: waarom zouden diensten de monoliet verlaten?

De eerste artikelen uit de cyclus gaan over de diensten die zich als eerste losmaakten van de monoliet. Om u in context te plaatsen, zal ik u vertellen welke problemen we begin 2016 in het systeem hadden, dat we te maken hadden met de scheiding van diensten.

Eén enkele MySql-database, waarin alle applicaties die op dat moment in Dodo IS bestonden hun records schreven. De gevolgen waren:

• Zware belasting (met 85% van de verzoeken voor lezen).
• De basis is gegroeid. Hierdoor werden de kosten en ondersteuning een probleem.
• Eén punt van mislukking. Als een applicatie die naar de database schrijft dit plotseling actiever begon te doen, dan voelden andere applicaties dat aan zichzelf.
• Inefficiëntie in opslag en query's. Vaak werden de gegevens opgeslagen in een structuur die handig was voor sommige scenario's, maar niet geschikt voor andere. Indexen versnellen sommige bewerkingen, maar kunnen andere vertragen.
• Sommige problemen werden verholpen door haastig gemaakte caches en read-replica's naar de bases (dit zal een apart artikel zijn), maar ze lieten hen alleen tijd winnen en losten het probleem niet fundamenteel op.

Het probleem was de aanwezigheid van de monoliet zelf. De gevolgen waren:

• Enkele en zeldzame releases.
• Moeite met gezamenlijke ontwikkeling van een groot aantal mensen.
• Onvermogen om nieuwe technologieën, nieuwe frameworks en bibliotheken in te voeren.

Problemen met de basis en de monoliet zijn al vele malen beschreven, bijvoorbeeld in het kader van crashes begin 2018 (Wees zoals Munch, of een paar woorden over technische schulden, De dag dat Dodo IS stopte. Asynchroon script и Het verhaal van de Dodo-vogel uit de Phoenix-familie. De grote val van Dodo IS), dus ik zal niet te veel stilstaan. Laat me alleen zeggen dat we meer flexibiliteit wilden geven bij het ontwikkelen van diensten. Allereerst betrof dit degenen die het meest geladen en root waren in het hele systeem - Auth en Tracker.

Het backoffice-pad: afzonderlijke bases en bus

Hoofdstuknavigatie

1. Monoliet regeling 2016
2. Beginnen met het uitladen van de monoliet: scheiding van authenticatie en tracker
   
3. Wat doet Auth?
4. Waar komen de ladingen vandaan?
5. Autorisatie lossen
6. Wat doet Tracker?
7. Waar komen de ladingen vandaan?
8. Tracker uitladen

Monoliet regeling 2016

Hier zijn de belangrijkste blokken van de Dodo IS 2016-monoliet, en net daaronder is een transcriptie van hun belangrijkste taken.

Kassa bezorging. Boekhouding voor koeriers, orders uitgeven aan koeriers.
Contact Centrum. Aanvaarding van bestellingen via de operator.
Website. Onze websites (dodopizza.ru, dodopizza.co.uk, dodopizza.by, enz.).
Auth. Autorisatie- en authenticatieservice voor de backoffice.
tracker. Besteltracker in de keuken. Service voor het markeren van gereedheidsstatussen bij het voorbereiden van een bestelling.
Kassa van het Restaurant. Bestellingen opnemen in een restaurant, kassa-interfaces.
Exporteren. Rapportages uploaden in 1C voor de boekhouding.
Meldingen en facturen. Spraakopdrachten in de keuken (bijvoorbeeld “Nieuwe pizza gearriveerd”) + factuur printen voor koeriers.
Shiftmanager. Interfaces voor het werk van de shiftmanager: lijst met orders, prestatiegrafieken, overplaatsing van medewerkers naar de shift.
Officemanager. Interfaces voor het werk van de franchisenemer en de manager: ontvangst van medewerkers, verslagen over het werk van de pizzeria.
Restaurant scorebord. Menuweergave op tv's in pizzeria's.
beheerder. Instellingen in een specifieke pizzeria: menu, prijzen, boekhouding, promotiecodes, promoties, websitebanners, enz.
Persoonlijk account van de werknemer. Werkschema's van werknemers, informatie over werknemers.
Keuken Motivatiebord. Een apart scherm dat in de keuken hangt en de snelheid van de pizzamakers weergeeft.
Communicatie. Sms en e-mail versturen.
Bestandsopslag. Eigen service voor het ontvangen en uitgeven van statische bestanden.

De eerste pogingen om de problemen op te lossen hebben ons geholpen, maar waren slechts een tijdelijke onderbreking. Het werden geen systeemoplossingen, dus het was duidelijk dat er iets met de sokkels moest gebeuren. Bijvoorbeeld om de algemene database op te splitsen in meerdere meer gespecialiseerde.

Beginnen met het uitladen van de monoliet: scheiding van authenticatie en tracker

De belangrijkste services die vervolgens meer opnamen en uit de database lezen dan andere:

1. Auth. Autorisatie- en authenticatieservice voor de backoffice.
2. Volger. Besteltracker in de keuken. Service voor het markeren van gereedheidsstatussen bij het voorbereiden van een bestelling.

Wat doet Auth?

Auth is een dienst waarmee gebruikers inloggen in de backoffice (er is een aparte zelfstandige ingang aan de klantzijde). In het verzoek wordt ook gevraagd om ervoor te zorgen dat de vereiste toegangsrechten aanwezig zijn en dat deze rechten niet zijn gewijzigd sinds de laatste login. Hierdoor komen apparaten de pizzeria binnen.

Zo willen we een display openen met de status van afgeronde bestellingen op de tv die in de hal hangt. Vervolgens openen we auth.dodopizza.ru, selecteren "Inloggen als apparaat", er verschijnt een code die kan worden ingevoerd op een speciale pagina op de computer van de shiftmanager, die het type apparaat (apparaat) aangeeft. De tv schakelt zelf over naar de gewenste interface van zijn pizzeria en begint de namen weer te geven van klanten wiens bestellingen daar klaarstaan.

Waar komen de ladingen vandaan?

Elke ingelogde gebruiker van de backoffice gaat voor elke aanvraag naar de database, naar de gebruikerstabel, haalt de gebruiker er via een sql-query uit en controleert of hij de benodigde toegang en rechten tot deze pagina heeft.

Elk van de apparaten doet hetzelfde alleen met de apparatentabel, waarbij de rol en de toegang ervan worden gecontroleerd. Een groot aantal verzoeken aan de hoofddatabase leidt tot het laden ervan en tot verspilling van bronnen van de gemeenschappelijke database voor deze bewerkingen.

Autorisatie lossen

Auth heeft een geïsoleerd domein, dat wil zeggen dat gegevens over gebruikers, logins of apparaten de dienst (voorlopig) binnenkomen en daar blijven. Als iemand ze nodig heeft, gaat hij naar deze dienst voor gegevens.

WAS. Het oorspronkelijke werkschema was als volgt:

Ik wil even uitleggen hoe het werkte:

1. Een verzoek van buitenaf komt naar de backend (er is Asp.Net MVC), brengt een sessiecookie met zich mee, die wordt gebruikt om sessiegegevens van Redis(1) op te halen. Het bevat ofwel informatie over toegangen, en dan is de toegang tot de controller open (3,4), of niet.
2. Als er geen toegang is, moet u de autorisatieprocedure doorlopen. Hier wordt het voor de eenvoud weergegeven als onderdeel van het pad in hetzelfde attribuut, hoewel het een overgang is naar de inlogpagina. Bij een positief scenario krijgen we een correct afgeronde sessie en gaan we naar de Backoffice Controller.
3. Als er gegevens zijn, moet u deze controleren op relevantie in de gebruikersdatabase. Is zijn rol veranderd, mag hij nu niet op de pagina? In dit geval moet u na ontvangst van de sessie (1) rechtstreeks naar de database gaan en de toegang van de gebruiker controleren met behulp van de logische authenticatielaag (2). Ga vervolgens naar de inlogpagina of ga naar de controller. Zo'n eenvoudig systeem, maar niet helemaal standaard.
4. Als alle procedures zijn doorlopen, gaan we verder in de logica in controllers en methoden.

Gebruikersgegevens worden gescheiden van alle andere gegevens, ze worden opgeslagen in een aparte lidmaatschapstabel, functies uit de AuthService-logicalaag kunnen heel goed api-methoden worden. Domeingrenzen zijn vrij duidelijk gedefinieerd: gebruikers, hun rollen, toegangsgegevens, het verlenen en intrekken van toegang. Alles ziet er zo uit dat het in een aparte dienst eruit kan worden gehaald.

WORDEN. Dus dat deden ze:

Deze aanpak heeft een aantal problemen. Het aanroepen van een methode binnen een proces is bijvoorbeeld niet hetzelfde als het aanroepen van een externe service via http. Latency, betrouwbaarheid, onderhoudbaarheid, transparantie van de operatie zijn totaal verschillend. Andrey Morevskiy sprak in zijn rapport meer in detail over dergelijke problemen. "50 tinten microservices".

De authenticatieservice en daarmee de apparaatservice worden gebruikt voor de backoffice, dat wil zeggen voor services en interfaces die in de productie worden gebruikt. Verificatie voor clientservices (zoals een website of een mobiele applicatie) vindt afzonderlijk plaats zonder Auth te gebruiken. De scheiding duurde ongeveer een jaar en nu hebben we het weer over dit onderwerp, het systeem overzetten naar nieuwe authenticatiediensten (met standaardprotocollen).

Waarom duurde de scheiding zo lang?
Er waren onderweg veel problemen die ons vertraagden:

1. We wilden gebruikers-, apparaat- en authenticatiegegevens van landspecifieke databases naar één database verplaatsen. Om dit te doen, moesten we alle tabellen en het gebruik vertalen van de int identifier naar de globale UUId identifier (onlangs deze code herwerkt Roman Bukin "Uuid - een groot verhaal van een kleine structuur" en open source-project Primitieven). Het opslaan van gebruikersgegevens (aangezien het persoonlijke informatie is) heeft zijn beperkingen en voor sommige landen is het noodzakelijk om ze apart op te slaan. Maar de globale id van de gebruiker moet zijn.
2. Veel tabellen in de database bevatten auditinformatie over de gebruiker die de bewerking heeft uitgevoerd. Dit vereiste een extra mechanisme voor consistentie.
3. Na de oprichting van api-services was er een lange en geleidelijke overgang naar een ander systeem. Het overstappen moest naadloos verlopen voor gebruikers en vereiste handmatig werk.

Apparaatregistratieschema in een pizzeria:

Algemene architectuur na de extractie van de Auth and Devices-service:

Noot. Voor 2020 werken we aan een nieuwe versie van Auth, die gebaseerd is op de OAuth 2.0 autorisatiestandaard. Deze standaard is vrij complex, maar is handig voor het ontwikkelen van een pass-through-authenticatieservice. In het artikel "Subtiliteiten van autorisatie: een overzicht van OAuth 2.0-technologie» we Alexey Chernyaev probeerden zo eenvoudig en duidelijk mogelijk over de standaard te vertellen, zodat u tijd bespaart bij het bestuderen ervan.

Wat doet Tracker?

Nu ongeveer de tweede van de geladen services. De tracker vervult een dubbele rol:

• Enerzijds is het zijn taak om de medewerkers in de keuken te laten zien welke bestellingen er momenteel aan het werk zijn, welke producten nu gekookt moeten worden.
• Anderzijds om alle processen in de keuken te digitaliseren.

Wanneer er een nieuw product in een bestelling verschijnt (bijvoorbeeld pizza), gaat het naar het uitrolvolgstation. Op dit station is er een pizzabakker die een broodje van de gewenste grootte neemt en uitrolt, waarna hij op de tracker-tablet noteert dat hij zijn taak heeft voltooid en de opgerolde deegbodem naar het volgende station - "Initiatie" brengt .

Daar vult de volgende pizzabakker de pizza, noteert vervolgens op de tablet dat hij zijn taak heeft volbracht en schuift de pizza in de oven (dit is ook een apart station dat op de tablet moet worden genoteerd). Zo'n systeem was vanaf het allereerste begin in Dodo en vanaf het allereerste begin van het bestaan ​​van Dodo IS. Hiermee kunt u alle transacties volledig volgen en digitaliseren. Bovendien stelt de tracker voor hoe een bepaald product moet worden gekookt, begeleidt elk type product volgens zijn productieschema's, slaat de optimale kooktijd voor het product op en volgt alle bewerkingen op het product.

Zo ziet het scherm van de tablet eruit op het station van de tracker "Raskatka"

Waar komen de ladingen vandaan?

Elk van de pizzeria's heeft zo'n vijf tablets met een tracker. In 2016 hadden we meer dan 100 pizzeria's (en nu meer dan 600). Elk van de tablets doet eens in de 10 seconden een verzoek aan de backend en schraapt gegevens uit de besteltabel (verbinding met de klant en adres), ordersamenstelling (verbinding met het product en indicatie van de hoeveelheid), de motivatie-boekhoudingstabel (de tijd van persen wordt daarin bijgehouden). Wanneer een pizzabakker op een product op de tracker klikt, worden de vermeldingen in al deze tabellen bijgewerkt. De besteltabel is algemeen, het bevat ook bijlagen bij het accepteren van een bestelling, updates van andere delen van het systeem en tal van aflezingen, bijvoorbeeld op een tv die in een pizzeria hangt en voltooide bestellingen aan klanten laat zien.

Tijdens de periode van worstelen met ladingen, toen alles en nog wat in de cache werd opgeslagen en overgebracht naar de asynchrone replica van de basis, gingen deze operaties met de tracker door naar de masterbasis. Er mag geen vertraging zijn, de gegevens moeten up-to-date zijn, niet synchroon lopen is onaanvaardbaar.

Ook maakte het ontbreken van eigen tabellen en indexen het niet mogelijk om meer specifieke zoekopdrachten op maat voor hun gebruik te schrijven. Het kan bijvoorbeeld efficiënt zijn voor een tracker om een ​​index voor een pizzeria op een bestellijst te hebben. We verwijderen pizzeria-bestellingen altijd uit de tracker-database. Tegelijkertijd is het voor het ontvangen van een bestelling niet zo belangrijk in welke pizzeria het valt, het is belangrijker welke klant deze bestelling heeft gedaan. En betekent dat daar de index op de client noodzakelijk is. Het is ook niet nodig dat de tracker de id van de afgedrukte kassabon of bonuspromoties die aan de bestelling zijn gekoppeld, opslaat in de besteltabel. Deze informatie is niet interessant voor onze trackerservice. In een gemeenschappelijke monolithische database kunnen tabellen alleen een compromis zijn tussen alle gebruikers. Dit was een van de oorspronkelijke problemen.

WAS. De oorspronkelijke architectuur was:

Zelfs na te zijn gescheiden in afzonderlijke processen, bleef het grootste deel van de codebasis gemeenschappelijk voor verschillende services. Alles onder de controllers was enkelvoudig en leefde in dezelfde repository. We gebruikten gemeenschappelijke methoden van services, repositories, een gemeenschappelijke basis, waarin gemeenschappelijke tabellen lagen.

Tracker uitladen

Het grootste probleem met de tracker is dat de gegevens moeten worden gesynchroniseerd tussen verschillende databases. Dit is ook het belangrijkste verschil met de scheiding van de Auth-service, de bestelling en de status ervan kunnen veranderen en moeten in verschillende services worden weergegeven.

We accepteren een bestelling bij de kassa van het restaurant (dit is een service), deze wordt in de database opgeslagen met de status "Geaccepteerd". Daarna zou hij naar de tracker moeten gaan, waar hij zijn status nog een paar keer zal veranderen: van "Keuken" naar "Ingepakt". Tegelijkertijd kunnen er externe invloeden van de Kassier of de Shift Manager-interface optreden bij de bestelling. Ik zal de bestelstatussen met hun beschrijving in de tabel geven:

Het schema voor het wijzigen van orderstatussen ziet er als volgt uit:

Statussen veranderen tussen verschillende systemen. En hier is de tracker geen definitief systeem waarin de gegevens zijn afgesloten. We hebben in een dergelijk geval verschillende mogelijke benaderingen voor partitionering gezien:

1. Wij concentreren alle bestelacties in één dienst. In ons geval vereist deze optie te veel service om met de bestelling te werken. Als we erbij zouden stoppen, zouden we de tweede monoliet krijgen. We zouden het probleem niet oplossen.
2. Het ene systeem belt naar het andere. De tweede optie is interessanter. Maar hiermee zijn aaneenschakelingen van oproepen mogelijk (trapsgewijze mislukkingen), de connectiviteit van de componenten is hoger, het is moeilijker te beheren.
3. We organiseren evenementen en elke dienst communiceert via deze evenementen met een andere. Als gevolg hiervan werd gekozen voor de derde optie, volgens welke alle services gebeurtenissen met elkaar beginnen uit te wisselen.

Het feit dat we voor de derde optie kozen, betekende dat de tracker zijn eigen database zou hebben, en voor elke wijziging in de bestelling een gebeurtenis hierover zou sturen, waarop andere diensten zich abonneren en die ook in de hoofddatabase valt. Om dit te doen, hadden we een service nodig die de bezorging van berichten tussen services zou garanderen.

Tegen die tijd hadden we RabbitMQ al in de stack, vandaar de uiteindelijke beslissing om het als berichtenmakelaar te gebruiken. Het diagram toont de overgang van een bestelling van de restaurantkassier naar de tracker, waar de status verandert en de weergave op de interface van de managerbestellingen. WORDEN:

Bestelpad stap voor stap
Het bestelpad begint bij een van de bestelbronservices. Hier is de kassier van het restaurant:

1. Bij het afrekenen staat de bestelling helemaal klaar en is het tijd om deze naar de tracker te sturen. De gebeurtenis waarop de tracker is geabonneerd, wordt gegenereerd.
2. De tracker accepteert een bestelling voor zichzelf, slaat deze op in zijn eigen database, maakt de gebeurtenis "Bestelling geaccepteerd door de tracker" en stuurt deze naar RMQ.
3. Per bestelling zijn er al meerdere handlers ingeschreven op de eventbus. Voor ons is degene die synchronisatie met een monolithische basis maakt belangrijk.
4. De handler ontvangt een gebeurtenis, selecteert daaruit gegevens die voor hem belangrijk zijn: in ons geval is dit de status van de bestelling "Geaccepteerd door de tracker" en werkt de besteleenheid in de hoofddatabase bij.

Als iemand een bestelling uit de monolithische tafel moet bestellen, dan kun je die daar ook lezen. De Orders-interface in de Shift Manager heeft dit bijvoorbeeld nodig:

Alle andere diensten kunnen zich ook abonneren op bestelgebeurtenissen van de tracker om ze voor zichzelf te gebruiken.

Als de bestelling na een tijdje in werking wordt genomen, verandert de status eerst in de database (Tracker-database) en wordt vervolgens onmiddellijk de gebeurtenis "OrderIn Progress" gegenereerd. Het komt ook in RMQ terecht, vanwaar het wordt gesynchroniseerd in een monolithische database en wordt geleverd aan andere services. Er kunnen onderweg verschillende problemen zijn, meer details hierover zijn te vinden in het rapport van Zhenya Peshkov over de implementatiedetails van Eventual Consistentie in de Tracker.

Definitieve architectuur na wijzigingen in Auth en Tracker

Samenvattend het tussenresultaat: Aanvankelijk had ik het idee om de negenjarige geschiedenis van het Dodo IS-systeem in één artikel te stoppen. Ik wilde snel en eenvoudig praten over de stadia van de evolutie. Toen ik echter voor het materiaal ging zitten, realiseerde ik me dat alles veel gecompliceerder en interessanter is dan het lijkt.

Nadenkend over de voordelen (of het ontbreken daarvan) van dergelijk materiaal, kwam ik tot de conclusie dat continue ontwikkeling onmogelijk is zonder volledige annalen van gebeurtenissen, gedetailleerde retrospectieven en analyse van mijn beslissingen uit het verleden.

Ik hoop dat het nuttig en interessant voor je was om meer te weten te komen over ons pad. Nu sta ik voor de keuze welk deel van het Dodo IS-systeem ik in het volgende artikel wil beschrijven: schrijf in de commentaren of stem.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Over welk onderdeel van Dodo IS zou je meer willen weten in het volgende artikel?

• 24,1%Vroege monoliet in Dodo IS (2011-2015)14

• 24,1%Eerste problemen en hun oplossingen (2015-2016)14

• 20,7%Het pad aan de clientzijde: gevel over sokkel (2016-2017)12

• 36,2%De geschiedenis van echte microservices (2018-2019)21

• 44,8%Volledig zagen van de monoliet en stabilisatie van de architectuur26

• 29,3%Over verdere plannen voor de ontwikkeling van het systeem17

• 19,0%Ik wil niets weten over Dodo IS11

58 gebruikers hebben gestemd. 6 gebruikers onthielden zich van stemming.

Bron: www.habr.com