Hei, habr. Påmelding til en ny kursstrøm er åpen akkurat nå på OTUS . På tampen av kursstart vil jeg dele min originalartikkel med deg.
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 skalerbarheten, gjør koden lettere å forstå, forbedrer feiltoleransen, og noen ganger vil du høre at de lar deg "rydde opp i koden din". La oss se på historien for å forstå formålet bak fremveksten av mikrotjenester.
Kort sagt, mikrotjenester i vår nåværende forståelse oppsto som følger: I 2011 trakk James Lewis, ved å analysere arbeidet til forskjellige selskaper, oppmerksomhet til fremveksten av et nytt "mikroapp"-mønster, som optimaliserte SOA når det gjaldt å akselerere utrullingen av tjenester. Noe senere, i 2012, på et arkitekturtoppmøte, ble mønsteret omdøpt til microservice. Dermed var det første målet med å introdusere mikrotjenester å forbedre det beryktede tid til markedet.
Mikrotjenester var på hypebølgen i 2015. I følge noen studier var ikke en eneste konferanse komplett uten en rapport om temaet mikrotjenester. Dessuten var noen konferanser utelukkende dedikert til mikrotjenester. I dag begynner mange prosjekter å bruke denne arkitektoniske stilen, og hvis prosjektet inneholder tonnevis med eldre kode, blir migrering til mikrotjenester sannsynligvis aktivt utført.
Til tross for alt det ovennevnte, kan et ganske lite antall utviklere fortsatt definere konseptet "mikrotjeneste". Men vi snakker om dette litt senere...
Monolith
Den arkitektoniske stilen som kontrasterer mikrotjenester er monolitten (eller alt-i-ett). Det gir sannsynligvis ikke mening å fortelle hva en monolitt er, så jeg vil umiddelbart liste opp ulempene med denne arkitektoniske stilen, som initierte videreutviklingen av arkitektoniske stiler: størrelse, tilkobling, distribusjon, skalerbarhet, pålitelighet og stivhet. Nedenfor foreslår jeg å ta en titt på hver av manglene separat.
Størrelse
Monolitten er veldig stor. Og den kommuniserer vanligvis med en veldig stor database. Applikasjonen blir for stor til at én utvikler i det hele tatt kan forstå. Bare de som har brukt mye tid på å jobbe med denne koden kan fungere godt med monolitten, mens nybegynnere vil bruke mye tid på å finne ut av monolitten og det er ingen garanti for at de vil finne ut av det. Vanligvis, når du jobber med en monolitt, er det alltid en "betinget" senior som kjenner monolitten mer eller mindre godt og slår hendene til andre nye utviklere i løpet av et og et halvt år. Naturligvis er en slik betinget senior et enkelt feilpunkt, og hans avgang kan føre til monolittens død.
Tilknytning
Monolitten er en "stor kule av gjørme", endringer som kan føre til uforutsigbare konsekvenser. Ved å gjøre endringer på ett sted kan du skade monolitten på et annet (det samme "du klødde deg i øret, *@ falt av"). Dette skyldes det faktum at komponentene i monolitten har svært komplekse og, viktigst av alt, ikke-åpenbare forhold.
Utplassering
Å distribuere en monolitt, på grunn av de komplekse forholdene mellom dens komponenter, er en lang prosess med sitt eget ritual. Et slikt ritual er vanligvis ikke fullstendig standardisert og videreføres "muntlig".
Skalerbarhet
Monolith-moduler kan ha motstridende ressursbehov, noe som krever at det inngås et kompromiss når det gjelder maskinvare. Tenk deg at du har en monolitt som består av tjenester A og B. Tjeneste A er krevende for størrelsen på harddisken, og tjeneste B er krevende for RAM. I dette tilfellet må enten maskinen som monolitten er installert på, støtte kravene til begge tjenestene, eller du må manuelt, kunstig deaktivere en av tjenestene.
Et annet eksempel (mer klassisk): tjeneste A er mye mer populær enn tjeneste B, så du vil at det skal være 100 tjenester A og 10 tjenester B. Igjen, to alternativer: enten distribuerer vi 100 fullverdige monolitter, eller på noen da tjenester B må deaktiveres manuelt.
Pålitelighet
Siden alle tjenester er plassert sammen, hvis monolitten faller, faller alle tjenester samtidig. Faktisk er dette kanskje ikke så ille, i det minste vil det ikke være noen delvise feil i et distribuert system, men på den annen side, på grunn av en feil i funksjonaliteten som brukes av 0.001 % av brukerne, 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 egen oppgave å beholde den samme senioren. Teknologistabelen som velges i starten av et prosjekt kan bli en blokk 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