Hei, Habr. I dag fortsetter jeg en serie publikasjoner som jeg skrev spesielt for starten av en ny strøm av kurset. .
Innledning
Valget av arkitektonisk stil er en av de grunnleggende tekniske avgjørelsene når man bygger et informasjonssystem. I denne artikkelserien foreslår jeg å analysere de mest populære arkitektoniske stilene for byggeapplikasjoner og svare på spørsmålet om når hvilken arkitektonisk stil er mest å foretrekke. I prosessen med presentasjonen vil jeg prøve å tegne en logisk kjede som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.
В vi tok for oss monolitten og kom til den konklusjonen at monolitten har en rekke problemer: størrelse, tilkobling, distribusjon, skalerbarhet, pålitelighet og rigiditet.
Denne gangen foreslår jeg å snakke om mulighetene for å organisere et system som et sett av moduler/biblioteker (komponentorientert arkitektur) eller tjenester (tjenesteorientert arkitektur).
Komponentorientert arkitektur
Komponentorientert arkitektur innebærer å utføre et system som et sett med komponenter som kan brukes i både nåværende og fremtidige prosjekter. Når et system brytes ned i komponenter, tas følgende i betraktning: gjenbrukbarhet, utskiftbarhet, kontekstuavhengighet, utvidbarhet, innkapsling og uavhengighet.
Med riktig bruk av komponenter løses problemet med "den store kulen av skitt" (stor størrelse + høy kobling), og selve komponentene kan være både monteringsenheter (moduler, biblioteker) og distribusjonsenheter (tjenester). Distribusjonsenheter er ikke alltid tilordnet den kjørende prosessen: for eksempel distribueres en webapplikasjon og en database sammen.
Oftest utvikles monolitter som et sett med moduler. Denne tilnærmingen fører til uavhengig utvikling, men problemene med uavhengig skalering og distribusjon, feiltoleranse og uavhengighet fra den generelle teknologistabelen gjenstår. Derfor er modulen en delvis uavhengig komponent.
Det største problemet med en slik monolitt er at inndelingen i moduler er rent logisk og lett kan krenkes av utviklere. En kjernemodul kan dukke opp, som gradvis blir til en søppelplass, grafen over avhengigheter mellom moduler kan vokse, og så videre. For å unngå slike problemer, bør utviklingen utføres enten av et veldig modent team, eller under veiledning av en "arkitekt" som er engasjert i kodegjennomgang på heltid og slår hendene på utviklere som bryter den logiske strukturen.
Den "ideelle" monolitten er et sett med logisk adskilte moduler, som hver ser inn i sin egen database.
Service Orientert Arkitektur
Hvis systemet er ment å være organisert i form av et sett med tjenester, så snakker vi om en tjenesteorientert arkitektur. Prinsippene er brukersentrisk applikasjonsinteroperabilitet, gjenbruk av forretningstjenester, uavhengighet av teknologistabel og autonomi (uavhengig utvikling, skalerbarhet og distribusjon).
Tjenesteorientert arkitektur (SOA = tjenesteorientert arkitektur) løser alle de identifiserte problemene til en monolitt: kun én tjeneste påvirkes når en endring skjer, og et veldefinert API støtter god innkapsling av komponenter.
Men ikke alt er så glatt: SOA skaper nye problemer. Fjernanrop er dyrere enn lokale, og omfordeling av ansvar mellom komponenter har blitt betydelig dyrere.
Muligheten for uavhengig distribusjon er forresten en svært viktig funksjon ved tjenesten. Hvis tjenester må distribueres sammen eller dessuten i en bestemt rekkefølge, kan ikke systemet anses som tjenesteorientert. I dette tilfellet snakker de om en distribuert monolitt (betraktet som et antimønster ikke bare fra SOAs synspunkt, men også fra synspunktet til mikrotjenestearkitektur).
Tjenesteorientert arkitektur er godt støttet av arkitektmiljøet og leverandører. Dette innebærer tilstedeværelsen av mange kurs og sertifiseringer, velutviklede mønstre. Sistnevnte inkluderer for eksempel den velkjente enterprise service bussen (ESB = enterprise service bus). Samtidig er ESB en bagasje fra leverandører, den trenger ikke nødvendigvis å brukes i SOA.
Populariteten til tjenesteorientert arkitektur toppet seg rundt 2008, hvoretter den begynte å avta, noe som ble betydelig mer dramatisk etter bruken av mikrotjenester (~2015).
Konklusjon
Etter at vi har diskutert mulighetene for å organisere informasjonssystemer i form av tjenester og moduler, foreslår jeg å til slutt gå videre til prinsippene for mikrotjenestearkitektur og vie spesielt oppmerksomhet til forskjellen mellom mikrotjenestearkitektur og tjenesteorientert arkitektur i neste del.
Kilde: www.habr.com