🥇Dodo IS-arkitekturens historia: tidig monolit

Eller så är varje olyckligt monolitföretag olyckligt på sitt eget sätt.

Utvecklingen av Dodo IS-systemet började så snart Dodo Pizza-verksamheten startade – 2011. Idén baserades på en fullständig och total digitalisering av affärsprocesser, och på egen hand, vilket redan år 2011 väckte många frågor och skepticism. Men i 9 år nu har vi följt den här vägen – med vår egen utveckling, som började med en monolit.

Den här artikeln är ett "svar" på frågorna "Varför skriva om arkitekturen och göra så storskaliga och tidskrävande förändringar?" till föregående artikel "Dodo IS-arkitekturens historia: Resan inom backoffice". Jag börjar med hur utvecklingen av Dodo IS började, hur den ursprungliga arkitekturen såg ut, hur nya moduler dök upp och vilka problem som ledde till storskaliga förändringar.

Artikelserien "Vad är Dodo IS?" kommer att berätta om:

Tidig monolit i Dodo IS (2011-2015). (Du är här)
Backoffice-vägen: Separata databaser och buss.
Klientdelens väg: fasad över basen (2016-2017). (Pågår…)
Historien om riktiga mikrotjänster. (2018–2019). (Pågår…)
Slutförd tillskärning av monoliten och stabilisering av arkitekturen. (Pågår…)

Ursprunglig arkitektur

År 2011 såg Dodo IS-arkitekturen ut så här:

Den första modulen i arkitekturen är orderacceptans. Affärsprocessen var följande:

kunden ringer pizzerian;
chefen svarar i telefonen;
tar emot beställningar via telefon;
Samtidigt matas den in i gränssnittet för orderacceptering: information om klienten, orderuppgifter och leveransadress beaktas.

Informationssystemets gränssnitt såg ut ungefär så här…

Första versionen från oktober 2011:

Något förbättrad i januari 2012

Informationssystem Dodo Pizza Delivery Pizza Restaurant

Resurserna för att utveckla modulen för första orderacceptans var begränsade. Det var nödvändigt att göra mycket, snabbt och med ett litet team. Det lilla teamet består av två utvecklare som lade grunden för hela det framtida systemet.

Deras första beslut avgjorde teknikstackens framtida öde:

Backend på ASP.NET MVC, C# språk. Utvecklarna var dotnet-utvecklare, och den här stacken var bekant och trevlig för dem.
Frontend på Bootstrap och JQuery: användargränssnitt för anpassade stilar och skript.
MySQL-databas: inga licenskostnader, enkel att använda.
Servrar på Windows Server, eftersom .NET bara kunde vara under Windows (Vi kommer inte att diskutera Mono).

Fysiskt uttrycktes allt detta i den "dedikerade servern hos värden".

Arkitektur för orderacceptansapplikationen

Då pratade alla redan om mikrotjänster, och SOA hade använts i stora projekt i ungefär 5 år; till exempel släpptes WCF 2006. Men då valde de en pålitlig och beprövad lösning.

Här är det.

Asp.Net MVC är en Razor som producerar en serverrenderad HTML-sida när den begärs från ett formulär eller en klient. På klienten visar CSS- och JS-skript redan information och kör, om nödvändigt, AJAX-förfrågningar via JQuery.

Förfrågningar på servern går till *Controller-klasserna, där metoden bearbetar och genererar den slutliga HTML-sidan. Styrenheter gör förfrågningar till ett logiklager som kallas *Tjänster. Var och en av tjänsterna motsvarade någon aspekt av verksamheten:

Till exempel tillhandahöll DepartmentStructureService information om pizzerior, uppdelade efter avdelning. En avdelning är en grupp pizzerior som drivs av en franchisetagare.
ReceivingOrdersService accepterade och beräknade ordersammansättningen.
Och SmsService skickade SMS genom att anropa API-tjänster för att skicka SMS.

Tjänsterna bearbetade data från databasen och lagrade affärslogik. Varje tjänst hade ett eller flera *Repositories med motsvarande namn. De innehöll redan frågor till lagrade procedurer i databasen och ett lager av mappers. Butikerna innehöll affärslogik, särskilt de som producerade rapporteringsdata. ORM användes inte, alla förlitade sig på handskriven SQL.

