Hej, habr. Anmälan till en ny kursström är öppen just nu på OTUS . På tröskeln till kursstart 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?", får du en mängd olika svar. Du kommer att höra att mikrotjänster förbättrar skalbarheten, gör koden lättare att förstå, förbättrar feltoleransen och ibland kommer du att höra att de tillåter dig att "städa upp din kod". Låt oss titta på historien för att förstå syftet bakom framväxten av mikrotjänster.
Kort sagt, mikrotjänster i vår nuvarande uppfattning uppstod enligt följande: 2011 uppmärksammade James Lewis, när han analyserade olika företags arbete, uppkomsten av ett nytt "mikroapp"-mönster, som optimerade SOA när det gäller att påskynda utbyggnaden av tjänster. Något senare, 2012, vid ett arkitekturtoppmöte, döptes mönstret om till microservice. Det ursprungliga målet med att introducera mikrotjänster var alltså att förbättra det ökända tid till marknaden.
Mikrotjänster var på hypevågen 2015. Enligt vissa studier var inte en enda konferens komplett utan en rapport om ämnet mikrotjänster. Dessutom var vissa konferenser dedikerade uteslutande till mikrotjänster. Nuförtiden börjar många projekt använda denna arkitektoniska stil, och om projektet innehåller massor av äldre kod, så genomförs troligen migrering till mikrotjänster aktivt.
Trots allt ovan kan ett ganska litet antal utvecklare fortfarande definiera begreppet "mikrotjänst". Men vi ska prata om det här lite senare...
Monolit
Den arkitektoniska stilen som kontrasterar mikrotjänster är monoliten (eller allt-i-ett). Det är förmodligen inte meningsfullt att berätta vad en monolit är, så jag kommer omedelbart att lista nackdelarna med denna arkitektoniska stil, som initierade vidareutvecklingen av arkitektoniska stilar: storlek, anslutningsmöjligheter, utbyggnad, skalbarhet, tillförlitlighet och styvhet. Nedan föreslår jag att vi tar en titt på var och en av bristerna separat.
Storlek
Monoliten är mycket stor. Och det brukar kommunicera med en väldigt stor databas. Applikationen blir för stor för en utvecklare att överhuvudtaget förstå. Endast de som har ägnat mycket tid åt att arbeta med den här koden kan fungera bra med monoliten, medan nybörjare kommer att spendera mycket tid på att försöka lista ut monoliten och det finns ingen garanti för att de kommer att lista ut det. Vanligtvis, när man arbetar med en monolit, finns det alltid någon "villkorlig" senior som känner till monoliten mer eller mindre väl och slår händerna på andra nya utvecklare inom ett och ett halvt år. Naturligtvis är en sådan villkorlig senior en enda punkt av misslyckande, och hans avgång kan leda till monolitens död.
Samhörighet
Monoliten är en "stor boll av lera", förändringar som kan leda till oförutsägbara konsekvenser. Genom att göra ändringar på ett ställe kan du skada monoliten på ett annat (samma "du kliade dig i örat, *@ föll av"). Detta beror på det faktum att komponenterna i monoliten har mycket komplexa och, viktigast av allt, icke-uppenbara relationer.
Spridning
Att distribuera en monolit, på grund av de komplexa relationerna mellan dess komponenter, är en lång process med sin egen ritual. En sådan ritual är vanligtvis inte helt standardiserad och förs vidare "muntligt".
Skalbarhet
Monolith-moduler kan ha motstridiga resursbehov, vilket kräver en kompromiss när det gäller hårdvara. Föreställ dig att du har en monolit som består av tjänster A och B. Service A är krävande för storleken på hårddisken och tjänst B kräver RAM. I det här fallet måste antingen maskinen på vilken monoliten är installerad 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 att det ska finnas 100 tjänster A och 10 tjänster B. Återigen, två alternativ: antingen distribuerar vi 100 fullfjädrade monoliter, eller på några då tjänster B måste inaktiveras manuellt.
Надежность
Eftersom alla tjänster är placerade tillsammans, om monoliten faller, faller alla tjänster på en gång. Faktum är att detta kanske inte är så illa, åtminstone kommer det inte att finnas några partiella fel i ett distribuerat system, men å andra sidan, på grund av en bugg i funktionalitet som används av 0.001% av användarna, kan du förlora alla användare av ditt system.
Tröghet
På grund av monolitens storlek är det svårt att byta till ny teknik. Som ett resultat är det en separat uppgift att behålla samma senior. Teknikstapeln som väljs i början av ett projekt kan bli ett block som hindrar utvecklingen av produkten.
Slutsats
Nästa gång ska vi prata om hur folk har försökt lösa dessa problem genom att gå över till komponenter och SOA.
Läs mer:
Källa: will.com