🥇Historien om Dodo IS-arkitekturen: tidig monolit

Eller så är varje olycklig företag med monolit en olycklig på sitt eget sätt.

Utvecklingen av Dodo IS-systemet började samma år som Dodo Pizzas verksamhet – 2011. Basen var idén om en fullständig och total digitalisering av affärsprocesserna, vilket gjordes i egen regi, något som redan då, 2011, väckte många frågor och skepticism. Men nu, efter nio år, fortsätter vi på denna väg – med 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ådana omfattande och långvariga förändringar?" till den föregående artikeln "Historien om Dodo IS-arkitekturen: vägen för backoffice".Jag börjar med hur utvecklingen av Dodo IS började, hur den ursprungliga arkitekturen såg ut, hur nya moduler kom till och vilka problem som ledde till omfattande förändringar.

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

Den tidiga monoliten i Dodo IS (2011-2015). (Du är här)
Vägen för backoffice: separata databaser och bussen.
Vägen för klientdelen: ett fasad över databasen (2016-2017). (Pågår…)
Historien om verkliga mikrotjänster. (2018-2019). (Pågår…)
Den avslutade nedskärningen av monoliten och stabiliseringen av arkitekturen. (Pågår…)

Den ursprungliga arkitekturen

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

Den första modulen i arkitekturen – beställningsmottagning. Affärsprocessen var sådan:

kunden ringer till pizzerian;
managern svarar;
tar emot beställningen per telefon;
samtidigt skriver han ner den i beställningsgränssnittet: information om kunden, detaljerna om beställningen, leveransadressen beaktas.

Gränssnittet för informationssystemet såg ungefär ut så här…

Den första versionen från oktober 2011:

Lite förbättrad i januari 2012

Dodo Pizza Informationssystem Delivery Pizza Restaurang

Resurserna för utvecklingen av den första beställningsmodulen var begränsade. Mycket skulle göras snabbt och med liten personalstyrka. Liten personalstyrka – det var två utvecklare som lade grunden för hela det framtida systemet.

Deras första beslut bestämde den tekniska stackens framtid:

Backend på ASP.NET MVC, språk C#. Utvecklarna var .NET-programmerare, denna stack var bekant och behaglig för dem.
Frontend på Bootstrap och jQuery: användargränssnitt med egen design och skript.
Databasen MySQL: utan licenskostnader, enkel att använda.
Servrar på Windows Server, eftersom .NET då endast kunde köras under Windows (Mono ska vi inte diskutera).

Fysiskt uttrycktes allt detta i "dedikera hos värden".

Arkitekturen för beställningsmottagningsapplikationen

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

Här är det.

Asp.Net MVC är Razor, som genererar en HTML-sida med rendering på servern på begäran från formulär eller klienten. På klienten visar CSS och JS-skript information och, vid behov, utför AJAX-anrop via JQuery.

Anropen på servern hamnar i klasser **Controller, där bearbetning och generation av den slutliga HTML-sidan äger rum i metoden. Kontrollerna gör anrop till logiklagret, kallat **Services. Varje tjänst svarade mot en aspekt av affärer:

Till exempel gav DepartmentStructureService information om pizzerior, om avdelningarna. En avdelning är en grupp pizzerior under en franchisetagares ledning.
ReceivingOrdersService tog emot och beräknade beställningens innehåll.
Och SmsService skickade sms genom att anropa API-tjänster för att skicka sms.

Tjänsterna bearbetade data från databasen, lagrade affärslogik. I varje tjänst fanns en eller flera **Repository med motsvarande namn. Här fanns redan anrop till lagrade procedurer i databasen och en lagermappare. Den lagrade innehöll affärslogik, särskilt i de som utfärdade rapportdata. ORM användes inte, alla litade på handskriven SQL.

Det fanns också ett lager av domänmodeller och allmänna hjälparklasser, till exempel klassen Order, som lagrade beställningen. Där fanns också en hjälpare för att konvertera visningstexten baserat på den valda valutan.

Allt detta kan representeras av en sådan modell:

Beställningens väg

Låt oss titta på en förenklad initial väg för att skapa en sådan beställning.

