Valg av arkitektonisk stil (del 2)

Hei, Habr. I dag fortsetter jeg serien av publikasjoner som jeg har skrevet spesielt for å starte det nye kurset. «Software Architect».

Innledning

Valg av arkitektonisk stil er en av de grunnleggende tekniske avgjørelsene når man bygger et informasjonssystem. I denne artikkelserien ønsker jeg å gå gjennom de mest populære arkitektoniske stilene for applikasjonsbygging og svare på spørsmålet om når en arkitektonisk stil er mest foretrukket. I løpet av forklaringen vil jeg prøve å trekke en logisk følge som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.

I forrige gang Vi har gått gjennom monolitten og kommet til at den har en rekke problemer: størrelse, sammenkobling, distribusjon, skalerbarhet, pålitelighet og tungmodighet.

Denne gangen vil jeg snakke om mulighetene for å organisere systemet i form av et ensemble av moduler/biblioteker (komponentorientert arkitektur) eller tjenester (tjenesteorientert arkitektur).

Komponentorientert arkitektur

Komponentorientert arkitektur innebærer at systemet kjører som et ensemble av komponenter som kan brukes både i nåværende og fremtidige prosjekter. Når systemet deles opp i komponenter, tas det hensyn til: deres egnethet for gjenbruk, erstatting, uavhengighet fra konteksten, utvidbarhet, innkapsling og uavhengighet.

Når komponenter brukes riktig, løses problemet med "den store klumpen med dritt" (stor størrelse + høy sammenkobling), og komponentene kan representere både enheter for bygging (moduler, biblioteker) og distribusjon (tjenester). Distribusjonsenheter gjenspeiler ikke alltid den kjørende prosessen: for eksempel distribueres et webapplikasjon og en database sammen.

Monolitter utvikles oftest som et sett med moduler. Denne tilnærmingen fører til uavhengighet i utviklingen, men problemer med uavhengig skalering og distribusjon, feiltoleranse og uavhengighet fra den generelle teknologiske stakken forblir. Derfor er modulen en delvis uavhengig komponent.

Det største problemet med en slik monolitt er at oppdelingen i moduler er rent logisk og lett kan bli brutt av utviklerne. Det kan dukke opp en core-modul som gradvis utvikler seg til å bli en søppeldynge, og det kan oppstå en vekst i avhengighetsgrafen mellom modulene, og så videre. For å unngå slike problemer må utviklingen ledes av enten et veldig erfarent team eller under ledelse av en "arkitekt" som jobber heltid med kodegjennomgang og påpeker brudd på den logiske strukturen av utviklerne.

Den «ideelle» monolitt består av et sett logisk atskilte moduler, hvor hver av dem peker mot sin egen database.

Tjenesteorientert arkitektur

Hvis man likevel planlegger å organisere systemet som et sett tjenester, snakker man om tjenesteorientert arkitektur. Dens prinsipper er: kompatibilitet mellom brukerorienterte applikasjoner, gjenbruk av forretnings tjenester, uavhengighet fra teknologiske sett og autonomi (uavhengig evolusjon, skalerbarhet og distribuerbarhet).

Tjenesteorientert arkitektur (SOA = service oriented architecture) løser alle de merkede problemene med monolitten: ved endringer berøres kun én tjeneste, og et klart definert API opprettholder god innkapsling av komponentene.

Men ikke alt er så enkelt: SOA fører til nye problemer. Fjerntilkallinger er dyrere enn lokale, og omfordeling av oppgaver mellom komponentene har blitt betydelig dyrere.

For øvrig er muligheten for uavhengig distribusjon en veldig viktig egenskap ved tjenesten. Hvis tjenestene må distribueres sammen eller, enda verre, i en bestemt rekkefølge, kan ikke systemet betraktes som tjenesteorientert. I så fall snakker man om en distribuert monolitt (som anses som et antipattern både fra et SOA- og mikrotjenesteperspektiv).

Tjenesteorientert arkitektur får god støtte fra det arkitektoniske fellesskapet og leverandører. Herav kommer et stort antall kurs og sertifiseringer, samt velutviklede mønstre. Et av de mer kjente er enterprise service bus (ESB). Samtidig er ESB en bagasje fra leverandørene; den må ikke nødvendigvis brukes i SOA.

Toppunktet for populariteten til tjenesteorientert arkitektur var rundt 2008, etter dette begynte den å avta, og nedgangen ble betydelig brattere etter fremveksten av mikrotjenester (~2015).

Konklusjon

Etter at vi har diskutert mulighetene for organisering av informasjonssystemer som tjenester og moduler, foreslår jeg å gå videre til prinsippene for mikrotjenestearkitektur og gi særlig oppmerksomhet til forskjellen mellom mikrotjenestearkitektur og tjenesteorientert arkitektur i den neste delen.

Kilde: habr.com