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 undersøgte monolitten og kom til den konklusion, at monolitten har en række problemer: størrelse, tilslutningsmuligheder, implementering, skalerbarhed, pålidelighed og inerti.
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).
Komponentbaseret arkitektur
Komponentorienteret arkitektur antager implementeringen af et system som et sæt af komponenter, der kan bruges både i nuværende og fremtidige projekter. Når et system opdeles i komponenter, tages følgende i betragtning: deres egnethed til genbrug, deres udskiftelighed, deres kontekstuafhængighed, udvidelsesmulighed, 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 komponenterne i sig selv kan repræsentere både samleenheder (moduler, biblioteker) og implementeringsenheder (tjenester). Implementeringsenheder er ikke altid knyttet til en kørende proces: for eksempel implementeres en webapplikation og en database sammen.
Monolitter udvikles oftest som et sæt af moduler. Denne tilgang sikrer udviklingsuafhængighed, men problemerne med uafhængig skalering og implementering, fejltolerance og uafhængighed af den overordnede teknologistak forbliver. Derfor er et modul en delvist uafhængig komponent.
Hovedproblemet med en sådan 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 skrald, en graf over afhængigheder mellem moduler kan vokse, og så videre. For at undgå sådanne problemer bør udviklingen udføres enten af et meget modent team eller under vejledning af en "arkitekt", der er fuldtids involveret i kodegennemgang og giver hånden til udviklere, der overtræder den logiske struktur.
Den "ideelle" monolit er et sæt af logisk adskilte moduler, som hver især kigger i sin egen database.
Serviceorienteret arkitektur
Hvis det alligevel antages, at systemet vil være organiseret som et sæt af tjenester, så taler vi om en serviceorienteret arkitektur. Dens principper er: kompatibilitet af brugerorienterede applikationer, genbrugelighed af forretningstjenester, uafhængighed af et sæt teknologier og autonomi (uafhængig udvikling, skalerbarhed og implementeringsevne).
Serviceorienteret arkitektur (SOA) løser alle de ovennævnte problemer med en monolit: når en ændring sker, påvirkes kun én tjeneste, og et veldefineret API opretholder god indkapsling af komponenter.
Men ikke alt går så glat: SOA giver anledning til nye problemer. Fjernopkald er dyrere end lokale opkald, og det er blevet betydeligt dyrere at omfordele ansvar mellem komponenterne.
Forresten er evnen til at implementere uafhængigt en meget vigtig funktion ved tjenesten. Hvis tjenester skal implementeres sammen, eller endnu mere i en bestemt rækkefølge, kan systemet ikke betragtes som serviceorienteret. I dette tilfælde taler de om en distribueret monolit (betragtes som et antimønster ikke kun fra SOA's synspunkt, men også fra mikroservicearkitekturens synspunkt).
Serviceorienteret arkitektur er godt understøttet af arkitektmiljøet og leverandører. Dette resulterer i tilstedeværelsen af mange kurser og certificeringer, veludviklede mønstre. Sidstnævnte omfatter for eksempel den velkendte enterprise service bus (ESB). Samtidig er ESB bagage fra leverandører, det behøver ikke nødvendigvis at blive brugt i SOA.
Serviceorienteret arkitektur toppede i popularitet omkring 2008, hvorefter den begyndte at falde, hvilket blev meget mere dramatisk efter fremkomsten af mikrotjenester (~2015).
Konklusion
Nu hvor vi har diskuteret mulighederne for at organisere informationssystemer i form af tjenester og moduler, foreslår jeg endelig at gå videre til principperne for mikroservicearkitektur og i næste del lægge særlig vægt på forskellen mellem mikroservicearkitektur og serviceorienteret arkitektur.
Kilde: www.habr.com