Det fanns också ett lager av domänmodell och vanliga hjälpklasser, till exempel Order-klassen, som lagrade ordningen. Där, i lagret, fanns en hjälpfunktion för att konvertera visningstexten enligt den valda valutan.

Allt detta kan representeras av följande modell:

Orderväg

Låt oss titta på en förenklad inledande väg för att skapa en sådan order.

Ursprungligen var webbplatsen statisk. Den hade priser på sig, och högst upp stod ett telefonnummer och orden ”Om du vill ha pizza, ring det här numret och beställ”. För att beställa behöver vi implementera ett enkelt flöde:

Kunden går till en statisk webbplats med priser, väljer produkter och ringer numret som anges på webbplatsen.
Kunden anger vilka produkter hen vill lägga till i beställningen.
Anger sin adress och namn.
Operatören accepterar ordern.
Ordern visas i gränssnittet för accepterade ordrar.

Allt börjar med menyvisningen. En inloggad användare/operatör accepterar endast en beställning åt gången. Därför kan utkastkorgen lagras i sin session (användarens session lagras i minnet). Det finns ett varukorgsobjekt som innehåller produkter och kundinformation.

Kunden namnger produkten, operatören trycker + bredvid produkten, och en begäran skickas till servern. Information om produkten hämtas från databasen och information om produkten läggs till i varukorgen.

Notera. Ja, här behöver du inte dra ut produkten ur databasen, utan överföra den från front-end. Men för tydlighetens skull visade jag sökvägen från databasen.

Ange sedan klientens adress och namn.

När du klickar på "Skapa beställning":

Vi skickar begäran till OrderController.SaveOrder().
Vi får varukorgen från sessionen, den innehåller produkter i den mängd vi behöver.
Vi kompletterar Cart med information om klienten och skickar den till AddOrder-metoden i ReceivingOrderService-klassen, där den sparas i databasen.
Databasen innehåller tabeller med en order, ordersammansättning, klient, och de är alla sammankopplade.
Ordervisningsgränssnittet hämtar de senaste ordrarna och visar dem.

Nya moduler

Att ta emot ordern var viktigt och nödvändigt. Du kan inte driva en pizzarestaurang om du inte har ett system för att ta emot beställningar att sälja den till. Därför började systemet få funktionalitet - ungefär från 2012 till 2015. Under denna tid dök många olika systemblock upp, som jag kommer att kalla moduler, i motsats till begreppet tjänst eller produkt.

En modul är en uppsättning funktioner som förenas av ett gemensamt affärsmål. Samtidigt är de fysiskt placerade i samma applikation.

Moduler kan kallas block i systemet. Till exempel är detta en rapporteringsmodul, administratörsgränssnitt, köksmatspårare, auktorisering. Dessa är alla olika användargränssnitt, vissa har till och med olika visuella stilar. Dessutom sker allt inom ramen för en enda applikation, en enda process.

Tekniskt sett var modulerna utformade som Area (denna idé fanns till och med kvar i asp.net-kärna). Det fanns separata filer för frontend, modeller och även deras egna kontrollklasser. Som ett resultat omvandlades systemet från detta…

...in i detta:

Vissa moduler implementeras som separata webbplatser (körbara projekt), på grund av helt separat funktionalitet och delvis på grund av något separat, mer fokuserad utveckling. Detta:

Plats - första versionen webbplatsen dodopizza.ru.
ExportLadda ner rapporter från Dodo IS för 1C.
Personlig — den anställdes personliga konto. Den utvecklades separat och har sin egen ingångspunkt och separata design.
fs — ett projekt för att hosta statiskt innehåll. Senare övergick vi från det och flyttade allt statiskt innehåll till Akamai CDN.

De återstående blocken fanns i BackOffice-applikationen.

Förklaring av namnen:

Kassör — Restaurangens kassa.
ShiftManager — gränssnitt för rollen ”Shift Manager”: operativ statistik om pizzeriaförsäljning, möjlighet att lägga till produkter på en stopplista, ändra en beställning.
OfficeManager — gränssnitt för rollen "Pizzeriachef" och "Franchisetagare". Det här avsnittet innehåller funktioner för att skapa en pizzeria, dess bonuskampanjer, anställa och arbeta med anställda samt rapporter.
PublicScreens - gränssnitt för TV-apparater och surfplattor som hänger på pizzerior. TV-apparaterna visar menyer, reklaminformation och orderstatus vid leverans.

