{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Valg av arkitekturstil (del 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hei, Habr. Akkurat n\u00e5 er OTUS \u00e5pnet for p\u00e5melding til et nytt kull av kurset \u00abSoftware Architect\u00bb<\/a><\/noindex>. I forkant av kursstart vil jeg dele min egen artikkel med dere.<\/i><\/b><\/p>\n

<\/p>\n

Innledning<\/h2>\n

\nValg av arkitektonisk stil er en av de grunnleggende tekniske avgj\u00f8relsene n\u00e5r man bygger et informasjonssystem. I denne artikkelserien \u00f8nsker jeg \u00e5 g\u00e5 gjennom de mest popul\u00e6re arkitektoniske stilene for applikasjonsbygging og svare p\u00e5 sp\u00f8rsm\u00e5let om n\u00e5r en arkitektonisk stil er mest foretrukket. I l\u00f8pet av forklaringen vil jeg pr\u00f8ve \u00e5 trekke en logisk f\u00f8lge som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.
\n<\/a><\/noindex><\/p>\n

Litt historie<\/h2>\n

\nHvis du pr\u00f8ver \u00e5 stille utviklere sp\u00f8rsm\u00e5let: \u00abHvorfor trenger vi mikrotjenester?\u00bb, vil du f\u00e5 de mest varierte svarene. Du vil h\u00f8re at mikrotjenester forbedrer skalerbarheten, forenkler forst\u00e5elsen av koden, \u00f8ker feilfriheten, og noen ganger kan det h\u00f8res ut som om de lar deg \u00abrydde opp i koden\u00bb. La oss se p\u00e5 historien for \u00e5 forst\u00e5 hva som var m\u00e5let med fremveksten av mikrotjenester.<\/p>\n

Kort sagt, mikrotjenester i v\u00e5r n\u00e5v\u00e6rende forst\u00e5else oppstod slik: I 2011 la James Lewis, i analyse av ulike selskapers arbeid, merke til fremveksten av et nytt m\u00f8nster kalt \u00abmicro-app\u00bb, som optimaliserte SOA med tanke p\u00e5 \u00e5 fremskynde distribusjonen av tjenester. Senere, i 2012, ble m\u00f8nsteret omd\u00f8pt til mikrotjeneste p\u00e5 en arkitektursummit. Dermed var det opprinnelige m\u00e5let med innf\u00f8ringen av mikrotjenester \u00e5 forbedre det velkjente time to market<\/b>.<\/p>\n

P\u00e5 b\u00f8lgen av hype var mikrotjenester i 2015. If\u00f8lge noen unders\u00f8kelser, 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.<\/p>\n

Til tross for alt dette, er det fortsatt et relativt lite antall utviklere som kan definere begrepet \u00abmikrotjeneste\u00bb. Men om dette skal vi snakke litt senere...<\/p>\n

Monolit<\/h2>\n

\nDen arkitekturtype der st\u00e5r i kontrast til mikrotjenester er monolitten (eller \u00abalt-i-ett\u00bb). Det gir sannsynligvis ikke mening \u00e5 forklarer hva en monolitt er, s\u00e5 jeg vil umiddelbart liste opp ulempene ved denne arkitekturtypen som har initiert videre utvikling av arkitekturstiler: st\u00f8rrelse, sammenkobling, distribusjon, skalerbarhet, p\u00e5litelighet og stivhet. Nedenfor tilbyr jeg \u00e5 bli kjent med hver av ulempene hver for seg.<\/p>\n

St\u00f8rrelse<\/h3>\n

\nMonolitten 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\u00e5 den. Bare de som har brukt mye tid med denne koden, kan jobbe godt med monolitten, mens nykommere vil bruke mye tid p\u00e5 \u00e5 pr\u00f8ve \u00e5 forst\u00e5 monolitten, med usikker utgang. Vanligvis finnes det alltid en slags \u00abbetinget\u00bb senior n\u00e5r man arbeider med monolitten, som kjenner den mer eller mindre godt og som gir pekefinger til andre nye utviklere i l\u00f8pet av et \u00e5r eller halvannet. Selvf\u00f8lgelig er en slik betinget senior et enkelt feilpunkt, og hans avgang kan f\u00f8re til monolittens d\u00f8d. <\/p>\n

Sammenkobling<\/h3>\n

\nMonolitten representerer et \u00abstort klump av s\u00f8le\u00bb (big ball of mud), der endringer kan f\u00f8re til uforutsigbare konsekvenser. Hvis man gj\u00f8r endringer ett sted, kan man skade monolitten et annet sted (det som heter \u00abkl\u00f8dd i \u00f8ret, *@ falt av\u00bb). Dette henger sammen med at komponentene i monolitten har veldig komplekse og, viktigst av alt, ikke-opplagte forhold til hverandre.<\/p>\n

Distribusjon<\/h3>\n

\nDistribusjonen av monolitten p\u00e5 grunn av de komplekse forholdene mellom dens komponenter \u2014 er en langvarig prosess med sine egne ritualer. Et slikt ritual er vanligvis ikke endelig standardisert og overleveres \u00abmellom folk\u00bb. <\/p>\n

Skalerbarhet<\/h3>\n

\nModulene til monolitten kan ha motstridende behov for ressurser, noe som gj\u00f8r at man m\u00e5 finne en kompromiss n\u00e5r det gjelder maskinvare. Tenk deg at monolitten din best\u00e5r av tjenestene A og B. Tjeneste A er kresen p\u00e5 harddiskst\u00f8rrelse, mens tjeneste B er p\u00e5 minne. I s\u00e5 fall m\u00e5 enten maskinen der monolitten installeres, oppfylle kravene til begge tjenester, eller man m\u00e5 manuelt og kunstig sl\u00e5 av en av tjenestene.<\/p>\n

Et annet eksempel (mer klassisk): Tjeneste A er mye mer popul\u00e6r enn tjeneste B, s\u00e5 du \u00f8nsker at det skal v\u00e6re 100 av tjeneste A og 10 av tjeneste B. Igjen har vi to alternativer: enten setter vi opp 100 komplette monolitter, eller vi m\u00e5 manuelt deaktivere tjeneste B p\u00e5 noen av dem. <\/p>\n

P\u00e5litelighet<\/h3>\n

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

Stivhet<\/h3>\n

\nP\u00e5 grunn av st\u00f8rrelsen p\u00e5 monolitten er det vanskelig \u00e5 overg\u00e5 til nye teknologier. Som en konsekvens av dette blir det en egen oppgave \u00e5 beholde den samme betingede senioren. Teknologistacken som ble valgt i starten av prosjektet kan bli en hindring for produktutviklingen. <\/p>\n

Konklusjon<\/h2>\n

\nNeste gang skal vi snakke om hvordan folk har fors\u00f8kt \u00e5 l\u00f8se de nevnte problemene ved \u00e5 g\u00e5 over til komponenter og SOA.<\/p>\n

\"Valg<\/a><\/noindex><\/p>\n

\n

Les mer:<\/h4>\n

<\/p>\n