I början var webbplatsen statisk. Den hade priser och överst fanns telefonnumret och texten "Vill du ha pizza — ring numret för att beställa". För att göra en beställning behöver vi genomföra ett enkelt flöde:

Kunden går in på den statiska webbplatsen med priser, väljer produkter och ringer numret som anges på webbplatsen.
Kunden nämner de produkter som han vill lägga till i beställningen.
Han nämner sin adress och namn.
Operatören tar emot beställningen.
Beställningen visas i gränssnittet för mottagna beställningar.

Allt börjar med att visa menyn. En inloggad användaroperatör kan endast ta ett enda beställning vid en given tidpunkt. Därför kan draft-korgen lagras i hans session (användarens session lagras i minnet). Där finns ett objekt Cart, som innehåller produkter och information om kunden.

Kunden nämner produkten, operatören klickar på + bredvid produkten och en begäran skickas till servern. Informationen om produkten hämtas från databasen och läggs till i korgen.

Anmärkning. Ja, här behöver man inte hämta produkten från databasen, utan kan överföra den från front-end. Men för tydlighetens skull visade jag just vägen från databasen.

Därefter skriver vi in kundens adress och namn.

Vid klick på "Skapa beställning":

Skickar vi begäran till OrderController.SaveOrder().
Vi får Cart från sessionen, där ligger produkterna i den mängd vi behöver.
Vi kompletterar Cart med kundinformation och överför det till metoden AddOrder i klassen ReceivingOrderService, där den sparas i databasen.
I databasen finns tabeller med beställningar, beställningens innehåll, kunden, och de är alla kopplade.
Gränssnittet för att visa beställningar går och hämtar de senaste beställningarna och visar dem.

Nya moduler

Mottagning av beställningar var viktig och nödvändig. Man kan inte driva en pizzeriabusiness utan en beställningsmottagning. Därför började systemet att växa i funktionalitet – ungefär mellan 2012 och 2015. Under denna tid kom många olika block av systemet, som jag kommer att kalla moduler, i motsats till begreppet tjänst eller produkt.

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

Moduler kan kallas block i systemet. Till exempel är detta modul för rapporter, admingränssnitt, produktspårning i köket, autentisering. Det är alla olika gränssnitt för användaren, och vissa har till och med olika visuella stilar. Samtidigt är alla inom en enda applikation, en enda fungerande process.

Tekniskt sett var modulerna utformade som Area (denna idé kvarstod till och med i asp.net core). Där fanns separata filer för front-end, modeller, samt egna kontrollklass. Resultatet blev att systemet omvandlades från sådan…

…till sådan:

Vissa moduler implementerades som separata webbplatser (exekverbara projekt) på grund av deras helt olika funktionalitet och delvis på grund av en mer separat, mer fokuserad utveckling. Dessa är:

Webbplats — den första versionen av webbplatsen dodopizza.ru.
Exportera: export av rapporter från Dodo IS till 1C.
Personlig — den personliga inloggningen för anställda. Utvecklades separat och har sin egen ingångspunkt och design.
fs — projektet för hosting av statisk innehåll. Senare övergick vi från det och flyttade all statisk till CDN Akamai.

Övriga block låg i BackOffice-applikationen.

Förklaring av namnen:

Cashier — Restaurangens kassa.
ShiftManager — gränssnitt för rollen "Skiftledare": aktuell statistik över pizzaförsäljningar, möjlighet att sätta produkter på stopplistan, ändra beställningar.
OfficeManager — gränssnitt för rollerna "Pizzeriaansvarig" och "Franchisetagare". Här samlas funktioner för att konfigurera pizzerian, dess bonuskampanjer, hantering av anställda, rapporter.
PublicScreens — gränssnitt för TV-apparater och tabletter som hänger i pizzerior. På TV:erna visas menyn, reklaminformation och beställningsstatus vid leverans.

De använde ett gemensamt tjänstelager, en gemensam block av domänklasser Dodo.Core, samt en gemensam databas. Ibland kunde de också göra övergångar mellan varandra. Även separata webbplatser, såsom dodopizza.ru eller personal.dodopizza.ru, kopplade till gemensamma tjänster.

