Valg av arkitekturstil (del 1)

Hei, Habr. Akkurat nå er OTUS åpnet for påmelding til et nytt kull av kurset «Software Architect». I forkant av kursstart vil jeg dele min egen artikkel med dere.

Innledning

Valg av arkitektonisk stil er en av de grunnleggende tekniske avgjørelsene når man bygger et informasjonssystem. I denne artikkelserien ønsker jeg å gå gjennom de mest populære arkitektoniske stilene for applikasjonsbygging og svare på spørsmålet om når en arkitektonisk stil er mest foretrukket. I løpet av forklaringen vil jeg prøve å trekke en logisk følge som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.

Litt historie

Hvis du prøver å stille utviklere spørsmålet: «Hvorfor trenger vi mikrotjenester?», vil du få de mest varierte svarene. Du vil høre at mikrotjenester forbedrer skalerbarheten, forenkler forståelsen av koden, øker feilfriheten, og noen ganger kan det høres ut som om de lar deg «rydde opp i koden». La oss se på historien for å forstå hva som var målet med fremveksten av mikrotjenester.

Kort sagt, mikrotjenester i vår nåværende forståelse oppstod slik: I 2011 la James Lewis, i analyse av ulike selskapers arbeid, merke til fremveksten av et nytt mønster kalt «micro-app», som optimaliserte SOA med tanke på å fremskynde distribusjonen av tjenester. Senere, i 2012, ble mønsteret omdøpt til mikrotjeneste på en arkitektursummit. Dermed var det opprinnelige målet med innføringen av mikrotjenester å forbedre det velkjente time to market.

På bølgen av hype var mikrotjenester i 2015. Ifølge noen undersøkelser, var det ingen konferanse uten en presentasjon om mikrotjenester. Dessuten var noen konferanser utelukkende dedikert til mikrotjenester. I dag starter mange prosjekter med bruk av denne arkitektoniske stilen, og hvis prosjektet inneholder store mengder legacy-kode, skjer det sannsynligvis aktiv migrering til mikrotjenester.

Til tross for alt dette, er det fortsatt et relativt lite antall utviklere som kan definere begrepet «mikrotjeneste». Men om dette skal vi snakke litt senere...

Monolit

Den arkitekturtype der står i kontrast til mikrotjenester er monolitten (eller «alt-i-ett»). Det gir sannsynligvis ikke mening å forklarer hva en monolitt er, så jeg vil umiddelbart liste opp ulempene ved denne arkitekturtypen som har initiert videre utvikling av arkitekturstiler: størrelse, sammenkobling, distribusjon, skalerbarhet, pålitelighet og stivhet. Nedenfor tilbyr jeg å bli kjent med hver av ulempene hver for seg.

Størrelse

Monolitten er veldig stor. Og den snakker vanligvis med en veldig stor database. Applikasjonen blir for omfattende til at en enkelt utvikler i utgangspunktet kan forstå den. Bare de som har brukt mye tid med denne koden, kan jobbe godt med monolitten, mens nykommere vil bruke mye tid på å prøve å forstå monolitten, med usikker utgang. Vanligvis finnes det alltid en slags «betinget» senior når man arbeider med monolitten, som kjenner den mer eller mindre godt og som gir pekefinger til andre nye utviklere i løpet av et år eller halvannet. Selvfølgelig er en slik betinget senior et enkelt feilpunkt, og hans avgang kan føre til monolittens død.

Sammenkobling

Monolitten representerer et «stort klump av søle» (big ball of mud), der endringer kan føre til uforutsigbare konsekvenser. Hvis man gjør endringer ett sted, kan man skade monolitten et annet sted (det som heter «klødd i øret, *@ falt av»). Dette henger sammen med at komponentene i monolitten har veldig komplekse og, viktigst av alt, ikke-opplagte forhold til hverandre.

Distribusjon

Distribusjonen av monolitten på grunn av de komplekse forholdene mellom dens komponenter — er en langvarig prosess med sine egne ritualer. Et slikt ritual er vanligvis ikke endelig standardisert og overleveres «mellom folk».

Skalerbarhet

Modulene til monolitten kan ha motstridende behov for ressurser, noe som gjør at man må finne en kompromiss når det gjelder maskinvare. Tenk deg at monolitten din består av tjenestene A og B. Tjeneste A er kresen på harddiskstørrelse, mens tjeneste B er på minne. I så fall må enten maskinen der monolitten installeres, oppfylle kravene til begge tjenester, eller man må manuelt og kunstig slå av en av tjenestene.

Et annet eksempel (mer klassisk): Tjeneste A er mye mer populær enn tjeneste B, så du ønsker at det skal være 100 av tjeneste A og 10 av tjeneste B. Igjen har vi to alternativer: enten setter vi opp 100 komplette monolitter, eller vi må manuelt deaktivere tjeneste B på noen av dem.

Pålitelighet

Siden alle tjenestene er samlet, hvis monolitten feiler, svikter alle tjenestene samtidig. Faktisk kan dette kanskje ikke være så ille, i det minste vil det ikke være delvise feil i et distribuert system, men på den annen side, på grunn av en feil i funksjonaliteten som kun 0,001% av brukerne benytter, kan du miste alle brukerne av systemet ditt.

Stivhet

På grunn av størrelsen på monolitten er det vanskelig å overføre til nye teknologier. Som et resultat fremstår opprettholdelse av den hypotetiske senioren som en separat oppgave. Teknologistakken som ble valgt i starten av prosjektet kan bli en hindring for produktutviklingen.

Konklusjon

Neste gang skal vi snakke om hvordan folk har forsøkt å løse de nevnte problemene ved å gå over til komponenter og SOA.

Les mer:

• Hvorfor SQL Server ikke garanterer sortering av resultater uten ORDER BY
• Arkitektur for utviklere og administratorer: Hvilke ferdigheter trenger de?

Kilde: habr.com