Hej, Habr. Idag fortsätter jag en serie publikationer som jag skrivit specifikt för starten av en ny ström av kursen. .
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.
В vi tog itu med monoliten och kom till slutsatsen att monoliten har ett antal problem: storlek, anslutning, utplacering, skalbarhet, tillförlitlighet och stelhet.
Den här gången föreslår jag att prata om möjligheterna att organisera ett system som en uppsättning moduler/bibliotek (komponentorienterad arkitektur) eller tjänster (tjänsteorienterad arkitektur).
Komponentorienterad arkitektur
Komponentorienterad arkitektur innebär att exekvera ett system som en uppsättning komponenter som kan användas i både nuvarande och framtida projekt. Vid nedbrytning av ett system i komponenter beaktas följande: deras återanvändbarhet, deras utbytbarhet, kontextoberoende, utbyggbarhet, inkapsling och oberoende.
Med korrekt användning av komponenter löses problemet med den "stora kulan av smuts" (stor storlek + hög koppling), och själva komponenterna kan vara både monteringsenheter (moduler, bibliotek) och distributionsenheter (tjänster). Driftsättningsenheter är inte alltid mappade till den pågående processen: till exempel distribueras en webbapplikation och en databas tillsammans.
Oftast utvecklas monoliter som en uppsättning moduler. Detta tillvägagångssätt leder till oberoende utveckling, men problemen med oberoende skalning och distribution, feltolerans och oberoende från den övergripande teknikstacken kvarstår. Det är därför modulen är en delvis fristående komponent.
Det största problemet med en sådan monolit är att uppdelningen i moduler är rent logisk och lätt kan kränkas av utvecklare. En kärnmodul kan dyka upp, som gradvis förvandlas till en soptipp, grafen över beroenden mellan moduler kan växa 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 är engagerad i kodgranskning på heltid och slår händerna på utvecklare som bryter mot den logiska strukturen.
Den "ideala" monoliten är en uppsättning logiskt separerade moduler, som var och en tittar in i sin egen databas.
Serviceinriktad arkitektur
Om systemet är tänkt att vara organiserat i form av en uppsättning tjänster, så talar vi om en tjänsteorienterad arkitektur. Dess principer är användarcentrerad applikationskompatibilitet, återanvändning av företagstjänster, oberoende av teknologistack och autonomi (oberoende utveckling, skalbarhet och driftsättning).
Tjänsteorienterad arkitektur (SOA = service oriented architecture) löser alla identifierade problem med en monolit: när en förändring sker påverkas endast en tjänst, och ett väldefinierat API stödjer bra inkapsling av komponenter.
Men allt är inte så smidigt: SOA skapar nya problem. Fjärrsamtal är dyrare än lokala, och omfördelning av ansvar mellan komponenter har blivit betydligt dyrare.
Möjligheten till oberoende distribution är förresten ett mycket viktigt inslag i tjänsten. Om tjänster måste distribueras tillsammans eller dessutom i en viss sekvens, kan systemet inte anses vara serviceinriktat. I det här fallet talar de om en distribuerad monolit (ansedd som ett antimönster inte bara ur SOAs synvinkel, utan också ur mikrotjänstarkitekturens synvinkel).
Tjänsteorienterad arkitektur stöds väl av arkitektsamhället och leverantörer. Detta innebär förekomsten av många kurser och certifieringar, välutvecklade mönster. Till den senare hör till exempel den välkända företagsservicebussen (ESB = enterprise service buss). Samtidigt är ESB ett bagage från leverantörer, det behöver inte nödvändigtvis användas i SOA.
Populariteten för tjänsteorienterad arkitektur nådde sin topp runt 2008, varefter den började minska, vilket blev betydligt mer dramatiskt efter tillkomsten av mikrotjänster (~2015).
Slutsats
Efter att vi diskuterat möjligheterna att organisera informationssystem i form av tjänster och moduler, föreslår jag att vi slutligen går över till principerna för mikrotjänstarkitektur och särskilt uppmärksammar skillnaden mellan mikrotjänstarkitektur och tjänsteorienterad arkitektur i nästa del.
Källa: will.com