Vid introduktionen av nya moduler strävade de efter att återanvända redan skapad kod för tjänster, lagrade procedurer och tabeller i databasen så mycket som möjligt.

För att bättre förstå omfattningen av modulerna som skapades i systemet, här är en diagram från 2012 med utvecklingsplaner:

År 2015 var allt på diagrammet och till och med mer i produktion.

Beställningsmottagningen utvecklades till en separat del av Kontaktcentret, där beställningar tas emot av operatörer.
Det dök upp offentliga skärmar med menyer och information som hänger i pizzerior.
I köket finns en modul som automatiskt återger röstmeddelandet "Ny pizza" när en ny beställning kommer in och skriver ut en följesedel för kuriren. Detta förenklar processerna i köket och gör att personalen kan fokusera mindre på ett stort antal enkla uppgifter.
Leveransblocket blev en separat Leveranskassa, där beställningen gavs till kuriren som tidigare ställt sig på skift. Hans arbetstid beaktades för att beräkna lönen.

Parallellt, från 2012 till 2015, kom mer än 10 utvecklare och 35 pizzerior öppnades, systemet rullades ut i Rumänien och förbereddes för öppning av punkter i USA. Utvecklarna sysslade inte längre med alla uppgifter utan delades upp i team, där varje team specialiserade sig på sin del av systemet.

Problem

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

Kaos i databasen

En databas är praktiskt. I den kan man uppnå konsekvens, dels tack vare funktioner inbyggda i relationsdatabaser. Att arbeta med den är bekant och praktiskt, särskilt om det finns få tabeller och lite data.

Men under fyra års utveckling fanns det runt 600 tabeller och 1500 lagrade procedurer, många med egen logik. Tyvärr ger lagrade procedurer inte något särskilt fördel vid arbete med MySQL. De cachas inte av databasen och att lagra logik i dem försvårar utvecklingen och felsökningen. Återanvändning av kod är också besvärligt.

Många tabeller hade inte lämpliga index.Å andra sidan fanns det, i vissa fall, väldigt många index, vilket försvårade insättning. Det behövde modifieras runt 20 tabeller — transaktionen för att skapa en beställning kunde ta runt 3-5 sekunder.

Data i tabellerna var inte alltid i den mest lämpliga formen.I vissa fall behövdes denormalisering. En del data som regelbundet mottogs var i en kolumn i form av en XML-struktur, vilket ökade exekveringstiden, förlängde förfrågningarna och försvårade utvecklingen.

Det gjordes mycket heterogena frågor mot samma tabeller.Särskilt drabbades populära tabeller, som den nämnda tabellen orders eller tabellen pizzeria.De användes för att visa operativa gränssnitt i köket, för analys. Även webbplatsendodopizza.ru, som när som helst kunde få många plötsliga förfrågningar.

Data var inte aggregerade och många beräkningar skedde på flyktiga sätt av databasen. Detta skapade onödiga beräkningar och extra belastning.

Koden gick ofta till databasen när den inte behövde göra det. I vissa fall saknades massoperationer, i andra fall behövde en fråga delas upp i flera genom koden för att öka hastigheten och förbättra tillförlitligheten.

Koppling och förvirring i koden

Modulerna, som skulle ansvara för sitt affärsområde, gjorde det inte ärligt.. Vissa av dem hade dubbleringar i funktionerna för rollerna. Till exempel, för en lokal marknadsförare som ansvarade för nätverkets marknadsföringsaktiviteter i sin stad, var det nödvändigt att använda både "Admin"-gränssnittet (för att skapa kampanjer) och "Kontorschef"-gränssnittet (för att se kampanjernas påverkan på affärerna). Självklart använde båda modulerna en gemensam tjänst som hanterade bonuskampanjer.

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

Själva klassmodellerna som lagrade data, arbetade i koden på olika sätt. På vissa ställen fanns konstruktorer där man kunde ange obligatoriska fält. På andra ställen gjordes detta via publika egenskaper. Självklart var det varierande hur data hämtades och omvandlades från databasen.

Logiken låg antingen i kontrollerna eller i servicelaser.

