Hej, Habr. I dag fortsætter jeg en række publikationer, som jeg skrev specifikt til starten på en ny strøm af kurset. .
Indledning
Valget af arkitektonisk stil er en af de grundlæggende tekniske beslutninger, når man bygger et informationssystem. I denne serie af artikler foreslår jeg at analysere de mest populære arkitektoniske stilarter til byggeapplikationer og besvare spørgsmålet om, hvornår hvilken arkitektonisk stil er mest at foretrække. I præsentationsprocessen vil jeg forsøge at tegne en logisk kæde, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikrotjenester.
В vi beskæftigede os med monolitten og kom til den konklusion, at monolitten har en række problemer: størrelse, tilslutningsmuligheder, udrulning, skalerbarhed, pålidelighed og stivhed.
Denne gang foreslår jeg at tale om mulighederne for at organisere et system som et sæt af moduler/biblioteker (komponentorienteret arkitektur) eller tjenester (serviceorienteret arkitektur).
Komponentorienteret arkitektur
Komponentorienteret arkitektur involverer eksekvering af et system som et sæt af komponenter, der kan bruges i både nuværende og fremtidige projekter. Når et system nedbrydes i komponenter, tages der hensyn til følgende: deres genanvendelighed, deres udskiftelighed, kontekstuafhængighed, udvidelsesmuligheder, indkapsling og uafhængighed.
Med korrekt brug af komponenter løses problemet med "den store kugle af snavs" (stor størrelse + høj kobling), og selve komponenterne kan være både samleenheder (moduler, biblioteker) og implementeringsenheder (tjenester). Implementeringsenheder er ikke altid knyttet til den kørende proces: for eksempel implementeres en webapplikation og en database sammen.
Oftest udvikles monolitter som et sæt moduler. Denne tilgang fører til uafhængig udvikling, men problemerne med uafhængig skalering og implementering, fejltolerance og uafhængighed af den overordnede teknologistack forbliver. Derfor er modulet en delvist selvstændig komponent.
Det største problem med sådan en monolit er, at opdelingen i moduler er rent logisk og let kan overtrædes af udviklere. Et kernemodul kan dukke op, som gradvist bliver til et affaldsplads, grafen over afhængigheder mellem moduler kan vokse, og så videre. For at undgå sådanne problemer bør udvikling udføres enten af et meget modent team eller under vejledning af en "arkitekt", der er engageret i fuldtidskodegennemgang og slår hænderne på udviklere, der overtræder den logiske struktur.
Den "ideelle" monolit er et sæt logisk adskilte moduler, som hver ser ind i sin egen database.
Serviceorienteret arkitektur
Hvis systemet formodes at være organiseret i form af et sæt tjenester, så taler vi om en serviceorienteret arkitektur. Dens principper er brugercentreret applikationsinteroperabilitet, genbrug af forretningstjenester, teknologistack-uafhængighed og autonomi (uafhængig udvikling, skalerbarhed og implementering).
Serviceorienteret arkitektur (SOA = service oriented architecture) løser alle de identificerede problemer i en monolit: kun én tjeneste påvirkes, når der sker en ændring, og en veldefineret API understøtter god indkapsling af komponenter.
Men ikke alt er så glat: SOA skaber nye problemer. Fjernopkald er dyrere end lokale, og omfordeling af ansvar mellem komponenter er blevet væsentligt dyrere.
Muligheden for uafhængig implementering er i øvrigt et meget vigtigt træk ved tjenesten. Hvis tjenester skal implementeres sammen eller i øvrigt i en bestemt rækkefølge, kan systemet ikke betragtes som serviceorienteret. I dette tilfælde taler de om en distribueret monolit (betragtet som et antimønster ikke kun fra SOAs synspunkt, men også fra mikroservicearkitekturens synspunkt).
Serviceorienteret arkitektur er godt understøttet af det arkitektoniske samfund og leverandører. Dette indebærer tilstedeværelsen af mange kurser og certificeringer, veludviklede mønstre. Sidstnævnte omfatter for eksempel den velkendte enterprise service bus (ESB = enterprise service bus). Samtidig er ESB en bagage fra leverandører; den skal ikke nødvendigvis bruges i SOA.
Populariteten af serviceorienteret arkitektur toppede omkring 2008, hvorefter den begyndte at falde, hvilket blev væsentligt mere dramatisk efter fremkomsten af mikrotjenester (~2015).
Konklusion
Efter at vi har diskuteret mulighederne for at organisere informationssystemer i form af services og moduler, foreslår jeg til sidst at gå videre til principperne for mikroservicearkitektur og være særligt opmærksom på forskellen mellem mikroservicearkitektur og serviceorienteret arkitektur i næste del.
Kilde: www.habr.com