Hej, habr. Tilmelding til en ny kursusstrøm er åben lige nu hos OTUS . På tærsklen til kursets start vil jeg dele min originale artikel med dig.
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.
Lidt historie
Hvis du prøver at spørge udviklerne: "Hvorfor har vi brug for mikrotjenester?", vil du få en række svar. Du vil høre, at mikrotjenester forbedrer skalerbarheden, gør kode lettere at forstå, forbedrer fejltolerancen, og nogle gange vil du høre, at de giver dig mulighed for at "rydde op i din kode". Lad os se på historien for at forstå formålet bag fremkomsten af mikrotjenester.
Kort sagt opstod mikroservices i vores nuværende forståelse som følger: I 2011 gjorde James Lewis, ved at analysere forskellige virksomheders arbejde, opmærksomheden på fremkomsten af et nyt "micro-app" mønster, som optimerede SOA med hensyn til at accelerere implementeringen af tjenester. Noget senere, i 2012, på et arkitekturtopmøde, blev mønsteret omdøbt til microservice. Således var det oprindelige mål med at introducere mikrotjenester at forbedre det berygtede tid til markedet.
Mikrotjenester var på hypebølgen i 2015. Ifølge nogle undersøgelser var ikke en eneste konference komplet uden en rapport om emnet mikrotjenester. Desuden var nogle konferencer udelukkende dedikeret til mikrotjenester. I dag begynder mange projekter at bruge denne arkitektoniske stil, og hvis projektet indeholder tonsvis af ældre kode, så udføres migrering til mikrotjenester sandsynligvis aktivt.
På trods af alt ovenstående kan et ret lille antal udviklere stadig definere begrebet "mikroservice". Men det taler vi om lidt senere...
Monolit
Den arkitektoniske stil, der kontrasterer mikrotjenester, er monolitten (eller alt-i-en). Det giver nok ikke mening at fortælle, hvad en monolit er, så jeg vil straks opremse ulemperne ved denne arkitektoniske stil, som igangsatte den videre udvikling af arkitektoniske stilarter: størrelse, tilslutningsmuligheder, udrulning, skalerbarhed, pålidelighed og stivhed. Nedenfor foreslår jeg at tage et kig på hver af manglerne separat.
størrelse
Monolitten er meget stor. Og det kommunikerer normalt med en meget stor database. Applikationen bliver for stor til, at én udvikler overhovedet kan forstå. Kun dem, der har brugt meget tid på at arbejde på denne kode, kan arbejde godt med monolitten, mens begyndere vil bruge meget tid på at finde ud af monolitten, og der er ingen garanti for, at de vil finde ud af det. Normalt, når man arbejder med en monolit, er der altid en "betinget" senior, der kender monolitten mere eller mindre godt og slår hænderne på andre nye udviklere inden for halvandet år. Naturligvis er en sådan betinget senior et enkelt fejlpunkt, og hans afgang kan føre til monolittens død.
Forbundethed
Monolitten er en "stor kugle af mudder", ændringer i som kan føre til uforudsigelige konsekvenser. Ved at foretage ændringer ét sted kan du beskadige monolitten et andet (det samme "du kløede dit øre, *@ faldt af"). Dette skyldes det faktum, at komponenterne i monolitten har meget komplekse og, vigtigst af alt, ikke-indlysende forhold.
Implementering
At implementere en monolit, på grund af de komplekse forhold mellem dens komponenter, er en lang proces med sit eget ritual. Et sådant ritual er normalt ikke fuldstændig standardiseret og videregives "mundtligt".
Skalerbarhed
Monolith-moduler kan have modstridende ressourcebehov, hvilket kræver, at der indgås et kompromis med hensyn til hardware. Forestil dig, at du har en monolit bestående af tjenester A og B. Service A er krævende for størrelsen på harddisken, og service B er krævende for RAM. I dette tilfælde skal enten maskinen, som monolitten er installeret på, understøtte kravene til begge tjenester, eller du bliver nødt til manuelt, kunstigt at deaktivere en af tjenesterne.
Et andet eksempel (mere klassisk): tjeneste A er meget mere populær end tjeneste B, så du vil have, at der skal være 100 tjenester A og 10 tjenester B. Igen, to muligheder: enten implementerer vi 100 fuldgyldige monolitter, eller på nogle så tjenester B skal deaktiveres manuelt.
Pålidelighed
Da alle tjenester er placeret sammen, falder monolitten, så falder alle tjenester på én gang. Faktisk er dette måske ikke så slemt, i det mindste vil der ikke være delvise fejl i et distribueret system, men på den anden side, på grund af en fejl i funktionaliteten, som bruges af 0.001% af brugerne, kan du miste alle brugerne af dit system.
Træghed
På grund af monolittens størrelse er det svært at skifte til nye teknologier. Som følge heraf er det en separat opgave at fastholde den samme senior. Den teknologistabel, der vælges i starten af et projekt, kan blive en blok, der hindrer udviklingen af produktet.
Konklusion
Næste gang vil vi tale om, hvordan folk har forsøgt at løse disse problemer ved at flytte til komponenter og SOA.
Læs mere:
Kilde: www.habr.com