De använde ett gemensamt servicelager, ett gemensamt block av Dodo.Core-domänklasser och en gemensam bas. Ibland kunde de också leda genom gångar till varandra. Inklusive separata webbplatser, såsom dodopizza.ru eller personal.dodopizza.ru, användes även allmänna tjänster.

När nya moduler dök upp försökte vi återanvända så mycket som möjligt den redan skapade koden för tjänster, lagrade procedurer och tabeller i databasen.

För att bättre förstå skalan på de moduler som tillverkats i systemet, här är ett diagram från 2012 med utvecklingsplaner:

År 2015 var allt på ritbordet och ännu mer var i produktion.

Ordermottagning har utvecklats till ett separat kontaktcenterblock, där ordern accepteras av en operatör.
Offentligt tillgängliga skärmar med menyer och information har dykt upp på pizzerior.
Köket har en modul som automatiskt spelar upp röstmeddelandet ”Ny pizza” när en ny beställning tas emot, och skriver även ut en faktura till budfirman. Detta förenklar processerna i köket avsevärt och gör att de anställda inte behöver bli distraherade av ett stort antal enkla operationer.
Leveransblocket blev en separat leveranskassa, där ordern gavs till kuriren som tidigare hade börjat sitt skift. Hans arbetstid beaktades vid beräkningen av hans lön.

Parallellt, från 2012 till 2015, dök fler än 10 utvecklare upp, 35 pizzerior öppnade, systemet utökades till Rumänien och förbereddes för öppningspunkter i USA. Utvecklarna hanterade inte längre alla uppgifter, utan var indelade i team. var och en specialiserad på sin egen del av systemet.

Problem

Inklusive på grund av arkitekturen (men inte bara).

Kaos i basen

En bas är praktiskt. Konsekvens kan uppnås i det, och detta görs med hjälp av de verktyg som är inbyggda i relationsdatabaser. Den är bekant och bekväm att arbeta med, särskilt om det finns få tabeller och lite data.

Men under fyra års utveckling innehöll databasen cirka 4 tabeller och 600 lagrade procedurer, varav många också innehöll logik. Tyvärr ger lagrade procedurer inte mycket fördelar när man arbetar med MySQL. De cachas inte av databasen, och att lagra logik i dem komplicerar utveckling och felsökning. Att återanvända kod är också svårt.

Många tabeller hade inte lämpliga index., någonstans, tvärtom, fanns det många index, vilket gjorde insättningen svår. Det var nödvändigt att modifiera cirka 20 tabeller – transaktionen för att skapa en order kunde ta cirka 3–5 sekunder.

Uppgifterna i tabellerna var inte alltid i den mest lämpliga formen.. Någonstans måste avnormalisering ske. En del av den regelbundet mottagna datan fanns i en kolumn i form av en XML-struktur, vilket ökade exekveringstiden, förlängde frågor och komplicerade utvecklingen.

Väldigt många ändringar gjordes i samma tabeller heterogena förfrågningar. Populära bord, som det som nämnts ovan, drabbades särskilt hårt ordrar eller bord pizzeria. De användes för att visa operativa gränssnitt i köket, analyser. Webbplatsen kontaktade dem också (dodopizza.ru), där det plötsligt kan komma in många förfrågningar när som helst.

Uppgifterna aggregerades inte. och många beräkningar gjordes i farten med hjälp av databasen. Detta skapade onödiga beräkningar och extra belastning.

Ofta hamnade koden i databasen när den inte behövde göra det. Någonstans fanns det inte tillräckligt med bulkoperationer, någonstans skulle det vara nödvändigt att dela upp en förfrågan i flera via koden för att påskynda och öka tillförlitligheten.

Sammanhållning och intrassling i kod

Modulerna som skulle ansvara för sin del av verksamheten gjorde det inte ärligt.. Några av dem hade dubbletter av funktioner för roller. Till exempel var en lokal marknadsförare som ansvarar för nätverkets marknadsföringsaktivitet i sin stad tvungen att använda både gränssnittet "Admin" (för att ställa in kampanjer) och gränssnittet "Office Manager" (för att se kampanjernas inverkan på verksamheten). Naturligtvis använde båda modulerna internt en tjänst som fungerade med bonuskampanjer.

Tjänster (klasser inom ett enda monolitiskt stort projekt) skulle kunna anropa varandra för att berika sina data.

