Hej, Habr. I dag fortsätter jag serien av inlägg som jag skrivit speciellt för starten av den nya kursomgången. .
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.
I Vi har gått igenom monoliten och kommit fram till att monoliten har ett antal problem: storlek, koppling, distribution, skalbarhet, tillförlitlighet och styvhet.
Denna gång föreslår jag att vi pratar om möjligheterna att organisera systemet som en uppsättning moduler/bibliotek (komponentorienterad arkitektur) eller tjänster (tjänstorienterad arkitektur).
Komponentorienterad arkitektur
Komponentorienterad arkitektur innebär att systemet utförs i form av en uppsättning komponenter som kan användas både i nuvarande och framtida projekt. Vid uppdelningen av systemet i komponenter beaktas: deras lämplighet för återanvändning, utbytbarhet, oberoende av kontext, utvidgbarhet, inkapsling och oberoende.
Med korrekt användning av komponenter löses problemet med "den stora klumpen av skräp" (stor storlek + hög koppling), och dessa komponenter kan representera både enheter av byggnad (moduler, bibliotek) och enheter av distribution (tjänster). Enheter av distribution avspeglas inte alltid i den körande processen: till exempel distribueras webbapplikationen och databasen tillsammans.
Monoliter utvecklas oftast i form av en uppsättning moduler. Denna metod leder till att oberoende utveckling säkerställs, men problemen med oberoende skalning och distribution, fel tolerans och oberoende av den gemensamma teknologistacken kvarstår. Det är just därför modulen är en delvis oberoende komponent.
Det största problemet med en sådan monolit är att modulindelningen är rent logisk och lätt kan brytas av utvecklarna. Det kan uppstå en kärnmodul som gradvis förvandlas till skräp, beroende på att beroendegrafen mellan modulerna växer och så vidare. För att undvika sådana problem bör utvecklingen utföras antingen av ett mycket moget team eller under ledning av en "arkitekt" som på heltid sysslar med kodgranskning och sätter stopp för utvecklare som bryter den logiska strukturen.
Den "ideala" monoliten består av en uppsättning logiskt separerade moduler, var och en med sin egen databas.
Tjänstorienterad arkitektur
Om man ändå planerar att organisera systemet som en uppsättning tjänster handlar det om tjänstorienterad arkitektur. Dess principer är: samverkan av användarcentrerade applikationer, återanvändning av affärstjänster, oberoende av teknikuppsättningar och autonomi (oberoende evolution, skalbarhet och distribution).
Tjänstorienterad arkitektur (SOA = service oriented architecture) löser alla de angivna problemen med monoliten: vid ändringar påverkas endast en tjänst, och ett tydligt definierat API upprätthåller god inkapsling av komponenterna.
Men allt är inte så enkelt: SOA leder till uppkomsten av nya problem. Fjärranrop är dyrare än lokala, och omfördelning av ansvar mellan komponenter har blivit avsevärt dyrare.
För övrigt är möjligheten till oberoende distribution en mycket viktig funktion av en tjänst. Om tjänster måste distribueras tillsammans eller ännu mer i en viss ordning kan systemet inte betraktas som tjänstorienterat. I sådana fall talar man om en distribuerad monolit (som anses vara en antipattern inte bara ur SOA:s perspektiv utan också ur mikrotjänstarkitekturens synvinkel).
Tjänstorienterad arkitektur stöds väl av arkitekturcommunityt och leverantörer. Därmed finns det många kurser och certifieringar, samt välutvecklade mönster. Ett av dessa är den inte okända företags tjänstebussen (ESB = enterprise service bus). ESB är ett arv från leverantörer och behöver inte nödvändigtvis användas inom SOA.
Den största populariteten för tjänsteorienterad arkitektur inträffade omkring 2008, efter vilket den började sjunka, och nedgången blev betydligt mer kraftig efter att mikroservicerna dök upp (runt 2015).
Slutsats
Efter att vi har diskuterat möjligheterna att organisera informationssystem som tjänster och moduler, föreslår jag att vi äntligen går vidare till principerna för mikroservicarkitektur och lägger särskild vikt vid skillnaden mellan mikroservicarkitektur och tjänsteorienterad arkitektur i nästa del.
Källa: habr.com
