Hej, Habr. I dag fortsætter jeg min række af indlæg, som jeg har skrevet specielt til lanceringen af det nye kursusforløb. .
Introduktion
Valget af arkitektonisk stil er en af de grundlæggende tekniske beslutninger, når man bygger et informationssystem. I denne række artikler vil jeg undersøge de mest populære arkitektoniske stilarter for applikationsopbygning og besvare spørgsmålet om, hvornår hvilken arkitektonisk stil er mest foretrukken. Undervejs vil jeg forsøge at føre en logisk tråd, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikroservices.
I vi kiggede på monolitten og kom frem til, at monolitten har en række problemer: størrelse, sammenhæng, implementering, skalerbarhed, pålidelighed og stivhed.
Denne gang vil jeg gerne tale om mulighederne for at organisere systemet som et sæt moduler/biblioteker (komponentorienteret arkitektur) eller tjenester (tjenesteorienteret arkitektur).
Komponentorienteret arkitektur
Komponentorienteret arkitektur indebærer, at systemet udføres som et sæt komponenter, der kan anvendes i både nuværende og fremtidige projekter. Når systemet opdeles i komponenter, tages der hensyn til: egnethed til genanvendelse, udskiftelighed, uafhængighed af konteksten, udvidelsesmuligheder, indkapsling og uafhængighed.
Ved korrekt brug af komponenter løses problemet med "stor klump af skrald" (stor størrelse + høj sammenhæng), og selve komponenterne kan repræsentere både enheder af samling (moduler, biblioteker) og enheder af implementering (tjenester). Enheder af implementering afspejler ikke altid den udførte proces: for eksempel implementeres webapplikationen og databasen sammen.
Ofte bliver monolitter udviklet som et sæt moduler. Denne tilgang fører til uafhængighed i udviklingen, men problemerne med uafhængig skalerbarhed og implementering, fejltolerance og uafhængighed af den generelle teknologiske stak forbliver. Derfor er et modul en delvist uafhængig komponent.
Det største problem med et sådant monolit er, at opdelingen i moduler er rent logisk og let kan blive brudt af udviklerne. Der kan opstå et kerne-modul, der gradvist bliver en skrotbunke, afhængighedsgrafen mellem modulerne kan vokse osv. For at undgå sådanne problemer bør udviklingen udføres af et meget modent team eller under ledelse af en 'arkitekt', der på fuld tid beskæftiger sig med code review og irettesætter udviklere, der bryder den logiske struktur.
Den 'ideelle' monolit består af et sæt logisk adskilte moduler, hvor hvert modul tager højde for sin egen database.
Serviceorienteret arkitektur
Hvis der alligevel skal organiseres et system som et sæt af tjenester, drejer det sig om serviceorienteret arkitektur. Dens principper er: interoperabilitet mellem brugerorienterede applikationer, genbrug af forretningsservices, uafhængighed af teknologi og autonomi (uafhængig evolution, skalerbarhed og implementering).
Serviceorienteret arkitektur (SOA = service oriented architecture) løser alle de nævnte problemer med monolitten: ved ændringer berøres kun én service, og en klart defineret API sikrer en god indkapsling af komponenterne.
Men alt er ikke så glat: SOA fører til nye problemer. Fjerndkald er dyrere end lokale, og omfordeling af ansvar mellem komponenterne er blevet betydeligt dyrere.
For at sige det i forbifarten, muligheden for uafhængig implementering er en meget vigtig egenskab ved en service. Hvis tjenesterne skal implementeres sammen, eller endnu mere, i en bestemt rækkefølge, kan systemet ikke betragtes som serviceorienteret. I så fald tales der om en distribueret monolit (der anses for et antipattern, både i forhold til SOA og mikrotjenestearkitektur).
Serviceorienteret arkitektur understøttes godt af arkitekturcommunautet og leverandørerne. Dette medfører et væld af kurser og certificeringer, samt veludviklede mønstre. Sidstnævnte inkluderer for eksempel den velkendte enterprise service bus (ESB). Samtidig er ESB en bagage fra leverandørerne og skal ikke nødvendigvis bruges i SOA.
Toppen af populariteten for service-orienteret arkitektur lå omkring 2008, hvorefter den begyndte at falde, hvilket blev markant mere udtalt efter introduktionen af mikrotjenester (~2015).
Konklusion
Efter at have diskuteret mulighederne for at organisere informationssystemer som tjenester og moduler, foreslår jeg endelig at gå videre til principperne for mikrotjenestearkitektur og lægge særlig vægt på forskellen mellem mikrotjenestearkitektur og service-orienteret arkitektur i næste del.
Kilde: habr.com