Med själva modellklasserna som lagrar data, arbetet med koden gjordes annorlunda. Någonstans fanns det konstruktörer genom vilka man kunde ange obligatoriska fält. Någonstans gjordes detta genom offentliga fastigheter. Naturligtvis var det varierande att hämta och omvandla data från databasen.

Logiken fanns antingen i styrenheter eller i serviceklasser.

Det här verkar vara mindre problem, men de saktade ner utvecklingen avsevärt och minskade kvaliteten, vilket ledde till instabilitet och buggar.

Komplexiteten i storskalig utveckling

Svårigheter uppstod också i själva utvecklingen. Det var nödvändigt att skapa olika block i systemet, och parallellt. Det blev allt svårare att anpassa behoven hos varje komponent till en enda kodbas. Det var inte lätt att komma överens och tillfredsställa alla komponenter samtidigt. Till detta kom tekniska begränsningar, särskilt i basen och frontend. Det var nödvändigt att överge JQuery till förmån för ramverk på hög nivå, särskilt när det gäller klienttjänster (webbplats).

Vissa delar av systemet skulle kunna använda databaser som är mer lämpade för detta. Till exempel hade vi senare ett prejudikat där vi bytte från Redis till CosmosDB för att lagra ordervarukorgen.

Team och utvecklare som arbetade inom sitt område ville helt klart ha mer autonomi för sina tjänster, både vad gäller utveckling och utrullning. Konflikter vid sammanslagningar, problem vid utgåvor. Om detta problem är obetydligt för 5 utvecklare, så skulle allt bli allvarligare med 10, och särskilt med den planerade tillväxten. Och framöver skulle utvecklingen av en mobilapplikation ske (den startade 2017, och 2018 fanns det stort fall).

Olika delar av systemet krävde olika stabilitetsindikatorer., men på grund av systemets starka anslutning kunde vi inte säkerställa detta. Ett fel vid utvecklingen av en ny funktion i administratörspanelen kan mycket väl ha påverkat orderacceptansen på webbplatsen, eftersom koden är gemensam och återanvändbar, databasen och data är också desamma.

Det skulle förmodligen vara möjligt att undvika dessa fel och problem inom ramen för en sådan monolitisk-modulär arkitektur: skapa en ansvarsseparation, refaktorera både kod och databas, tydligt separera lagren från varandra och övervaka kvaliteten varje dag. De valda arkitektoniska lösningarna och fokus på snabb expansion av systemets funktionalitet ledde dock till problem vad gäller stabilitet.

Hur bloggen The Power of the Mind fick kassaregister på restauranger att gå sönder

Om pizzakedjans (och belastningens) tillväxt fortsatte i samma takt, skulle nedgångarna efter en tid vara sådana att systemet inte skulle stiga. Följande berättelse illustrerar väl de problem vi började möta 2015.

I bloggen «Sinnets kraft"Det fanns en widget som visade intäktsdata för hela nätverket för året. Widgeten åtkom till det publika Dodo API:et, som tillhandahåller dessa data. Denna statistik finns nu tillgänglig på http://dodopizzastory.com/. Widgeten visades på varje sida och gjorde förfrågningar med en timer var 20:e sekund. Begäran gick till api.dodopizza.ru och begärde:

antal pizzerior i kedjan;
nätverkets totala intäkter sedan årets början;
intäkter för idag.

Begäran om intäktsstatistik gick direkt till databasen och började begära data om ordrar, aggregera data i realtid och utfärda en summa.

Kassorna på restaurangerna gick till samma beställningsbord, laddade ner listan över accepterade beställningar för idag, och nya beställningar lades till i den. Kassorna gjorde sina förfrågningar var 5:e sekund eller när sidan uppdaterades.

Diagrammet såg ut så här:

En höst skrev Fjodor Ovchinnikov en lång och populär artikel på sin blogg. Många kom till bloggen och började läsa allt noggrant. Medan varje person som kom läste artikeln fungerade intäktswidgeten korrekt och begärde API:et var 20:e sekund.

API:et anropade en lagrad procedur för att beräkna summan av alla beställningar sedan årets början för alla pizzerior i kedjan. Aggregeringen baserades på ordertabellen, som är mycket populär. Alla kassor på alla restauranger som är öppna vid den tiden går dit. Kassorna slutade svara och beställningar accepterades inte. De accepterades inte heller från webbplatsen, dök inte upp i spåraren och skiftchefen kunde inte se dem i sitt gränssnitt.

