{"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\/da\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Valg af arkitektonisk stil (del 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr. Lige nu er der \u00e5bent for tilmelding til et nyt hold i OTUS-kurset \u00abSoftware Architect\u00bb<\/a><\/noindex>. Forud for kursusstart vil jeg dele min egen artikel med dig.<\/i><\/b><\/p>\n

<\/p>\n

Introduktion<\/h2>\n

\nValget af arkitektonisk stil er en af de grundl\u00e6ggende tekniske beslutninger, n\u00e5r man bygger et informationssystem. I denne r\u00e6kke artikler vil jeg unders\u00f8ge de mest popul\u00e6re arkitektoniske stilarter for applikationsopbygning og besvare sp\u00f8rgsm\u00e5let om, hvorn\u00e5r hvilken arkitektonisk stil er mest foretrukken. Undervejs vil jeg fors\u00f8ge at f\u00f8re en logisk tr\u00e5d, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikroservices.
\n<\/a><\/noindex><\/p>\n

Lidt historie<\/h2>\n

\nHvis du pr\u00f8ver at stille sp\u00f8rgsm\u00e5let til udviklerne: \"Hvorfor er microservices n\u00f8dvendige?\", s\u00e5 f\u00e5r du de mest forskellige svar. Du vil h\u00f8re, at microservices forbedrer skal\u00e9rbarhed, g\u00f8r koden lettere at forst\u00e5, forbedrer fejltolerance, og nogle gange kan man h\u00f8re, at de tillader at \"rydde op i koden\". Lad os se tilbage i historien for at forst\u00e5, hvilket m\u00e5l der l\u00e5 bag fremkomsten af microservices.<\/p>\n

Kort sagt, blev microservices i vores nuv\u00e6rende forst\u00e5else til p\u00e5 f\u00f8lgende m\u00e5de: I 2011, mens James Lewis analyserede forskellige virksomheders arbejde, bem\u00e6rkede han fremkomsten af et nyt m\u00f8nster kaldet \"micro-app\", som optimerede SOA med hensyn til hurtigere udrulning af tjenester. Senere, i 2012, blev m\u00f8nsteret omd\u00f8bt til microservice p\u00e5 en arkitekturkonference. Dermed var det oprindelige m\u00e5l med implementeringen af microservices at forbedre den berygtede time to market<\/b>.<\/p>\n

I \"buzz-perioden\" var microservices fremtr\u00e6dende i 2015. If\u00f8lge nogle unders\u00f8gelser gik ingen konference uden et indl\u00e6g om microservices. Desuden var nogle konferencer udelukkende dedikeret til microservices. I dag starter mange projekter med anvendelse af denne arkitektoniske stil, og hvis projektet indeholder tonsvis af legacy-kode, er der helt sikkert gang i migreringen til microservices.<\/p>\n

P\u00e5 trods af alt dette er der stadig et forholdsvis lille antal udviklere, der kan definere begrebet \"microservice\". Men det vil vi tale om lidt senere\u2026<\/p>\n

Monolit<\/h2>\n

\nDen arkitektoniske stil, der mods\u00e6ttes microservice-stilen, er monolit (eller \"alt i \u00e9t\"). Det giver nok ikke mening at fort\u00e6lle, hvad en monolit er, s\u00e5 jeg vil straks liste ulemperne ved denne arkitektoniske stil, som initierede yderligere udvikling af arkitektoniske stilarter: st\u00f8rrelse, sammenh\u00e6ng, udrulning, skal\u00e9rbarhed, p\u00e5lidelighed og stivhed. Nedenfor foresl\u00e5r jeg at se n\u00e6rmere p\u00e5 hver af ulemperne.<\/p>\n

St\u00f8rrelse<\/h3>\n

\nMonolitten er meget stor. Og den kommunikerer som regel med en meget stor database. Applikationen bliver for stor til, at \u00e9n udvikler overhovedet kan forst\u00e5 den. Kun dem, der har brugt meget tid p\u00e5 denne kode, kan arbejde godt med monolitten, mens nybegyndere vil bruge meget tid p\u00e5 at fors\u00f8ge at forst\u00e5 monolitten, og det er ikke sikkert, at de lykkes. Normalt er der altid en slags 'senior', der kender monolitten nogenlunde godt, og som holder \u00f8je med de nye udviklere i l\u00f8bet af et \u00e5r til halvandet. Det er klart, at en s\u00e5dan senior er det eneste svage led, og hans eller hendes frav\u00e6r kan f\u00f8re til monolittens undergang. <\/p>\n

Sammenh\u00e6ng<\/h3>\n

\nMonolitten kan beskrives som en \"stor klump mudder\" (big ball of mud), hvor \u00e6ndringer kan f\u00f8re til uforudsigelige konsekvenser. At \u00e6ndre \u00e9n ting et sted kan skade monolitten et andet sted (det er den klassiske 'kl\u00f8 \u00f8ret og *@ det falder af'). Dette skyldes, at komponenterne i monolitten har meget komplekse og, vigtigst af alt, ikke-\u00e5benlyse interrelationer.<\/p>\n

Udrulning<\/h3>\n

\nUdrulning af monolitten, p\u00e5 grund af de komplekse relationer mellem dens komponenter, er en lang proces med sine egne ritualer. Et s\u00e5dant ritual er normalt ikke fuldst\u00e6ndig standardiseret og videregives \"mund til mund\". <\/p>\n

Skalering<\/h3>\n

\nModulerne i monolitten kan have konflikte behov for ressourcer, hvorfor det er n\u00f8dvendigt at s\u00f8ge kompromis fra et hardware-perspektiv. Forestil dig, at din monolit best\u00e5r af tjenester A og B. Tjeneste A kr\u00e6ver meget diskplads, mens tjeneste B kr\u00e6ver meget RAM. I s\u00e5 fald skal maskinen, som monolitten installeres p\u00e5, enten opfylde kravene fra begge tjenester, eller det bliver n\u00f8dvendigt at slukke for den ene tjeneste manuelt.<\/p>\n

Et andet eksempel (mere klassisk): Tjeneste A er meget mere popul\u00e6r end tjeneste B, s\u00e5 du \u00f8nsker, at der er 100 af tjeneste A og 10 af tjeneste B. Igen er der to muligheder: enten udruller vi 100 fuldgyldige monolitter, eller p\u00e5 nogle af dem m\u00e5 vi manuelt slukke for tjenesterne B. <\/p>\n

P\u00e5lidelighed<\/h3>\n

\nDa alle tjenester er samlet, falder alle tjenester samtidigt, hvis monolitten fejler. Faktisk er det m\u00e5ske ikke s\u00e5 skidt, da der i det mindste ikke vil v\u00e6re delvise fejl i et distribueret system. Men p\u00e5 den anden side kan en fejl i funktionaliteten, som 0,001% af brugerne anvender, f\u00f8re til tab af alle brugere i dit system. <\/p>\n

Stivhed<\/h3>\n

\nP\u00e5 grund af monolitens st\u00f8rrelse er det sv\u00e6rt at overg\u00e5 til nye teknologier. Som f\u00f8lge heraf bliver det en s\u00e6rskilt opgave at fastholde den s\u00e5kaldte senior. Den teknologistak, der blev valgt ved projektets start, kan blive en hindring for produktets udvikling. <\/p>\n

Konklusion<\/h2>\n

\nN\u00e6ste gang vil vi tale om, hvordan folk har fors\u00f8gt at l\u00f8se de n\u00e6vnte problemer ved at g\u00e5 over til komponenter og SOA.<\/p>\n

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

\n

L\u00e6s mere:<\/h4>\n

<\/p>\n