Detta kan verka vara små problem, men de fördröjde utvecklingen avsevärt och försämrade kvaliteten, vilket ledde till instabilitet och fel.

Svårigheterna med stor utveckling

Svårigheter uppstod även i själva utvecklingen. Det behövdes olika block i systemet, vilket innebar att man var tvungen att arbeta parallellt. Att rymma behoven hos varje komponent i en gemensam kod blev allt svårare. Det var inte lätt att komma överens och tillfredsställa alla komponenter samtidigt. Dessutom fanns det begränsningar i teknologierna, särskilt vad gällde databasen och frontend. Man var tvungen att överge jQuery till förmån för högre nivåer av ramverk, särskilt när det gällde klienttjänster (webbplatsen).

I vissa delar av systemet kunde databaser som passade bättre för detta användas,. Till exempel hade vi senare ett exempel på att vi gick från Redis till CosmosDB för att lagra kundvagnen.

Team och utvecklare som arbetade inom sina områden ville uppenbarligen ha mer självständighet för sina tjänster, både när det gällde utveckling och distribution. Konflikter vid sammanslagningar, problem vid releaser. Om detta problem inte var betydelsefullt för 5 utvecklare, så blev det allvarligare med 10, och ännu mer med planerad tillväxt. Dessutom skulle det vara utveckling av en mobilapp i framtiden (den startade 2017, och 2018 hade vi ett stort fall.).

Olika delar av systemet krävde olika stabilitetsmått., men på grund av systemets starka kopplingar kunde vi inte säkerställa detta. Ett fel vid utvecklingen av en ny funktion i adminpanelen kunde mycket väl ha påverkat beställningsmottagningen på webbplatsen, eftersom koden är gemensam och återanvändbar, och databasen och data också är enhetliga.

Det skulle nog ha varit möjligt att undvika dessa fel och problem inom en sådan monolitisk-modulär arkitektur: att göra en tydlig ansvarsfördelning, genomföra refaktorering av både koden och databasen, klart separera lagren från varandra, och övervaka kvaliteten varje dag. Men de valda arkitektoniska besluten och fokus på snabb funktionsexpansion ledde till problem med stabiliteten.

Hur bloggen Sila Uma bidrog till kassor i restauranger

Om tillväxten av pizzakedjan (och belastningen) hade fortsatt i samma takt, skulle fallen så småningom ha blivit så stora att systemet inte skulle kunna återhämta sig. En historia som tydligt illustrerar de problem vi började möta runt 2015.

I bloggen “Sila Uma” fanns det en widget som visade intäktsdata för hela kedjan under ett år. Widgeten gjorde anrop till Dodo's offentliga API, som tillhandahåller dessa uppgifter. Nu finns denna statistik tillgänglig på http://dodopizzastory.com/. Widgeten visades på varje sida och gjorde anrop var 20:e sekund. Anropet gick till api.dodopizza.ru och begärde:

antal pizzarestauranger i kedjan;
den totala intäkten för kedjan sedan årets början;
intäkten för idag.

Statistikförfrågan om intäkter gick direkt till databasen och började begära data om beställningar, aggregera data i realtid och returnera summan.

I samma beställningstabell gick kassorna i restauranger, de laddade upp listan över beställningar som tagits emot idag, och nya beställningar lades också till. Kassorna gjorde sina förfrågningar var 5:e sekund eller vid siduppdateringar.

Schemat såg ut så här:

En höst skrev Fedor Ovchinnikov en lång och populär artikel på sin blogg. Många människor kom till bloggen och började läsa noggrant. Medan varje besökare läste artikeln fungerade widgeten för intäkter som den skulle och begärde API var 20:e sekund.

API anropade en lagrad procedur för att beräkna summan av alla beställningar sedan början av året från alla pizzerior i kedjan. Aggreringen skedde i tabellen orders, som var mycket populär. Denna tabell innefattade alla kassor från alla öppna restauranger vid den tidpunkten. Kassorna slutade svara, beställningar togs inte emot. Dessutom kunde inte beställningar göras från webbplatsen, de dök inte upp på trackern och skiftchefen kunde inte se dem i sitt gränssnitt.