Detta är inte den enda berättelsen. Hösten 2015 var systembelastningen kritisk varje fredag. Vi stängde av det publika API:et flera gånger, och en gång var vi till och med tvungna att stänga av webbplatsen eftersom ingenting längre hjälpte. Det fanns till och med en lista över tjänster med den ordning i vilken de skulle stängas av vid hög belastning.

Från och med denna tidpunkt börjar vår kamp med laster och för stabilisering av systemet (från hösten 2015 till hösten 2018). Det var då det hände.Det stora fallet". Senare förekom det även enstaka fel, av vilka några var ganska känsliga, men den allmänna perioden av instabilitet kan nu anses vara över.

Snabb tillväxt av företag

Varför kunde det inte göras bra direkt? Titta bara på följande grafer.

Även under 2014-2015 öppnades det i Rumänien och en öppning i USA förbereddes.

Nätverket växte mycket snabbt, nya länder öppnade, nya pizzeriaformat dök upp, till exempel en pizzeria öppnade i en food court. Allt detta krävde betydande uppmärksamhet för att utöka funktionerna hos Dodo IS. Utan alla dessa funktioner, utan spårning i köket, redovisning av produkter och förluster i systemet, visning av beställningens leverans i matsalen, skulle vi knappast diskutera den "rätta" arkitekturen och det "rätta" tillvägagångssättet för utveckling.

Ett annat hinder för en snabb revidering av arkitekturen och, i allmänhet, uppmärksamhet på tekniska problem var krisen 2014. Sådana här saker skadar teamens tillväxtpotential, särskilt för unga företag som Dodo Pizza.

Snabba lösningar som hjälpte

Problem behövde lösas. Konventionellt kan lösningar delas in i två grupper:

Snabba sådana som släcker branden och ger oss en liten säkerhetsmarginal och köper oss tid att göra förändringar.
Systemisk och därför långvarig. Omstrukturering av ett antal moduler, uppdelning av den monolitiska arkitekturen i separata tjänster (de flesta av dem är inte mikrotjänster utan snarare makrotjänster, och det finns ett inlägg om detta) rapport av Andrey Morevsky).

Den torra listan över snabba förändringar är följande:

Skala upp masterbasen

Naturligtvis är det första som görs för att bekämpa belastningen att öka serverkapaciteten. Detta gjordes för masterbasen och för webbservrar. Tyvärr är detta bara möjligt upp till en viss gräns; efter det blir det för dyrt.

Sedan 2014 har vi gått över till Azure, vi skrev även om detta ämne då i artikeln "Hur Dodo Pizza levererar pizza med hjälp av Microsoft Azure Cloud". Men efter en serie höjningar nådde servrarna för basen en prisgräns.

Basrepliker för läsning

Vi gjorde två replikor till basen:

Läsreplika för referensfrågor. Den används för att läsa kataloger, såsom stad, gata, pizzeria, produkter (långsamt ändrad domän), och i de gränssnitt där en liten fördröjning är acceptabel. Det fanns två av dessa replikor, vi säkerställde deras tillgänglighet på samma sätt som för mästarna.

ReadReplica för rapportfrågor. Denna databas hade lägre tillgänglighet, men alla rapporter gick till den. De kan ha stora förfrågningar om enorma datamängder, men de påverkar åtminstone inte huvuddatabasen och de operativa gränssnitten.

Cachar i kod

Det fanns inga cachar i koden någonstans (alls). Detta ledde till ytterligare, inte alltid nödvändiga, förfrågningar till den laddade databasen. Cachar fanns initialt både i minnet och på en extern cachetjänst, som var Redis. Allt ogiltigförklarades av tiden, inställningarna var specificerade i koden.

Flera servrar för backend

Applikationens backend behövde också skalas för att hantera ökade belastningar. Det var nödvändigt att skapa ett kluster från en IIS-server. Vi flyttade ansökningssession från minne till RedisCache, vilket gjorde det möjligt för oss att ha flera servrar bakom en enkel lastbalanserare i runda-rollen. Till en början användes samma Redis som för cacher, sedan delades den upp i flera.

Som ett resultat blev arkitekturen mer komplex...