{"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\/sv\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Val av arkitekturstil (del 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr. Just nu har OTUS \u00f6ppnat f\u00f6r nya ans\u00f6kningar till kursen. \u00abSoftware Architect\u00bb<\/a><\/noindex>. I god tid f\u00f6re kursens start vill jag dela med mig av min egen artikel.<\/i><\/b><\/p>\n

<\/p>\n

Introduktion<\/h2>\n

\nValet av arkitekturtyp \u00e4r en av de grundl\u00e4ggande tekniska besluten vid uppbyggnaden av ett informationssystem. I denna artikelserie f\u00f6resl\u00e5r jag att vi g\u00e5r igenom de mest popul\u00e4ra arkitekturstilarna f\u00f6r applikationsutveckling och besvarar fr\u00e5gan om n\u00e4r vilken arkitekturtyp \u00e4r mest f\u00f6redragen. Under redog\u00f6relsen kommer jag att f\u00f6rs\u00f6ka dra en logisk kedja som f\u00f6rklarar utvecklingen av arkitekturstilar fr\u00e5n monoliter till mikrotj\u00e4nster.
\n<\/a><\/noindex><\/p>\n

Lite historia<\/h2>\n

\nOm du st\u00e4ller fr\u00e5gan till utvecklarna: \"Varf\u00f6r beh\u00f6vs mikrotj\u00e4nster?\", f\u00e5r du de mest varierande svar. Du kommer att h\u00f6ra att mikrotj\u00e4nster f\u00f6rb\u00e4ttrar skalbarheten, f\u00f6renklar f\u00f6rst\u00e5elsen av koden, \u00f6kar tillf\u00f6rlitligheten, och ibland h\u00f6r man att de m\u00f6jligg\u00f6r \"renare kod\". L\u00e5t oss g\u00e5 tillbaka i historien f\u00f6r att f\u00f6rst\u00e5 vilket syfte som l\u00e5g bakom inf\u00f6randet av mikrotj\u00e4nster.<\/p>\n

I korthet kan man s\u00e4ga att mikrotj\u00e4nster, som vi f\u00f6rst\u00e5r dem idag, uppstod p\u00e5 f\u00f6ljande s\u00e4tt: 2011 uppm\u00e4rksammade James Lewis, n\u00e4r han analyserade arbeten fr\u00e5n olika f\u00f6retag, en ny m\u00f6nster \"micro-app\" som optimerade SOA f\u00f6r att p\u00e5skynda distribuerandet av tj\u00e4nster. N\u00e5gra \u00e5r senare, 2012, blev m\u00f6nstret omd\u00f6pt till mikrotj\u00e4nst p\u00e5 en arkitekturkonferens. S\u00e5ledes var det ursprungliga syftet med att inf\u00f6ra mikrotj\u00e4nster att f\u00f6rb\u00e4ttra den \u00f6k\u00e4nda time to market<\/b>.<\/p>\n

P\u00e5 \"hajpf\u00f6ljden\" var mikrotj\u00e4nster popul\u00e4ra 2015. Enligt vissa studier fanns det ingen konferens utan ett f\u00f6redrag om mikrotj\u00e4nster. Dessutom var vissa konferenser helt och h\u00e5llet \u00e4gnade \u00e5t mikrotj\u00e4nster. Idag inleds m\u00e5nga projekt med detta arkitekturstil, och om ett projekt inneh\u00e5ller mycket legacy-kod, p\u00e5g\u00e5r det sannolikt aktivt migrering till mikrotj\u00e4nster.<\/p>\n

Trots allt ovanst\u00e5ende finns det fortfarande ett relativt litet antal utvecklare som kan definiera begreppet \"mikrotj\u00e4nst\". Men vi kommer att diskutera detta lite senare...<\/p>\n

Monolit<\/h2>\n

\nDen arkitekturstil som st\u00e4lls mot mikrotj\u00e4nster \u00e4r monolit (eller \"allt-i-ett\"). Det \u00e4r nog inte meningsfullt att f\u00f6rklara vad en monolit \u00e4r, s\u00e5 jag listar direkt nackdelarna med denna arkitekturstil, som initierade utvecklingen av andra arkitekturstilar: storlek, koppling, distribution, skalbarhet, tillf\u00f6rlitlighet och tr\u00f6ghet. Nedan f\u00f6resl\u00e5r jag att vi bekantar oss med varje nackdel separat.<\/p>\n

Dimensions<\/h3>\n

\nMonoliten \u00e4r mycket stor. Den kommunicerar vanligtvis med en mycket stor databas. Applikationen blir f\u00f6r stor f\u00f6r att en enda utvecklare ska kunna f\u00f6rst\u00e5 den. Endast de som har tillbringat tillr\u00e4ckligt med tid med denna kod kan arbeta bra med monoliten, medan nykomlingar kan spendera mycket tid p\u00e5 att f\u00f6rs\u00f6ka f\u00f6rst\u00e5 den, utan garanti att de lyckas. Vanligtvis finns det alltid n\u00e5gon som \u00e4r en slags \u00absenior\u00bb och som k\u00e4nner till monoliten ganska v\u00e4l och v\u00e4gleder andra nya utvecklare under ett \u00e5r eller ett och ett halvt. Det \u00e4r uppenbart att en s\u00e5dan senior utg\u00f6r en enda felpunkt, och hans avf\u00e4rd kan leda till monolitens underg\u00e5ng. <\/p>\n

Sammanl\u00e4nkning<\/h3>\n

\nMonoliten kan beskrivas som en \u00abstor klump av smuts\u00bb (big ball of mud), d\u00e4r f\u00f6r\u00e4ndringar kan leda till of\u00f6ruts\u00e4gbara konsekvenser. Att g\u00f6ra \u00e4ndringar p\u00e5 ett st\u00e4lle kan skada monoliten p\u00e5 ett annat (det ber\u00f6mda \u00abjag kliade mig bakom \u00f6rat, och *@ f\u00f6ll av\u00bb). Detta beror p\u00e5 att komponenterna i monoliten har mycket komplexa och, viktigast av allt, otydliga relationer.<\/p>\n

Distribution<\/h3>\n

\nUtrullningen av monoliten, p\u00e5 grund av de komplexa relationerna mellan dess komponenter, \u00e4r en l\u00e5ng process med sin egen ritual. En s\u00e5dan ritual \u00e4r vanligtvis inte helt standardiserad och \u00f6verf\u00f6rs \u00abfr\u00e5n mun till mun\u00bb. <\/p>\n

Skalbarhet<\/h3>\n

\nModuler i monoliten kan ha konkurrerande resursbehov, vilket g\u00f6r det n\u00f6dv\u00e4ndigt att s\u00f6ka kompromisser ur ett h\u00e5rdvaruperspektiv. T\u00e4nk dig att din monolit best\u00e5r av tj\u00e4nster A och B. Tj\u00e4nst A har stora krav p\u00e5 h\u00e5rddiskens storlek, medan tj\u00e4nst B kr\u00e4ver mycket RAM. I s\u00e5 fall m\u00e5ste maskinen d\u00e4r monoliten installeras antingen uppfylla kraven fr\u00e5n b\u00e5da tj\u00e4nsterna, eller s\u00e5 m\u00e5ste man manuellt st\u00e4nga av en av tj\u00e4nsterna.<\/p>\n

Ett annat exempel (mer klassiskt): tj\u00e4nst A \u00e4r betydligt mer popul\u00e4r \u00e4n tj\u00e4nst B, s\u00e5 du vill ha 100 enheter av tj\u00e4nst A och 10 enheter av tj\u00e4nst B. \u00c5terigen finns det tv\u00e5 alternativ: antingen rullar vi ut 100 fullst\u00e4ndiga monoliter, eller s\u00e5 m\u00e5ste vi manuellt st\u00e4nga av tj\u00e4nst B p\u00e5 n\u00e5gra av dem. <\/p>\n

P\u00e5litlighet<\/h3>\n

\nEftersom alla tj\u00e4nster \u00e4r samlade, om monoliten faller, s\u00e5 faller alla tj\u00e4nster samtidigt. Faktum \u00e4r att det kanske inte \u00e4r s\u00e5 d\u00e5ligt, \u00e5tminstone kommer det inte att finnas n\u00e5gra delvisa fel i ett distribuerat system, men \u00e5 andra sidan kan en bugg i en funktion som anv\u00e4nds av 0,001% av anv\u00e4ndarna g\u00f6ra att du f\u00f6rlorar alla anv\u00e4ndare av ditt system. <\/p>\n

Rigiditet<\/h3>\n

\nP\u00e5 grund av storleken p\u00e5 monoliten \u00e4r det sv\u00e5rt att g\u00e5 \u00f6ver till nya teknologier. Som en f\u00f6ljd av detta framtr\u00e4der en s\u00e4rskild uppgift att beh\u00e5lla den s\u00e5 kallade senioren. Den valda teknologiska stacken i b\u00f6rjan av projektet kan bli ett hinder f\u00f6r produktens utveckling. <\/p>\n

Slutsats<\/h2>\n

\nN\u00e4sta g\u00e5ng kommer vi att diskutera hur m\u00e4nniskor har f\u00f6rs\u00f6kt l\u00f6sa de n\u00e4mnda problemen genom att \u00f6verg\u00e5 till komponenter och SOA.<\/p>\n

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

\n

L\u00e4s mer:<\/h4>\n

<\/p>\n