Detta är inte den enda historien. Fram till hösten 2015 var belastningen på systemet kritisk varje fredag. Flera gånger stängde vi ner det offentliga API:et, och en gång var vi till och med tvungna att stänga av webbplatsen eftersom ingenting hjälpte. Det fanns till och med en lista över tjänster med ordningen för avstängning vid allvarliga belastningar.

Från och med den tidpunkten började vår kamp mot belastningar och för stabilisering av systemet (från hösten 2015 till hösten 2018). Det var just då som "Det stora fallet" inträffade. Även efter det inträffade ibland störningar, vissa var ganska känsliga, men den övergripande perioden av instabilitet kan nu betraktas som överkommen.

Den kraftiga tillväxten av verksamheten

Varför kunde man inte "göra det bra från början"? Man behöver bara titta på följande diagram.

Det fanns även en öppning i Rumänien 2014-2015 och en plan för en öppning i USA.

Nätverket växte mycket snabbt, nya länder öppnades, nya format av pizzerior dök upp, till exempel en pizzeria i en food court. Allt detta krävde betydande uppmärksamhet till utvidgningen av funktioner i Dodo IS. Utan alla dessa funktioner, utan spårning i köket, hantering av ingredienser och förluster i systemet, samt visning av beställningar i food courten, skulle vi troligen inte diskutera "rätt" arkitektur och "rätt" metodik för utveckling.

Ytterligare hinder för en snabb översyn av arkitekturen och överhuvudtaget uppmärksamheten på tekniska problem var krisen 2014. Sådana situationer slår hårt mot tillväxtmöjligheterna för team, särskilt för ett ungt företag som Dodo Pizza.

Snabba lösningar som hjälpte

Problemen krävde lösningar. Villkorligt kan lösningarna delas in i två grupper:

Snabba, som släcker brand och ger en liten buffert samt vinner oss tid för förändringar.
Systematiska och därmed långsamma. Reengineering av flera moduler, uppdelning av den monolitiska arkitekturen i separata tjänster (de flesta av dem är inte mikro utan snarare makrotjänster och detta är det som finns) Andrey Morevsky rapport).

Den korta listan över snabba förändringar är som följande:

Skala upp masterdatabasen

Självklart, det första som görs för att hantera belastningarna är att öka serverns kapacitet. Detta gjordes för masterdatabasen och för webservrarna. Tyvärr är detta endast möjligt upp till en viss gräns, efter det blir det för dyrt.

Sedan 2014 har vi övergått till Azure, om detta skrev vi också vid den tiden i artikeln "Hur Dodo Pizza levererar pizza med hjälp av Microsoft Azure molnet". Men efter en serie av serverökningar för databasen nådde vi en kostnadsgräns.

Läsreplicor för databasen

Det gjordes två repliker för databasen:

ReadReplica för förfrågningar om referenser. Den används för att läsa referenser, typ stad, gata, pizzerior, produkter (långsamt förändrad domän), och i de gränssnitt där en liten fördröjning är acceptabel. Dessa repliker var 2, vi säkerställde deras tillgänglighet likväl som för mästaren.

ReadReplica för rapportförfrågningar. Denna databas hade lägre tillgänglighet, men alla rapporter gick genom den. Även om den hade tunga förfrågningar om enorma databeräkningar, påverkar de inte masterdatabasen eller operationella gränssnitt.

Cache i koden

Det fanns inga cacher i koden (alls). Detta ledde till ytterligare, inte alltid nödvändiga, förfrågningar i den belastade databasen. Cacher fanns först både i minnet och på en extern cachningstjänst, det var Redis. Allt invalidierades efter en viss tid, inställningarna angavs i koden.

Flera servrar för backend

Backend för applikationen behövde också skalas upp för att hantera ökade belastningar. Det var nödvändigt att göra en kluster från en iis-server. Vi flyttade applikationssessionen från minnet till RedisCache, vilket möjliggjorde flera servrar bakom en enkel lastbalanserare med round robin. Först användes samma Redis som för cacherna, sedan fördelade vi det på flera.

Resultatet blev en mer komplex arkitektur…