Hei, Habr. Akkurat nå åpner OTUS et nytt kursopptak I påvente av kursstart vil jeg gjerne dele min originale artikkel med dere.
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.
En bit av historien
Hvis du prøver å spørre utviklere: «Hvorfor trenger vi mikrotjenester?», vil du få en rekke svar. Du vil høre at mikrotjenester forbedrer skalering, gjør kode lettere å forstå, forbedrer feiltoleransen, og noen ganger vil du høre at de lar deg «rydde opp i koden». La oss se på historien for å forstå hvilket formål mikrotjenester hadde i tankene.
Kort sagt, mikrotjenester slik vi forstår dem i dag, oppsto på følgende måte: I 2011 trakk James Lewis, mens han analyserte arbeidet til ulike selskaper, oppmerksomhet til fremveksten av et nytt mønster kalt «mikroapp», som optimaliserte SOA med tanke på å akselerere tjenestedistribusjon. Litt senere, i 2012, på et arkitekturtoppmøte, ble mønsteret omdøpt til mikrotjenester. Dermed var det opprinnelige målet med å introdusere mikrotjenester å forbedre den beryktede tid til markedet.
Mikrotjenester var på «hypebølgen» i 2015. Ifølge noen studier ble det ikke holdt en eneste konferanse uten en rapport om emnet mikrotjenester. Dessuten var noen konferanser utelukkende dedikert til mikrotjenester. Nå begynner mange prosjekter å bruke denne arkitektoniske stilen, og hvis prosjektet inneholder tonnevis av eldre kode, er migreringen til mikrotjenester mest sannsynlig aktivt utført.
Til tross for alt det ovennevnte, er det fortsatt ganske mange utviklere som kan definere begrepet «mikrotjeneste». Men vi skal snakke om det litt senere ...
Monolith
Den arkitektoniske stilen som står i motsetning til mikrotjenester er monolitten (eller «alt-i-ett»). Det er sannsynligvis ikke noe poeng i å forklare hva en monolitt er, så jeg vil umiddelbart liste opp ulempene med denne arkitektoniske stilen, som startet videreutviklingen av arkitektoniske stiler: størrelse, kobling, utplassering, skalerbarhet, pålitelighet og treghet. Nedenfor foreslår jeg å gjøre seg kjent med hver av ulempene separat.
Størrelse
Monolitten er veldig stor. Og den kommuniserer vanligvis med en veldig stor database. Applikasjonen blir i prinsippet for stor til at én utvikler kan forstå den. Bare de som har brukt mye tid med denne koden kan jobbe bra med monolitten, mens nykommere vil bruke mye tid på å prøve å forstå monolitten, og det er ikke et faktum at de vil forstå den. Vanligvis, når man jobber med en monolitt, er det alltid en "betinget" senior som kjenner monolitten mer eller mindre godt og klasker andre nye utviklere på hendene i et år eller halvannet år. Naturligvis er en slik betinget senior et enkelt feilpunkt, og hans avgang kan føre til monolittens død.
Tilknytning
En monolitt er en «stor gjørmeball», hvis endringer kan føre til uforutsigbare konsekvenser. Ved å gjøre endringer på ett sted, kan du skade monolitten på et annet (den samme «kløt meg i øret, *@ falt av»). Dette skyldes det faktum at komponentene i monolitten har svært komplekse og, viktigst av alt, ikke-åpenbare sammenhenger.
Utplassering
Utplasseringen av en monolitt er en lang prosess med sitt eget ritual på grunn av de komplekse forholdene mellom komponentene. Et slikt ritual er vanligvis ikke fullstendig standardisert og formidles «jungeltelegrafen».
Skalerbarhet
Monolittmoduler kan ha motstridende ressurskrav, og det er derfor nødvendig å finne et kompromiss når det gjelder maskinvare. Tenk deg at du har en monolitt som består av tjeneste A og B. Tjeneste A krever harddiskstørrelse, og tjeneste B krever RAM. I dette tilfellet må enten maskinen som monolitten er installert på støtte kravene til begge tjenestene, eller så må du manuelt og kunstig deaktivere en av tjenestene.
Et annet eksempel (mer klassisk): tjeneste A er mye mer populær enn tjeneste B, så du vil ha 100 tjenester A og 10 tjenester B. Igjen, to alternativer: enten distribuere 100 fullverdige monolitter, eller deaktivere tjenester B manuelt på noen av dem.
Pålitelighet
Siden alle tjenestene er samlet, vil alle tjenestene feile samtidig hvis monolitten svikter. Egentlig er kanskje ikke dette så ille, i det minste vil ikke delvise feil i et distribuert system skje, men på den annen side, på grunn av en feil i funksjonaliteten som 0.001 % av brukerne bruker, kan du miste alle brukerne av systemet ditt.
Treghet
På grunn av størrelsen på monolitten er det vanskelig å bytte til nye teknologier. Som et resultat er det en separat oppgave å beholde den svært betingede senioren. Teknologistakken som velges i starten av prosjektet kan bli en blokkering som hindrer utviklingen av produktet.
Konklusjon
Neste gang skal vi snakke om hvordan folk har prøvd å løse disse problemene ved å gå over til komponenter og SOA.
Les mer:
Kilde: www.habr.com
