Hej, Habr. Just nu har OTUS öppnat för nya ansökningar till kursen. . I god tid före kursens start vill jag dela med mig av min egen artikel.
Introduktion
Valet av arkitekturtyp är en av de grundläggande tekniska besluten vid uppbyggnaden av ett informationssystem. I denna artikelserie föreslår jag att vi går igenom de mest populära arkitekturstilarna för applikationsutveckling och besvarar frågan om när vilken arkitekturtyp är mest föredragen. Under redogörelsen kommer jag att försöka dra en logisk kedja som förklarar utvecklingen av arkitekturstilar från monoliter till mikrotjänster.
Lite historia
Om du ställer frågan till utvecklarna: "Varför behövs mikrotjänster?", får du de mest varierande svar. Du kommer att höra att mikrotjänster förbättrar skalbarheten, förenklar förståelsen av koden, ökar tillförlitligheten, och ibland hör man att de möjliggör "renare kod". Låt oss gå tillbaka i historien för att förstå vilket syfte som låg bakom införandet av mikrotjänster.
I korthet kan man säga att mikrotjänster, som vi förstår dem idag, uppstod på följande sätt: 2011 uppmärksammade James Lewis, när han analyserade arbeten från olika företag, en ny mönster "micro-app" som optimerade SOA för att påskynda distribuerandet av tjänster. Några år senare, 2012, blev mönstret omdöpt till mikrotjänst på en arkitekturkonferens. Således var det ursprungliga syftet med att införa mikrotjänster att förbättra den ökända time to market.
På "hajpföljden" var mikrotjänster populära 2015. Enligt vissa studier fanns det ingen konferens utan ett föredrag om mikrotjänster. Dessutom var vissa konferenser helt och hållet ägnade åt mikrotjänster. Idag inleds många projekt med detta arkitekturstil, och om ett projekt innehåller mycket legacy-kod, pågår det sannolikt aktivt migrering till mikrotjänster.
Trots allt ovanstående finns det fortfarande ett relativt litet antal utvecklare som kan definiera begreppet "mikrotjänst". Men vi kommer att diskutera detta lite senare...
Monolit
Den arkitekturstil som ställs mot mikrotjänster är monolit (eller "allt-i-ett"). Det är nog inte meningsfullt att förklara vad en monolit är, så jag listar direkt nackdelarna med denna arkitekturstil, som initierade utvecklingen av andra arkitekturstilar: storlek, koppling, distribution, skalbarhet, tillförlitlighet och tröghet. Nedan föreslår jag att vi bekantar oss med varje nackdel separat.
Dimensions
Monoliten är mycket stor. Den kommunicerar vanligtvis med en mycket stor databas. Applikationen blir för stor för att en enda utvecklare ska kunna förstå den. Endast de som har tillbringat tillräckligt med tid med denna kod kan arbeta bra med monoliten, medan nykomlingar kan spendera mycket tid på att försöka förstå den, utan garanti att de lyckas. Vanligtvis finns det alltid någon som är en slags «senior» och som känner till monoliten ganska väl och vägleder andra nya utvecklare under ett år eller ett och ett halvt. Det är uppenbart att en sådan senior utgör en enda felpunkt, och hans avfärd kan leda till monolitens undergång.
Sammanlänkning
Monoliten kan beskrivas som en «stor klump av smuts» (big ball of mud), där förändringar kan leda till oförutsägbara konsekvenser. Att göra ändringar på ett ställe kan skada monoliten på ett annat (det berömda «jag kliade mig bakom örat, och *@ föll av»). Detta beror på att komponenterna i monoliten har mycket komplexa och, viktigast av allt, otydliga relationer.
Distribution
Utrullningen av monoliten, 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 överförs «från mun till mun».
Skalbarhet
Moduler i monoliten kan ha konkurrerande resursbehov, vilket gör det nödvändigt att söka kompromisser ur ett hårdvaruperspektiv. Tänk dig att din monolit består av tjänster A och B. Tjänst A har stora krav på hårddiskens storlek, medan tjänst B kräver mycket RAM. I så fall måste maskinen där monoliten installeras antingen uppfylla kraven från båda tjänsterna, eller så måste man manuellt stänga av en av tjänsterna.
Ett annat exempel (mer klassiskt): tjänst A är betydligt mer populär än tjänst B, så du vill ha 100 enheter av tjänst A och 10 enheter av tjänst B. Återigen finns det två alternativ: antingen rullar vi ut 100 fullständiga monoliter, eller så måste vi manuellt stänga av tjänst B på några av dem.
Pålitlighet
Eftersom alla tjänster är samlade, om monoliten faller, så faller alla tjänster samtidigt. Faktum är att det kanske inte är så dåligt, åtminstone kommer det inte att finnas några delvisa fel i ett distribuerat system, men å andra sidan kan en bugg i en funktion som används av 0,001% av användarna göra att du förlorar alla användare av ditt system.
Rigiditet
På grund av monolitens storlek är det svårt att övergå till nya teknologier. Som en följd av detta framträder en särskild uppgift att behålla den så kallade senioren. Den valda teknologistacken i början av projektet kan bli ett hinder för produktutvecklingen.
Slutsats
Nästa gång kommer vi att diskutera hur människor har försökt lösa de nämnda problemen genom att övergå till komponenter och SOA.
Läs mer:
Källa: habr.com
