Hej Habr. Just nu öppnar OTUS ett nytt kursintag. Inför kursstarten vill jag dela med mig av min originalartikel.
Inledning
Valet av arkitektonisk stil är ett av de grundläggande tekniska besluten när man bygger ett informationssystem. I den här artikelserien föreslår jag att analysera de mest populära arkitektoniska stilarna för byggnadsapplikationer och svara på frågan om när vilken arkitektonisk stil är mest att föredra. I presentationsprocessen kommer jag att försöka rita en logisk kedja som förklarar utvecklingen av arkitektoniska stilar från monoliter till mikrotjänster.
Lite historia
Om du försöker fråga utvecklare ”Varför behöver vi mikrotjänster?” kommer du att få en mängd olika svar. Du kommer att höra att mikrotjänster förbättrar skalning, gör kod lättare att förstå, förbättrar feltoleransen, och ibland kommer du att höra att de låter dig ”städa upp koden”. Låt oss titta på historien för att förstå vilket syfte mikrotjänster hade i åtanke.
Kort sagt, mikrotjänster som vi förstår dem idag uppstod på följande sätt: År 2011 uppmärksammade James Lewis, när han analyserade olika företags arbete, framväxten av ett nytt mönster kallat "mikroapp", vilket optimerade SOA när det gäller att accelerera tjänstedistributionen. Lite senare, 2012, vid ett arkitekturtoppmöte, döptes mönstret om till mikrotjänster. Det ursprungliga målet med att introducera mikrotjänster var således att förbättra den ökända tid till marknaden.
Mikrotjänster var på "hypevågen" år 2015. Enligt vissa studier hölls inte en enda konferens utan en rapport om ämnet mikrotjänster. Dessutom var vissa konferenser uteslutande tillägnade mikrotjänster. Nu börjar många projekt använda denna arkitektoniska stil, och om projektet innehåller massor av äldre kod, är migreringen till mikrotjänster troligtvis aktiv.
Trots allt ovanstående finns det fortfarande en hel del utvecklare som kan definiera termen "mikrotjänst". Men vi kommer att prata om det lite senare...
Monolit
Den arkitektoniska stil som står i motsats till mikrotjänster är monoliten (eller "allt-i-ett"). Det är förmodligen ingen mening med att förklara vad en monolit är, så jag kommer omedelbart att lista nackdelarna med denna arkitektoniska stil, som initierade den vidare utvecklingen av arkitektoniska stilar: storlek, koppling, implementering, skalbarhet, tillförlitlighet och tröghet. Nedan föreslår jag att man bekanta sig med var och en av nackdelarna separat.
Storlek
Monoliten är väldigt stor. Och den kommunicerar vanligtvis med en väldigt stor databas. Applikationen blir i princip för stor för att en utvecklare ska kunna förstå den. Endast de som har spenderat mycket tid med den här koden kan arbeta bra med monoliten, medan nykomlingar kommer att spendera mycket tid på att försöka förstå monoliten och det är inte ett faktum att de kommer att förstå den. Vanligtvis, när man arbetar med en monolit, finns det alltid någon "villkorlig" senior som känner monoliten mer eller mindre väl och slår andra nya utvecklare på händerna i ett år eller ett och ett halvt år. Naturligtvis är en sådan villkorlig senior en enda felpunkt, och hans avhopp kan leda till monolitens död.
Samhörighet
En monolit är en "stor lerboll", vars förändringar kan leda till oförutsägbara konsekvenser. Genom att göra förändringar på ett ställe kan man skada monoliten på ett annat (samma "klipade mig i örat, *@ ramlade av"). Detta beror på att komponenterna i monoliten har mycket komplexa och, viktigast av allt, icke uppenbara samband.
Spridning
Utplaceringen av en monolit är, på grund av de komplexa relationerna mellan dess komponenter, en lång process med sin egen ritual. En sådan ritual är vanligtvis inte helt standardiserad och förs vidare "genom mun till mun".
Skalbarhet
Monolitmoduler kan ha motstridiga resurskrav, vilket är anledningen till att det är nödvändigt att söka en kompromiss när det gäller hårdvara. Tänk dig att du har en monolit som består av tjänsterna A och B. Tjänst A kräver hårddiskstorlek och tjänst B kräver RAM. I det här fallet måste antingen maskinen som monoliten är installerad på stödja kraven för båda tjänsterna, eller så måste du manuellt, artificiellt, inaktivera en av tjänsterna.
Ett annat exempel (mer klassiskt): tjänst A är mycket mer populär än tjänst B, så du vill ha 100 tjänster A och 10 tjänster B. Återigen, två alternativ: antingen distribuera 100 fullfjädrade monoliter, eller manuellt inaktivera tjänster B på några av dem.
Надежность
Eftersom alla tjänster är sammankopplade, om monoliten fallerar, fallerar alla tjänster samtidigt. Egentligen kanske detta inte är så illa, åtminstone kommer inte partiella fel i ett distribuerat system att inträffa, men å andra sidan, på grund av en bugg i funktionaliteten som 0.001% av användarna använder, kan du förlora alla användare av ditt system.
Tröghet
På grund av monolitens storlek är det svårt att byta till nya teknologier. Att behålla den där mycket villkorade senioren är därför en separat uppgift. Den teknologiska stack som valts i början av projektet kan bli ett hinder för produktens utveckling.
Slutsats
Nästa gång ska vi prata om hur man har försökt lösa dessa problem genom att gå över till komponenter och SOA.
Läs mer:
Källa: will.com
