{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikrotjenester: hvad er det, hvorfor er det vigtigt, og hvorn\u00e5r skal man implementere dem?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jeg har l\u00e6nge \u00f8nsket at skrive en artikel om mikrotjenestearkitektur, men jeg er hele tiden blevet stoppet af to faktorer \u2014 jo mere jeg dykkede ned i emnet, desto mere syntes jeg, at det jeg ved, er \u00e5benlyst, og det jeg ikke ved, kr\u00e6ver endnu mere studier. P\u00e5 den anden side mener jeg, at der allerede er noget at diskutere for et bredt publikum. S\u00e5 alternative meninger er velkomne.
\n<\/a><\/noindex><\/p>\n

Conways lov og forbindelsen mellem forretning, organisation og informationssystem<\/h2>\n

\nJeg vil endnu en gang tillade mig at citere:<\/p>\n

\u00abEnhver organisation, der designer et system (i bred forstand) vil f\u00e5 et design, hvis struktur kopierer strukturen af teamene i denne organisation\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Efter min mening relaterer denne lov sig mere til fornuften i at organisere en virksomhed end direkte til informationssystemet. Jeg vil forklare det med et eksempel. Antag, at vi har en stabil forretningsmulighed med en livscyklus, der er s\u00e5 lang, at det giver mening at organisere et foretagende (det er ikke en trykfejl, men jeg holder meget af dette udtryk, som jeg har stj\u00e5let). Det er klart, at det underst\u00f8ttende system for denne virksomhed vil organisatorisk og procesm\u00e6ssigt svare til denne virksomhed.<\/p>\n

Forretningsorientering af informationssystemer<\/h2>\n

\n\"Mikrotjenester:
\n
\nJeg vil forklare det med et eksempel. Antag, at der er en forretningsmulighed for at organisere en virksomhed til at s\u00e6lge pizza. I version 1 (lad os kalde den den ikke-informationsbaserede) var virksomheden en pizzeria, kasse og leveringsservice. Denne version havde en lang levetid under forhold med lav volatilitet i den omgivende verden. Derefter kom version 2 \u2014 en mere avanceret, der kunne bruge informationssystemet som grundlag for en virksomhed med monolitisk arkitektur. Og her, efter min mening, opst\u00e5r der en virkelig uretf\u00e6rdighed over for monolitter \u2014 tilsyneladende matcher monolitisk arkitektur ikke virksomhedens dom\u00e6nemodel<\/b>. Hvis det var tilf\u00e6ldet, ville systemet slet ikke kunne fungere - i strid med den samme Conway-lov og sund fornuft. Nej, monolitisk arkitektur stemmer fuldt ud overens med forretningsmodellen p\u00e5 dette udviklingsstadium \u2014 jeg mener selvf\u00f8lgelig det stadium, hvor systemet allerede er opbygget og taget i brug. Det er en fuldst\u00e6ndig bem\u00e6rkelsesv\u00e6rdig kendsgerning, at uanset den arkitektoniske tilgang, vil version 3 af serviceorienteret arkitektur og version N af mikroservicearkitektur fungere lige godt. Hvor er fangsten?<\/p>\n

Alt flyder, alt \u00e6ndrer sig, eller er mikroservicer et redskab til at bek\u00e6mpe kompleksitet?<\/h2>\n

\n F\u00f8r vi forts\u00e6tter, lad os se p\u00e5 nogle misforst\u00e5elser omkring mikroservicearkitektur.<\/p>\n

Fork\u00e6mpere af mikroserviceprincippet taler ofte om, at opdelingen af et monolitisk system i mikroservicer forenkler udviklingsprocessen ved at reducere kodebasen for de enkelte tjenester. Efter min mening er dette udsagn komplet nonsens. Alvorligt, virker det virkelig komplekst at interagere inden for en monolit og homogen kode? Hvis det virkelig var tilf\u00e6ldet, ville alle projekter fra starten af v\u00e6re bygget som mikroservicer, mens praksis viser, at migration fra monolit til mikroservicer er meget mere udbredt. Kompleksitet forsvinder ikke, den overg\u00e5r blot fra individuelle moduler til gr\u00e6nseflader (uanset om det er databusser, RPC, API og andre protokoller) og orkestreringssystemer. Og det er komplekst! <\/p>\n

Fordelen ved at bruge en heterogen stab virker ogs\u00e5 tvivlsom. Jeg vil ikke argumentere for, at det ogs\u00e5 er muligt, men i virkeligheden sj\u00e6ldent ses (Bare for at v\u00e6re forudseende \u2014 det b\u00f8r finde sted \u2014 men mere som en konsekvens snarere end en fordel).<\/p>\n

Produktlivscyklus og servicelivscyklus<\/h2>\n

\nTag et kig igen p\u00e5 diagrammet ovenfor. Jeg n\u00e6vnte ikke tilf\u00e6ldigt den faldende livscyklus for den enkelte version af forretningen \u2014 i moderne tider er det netop accelerationen af overgangen mellem versioner, der er afg\u00f8rende for dens succes. Produktets succes bestemmes af hastigheden af validering af forretningshypoteser i det.<\/b>. Og her er, efter min mening, den vigtigste fordel ved mikroservicearkitektur skjult. Men lad os tage det skridt for skridt. <\/p>\n

Lad os g\u00e5 videre til den n\u00e6ste fase i evolutionen af informationssystemer \u2014 serviceorienteret arkitektur (SOA). S\u00e5 p\u00e5 et bestemt tidspunkt adskilte vi os i vores produkt langlivede tjenester<\/b> \u2014 langlivede i den forstand, at ved overgangen mellem versioner af produktet er der chance for, at livscyklussen for tjenesten vil vare l\u00e6ngere end livscyklussen for den n\u00e6ste version af produktet. Det ville v\u00e6re logisk ikke at \u00e6ndre dem overhovedet \u2014 vi er netop interesseret i hastigheden af overgangen til den n\u00e6ste version<\/b>. Men desv\u00e6rre er vi n\u00f8dt til at lave konstante \u00e6ndringer i tjenesterne \u2014 og her g\u00e6lder alt, hvad der kan t\u00e6nkes, fra DevOps-praksis til containerisering osv. Men det er stadig ikke mikrotjenester! <\/p>\n

Mikrotjenester som et middel til at bek\u00e6mpe kompleksitet\u2026 konfigurationsstyring<\/h2>\n

\n Og her kan vi endelig overg\u00e5 til den afg\u00f8rende rolle, som mikrotjenester spiller \u2014 det er en tilgang, der forenkler konfigurationsstyring af produktet. Mere specifikt beskriver funktionen af hver mikrotjeneste netop en forretningsfunktion inden for produktet i henhold til den dom\u00e6nemodel \u2014 og det er allerede aspekter, der lever ikke i kortlivede versioner, men i langlivede forretningsmuligheder. Og overgangen til den n\u00e6ste version af produktet sker bogstaveligt talt usynligt \u2014 du \u00e6ndrer\/tilf\u00f8jer \u00e9n mikrotjeneste, eller m\u00e5ske blot skemaet for deres interaktion, og pludselig befinder du dig allerede i fremtiden, efterladende gr\u00e6dende konkurrenter, der forts\u00e6tter med at hoppe mellem versioner af deres monolitter. Forestil dig nu, at der er et tilstr\u00e6kkeligt stort antal mikrotjenester med foruddefinerede gr\u00e6nseflader og forretningsmuligheder. Og du kommer og bygger strukturen af dit produkt ud fra eksisterende mikrotjenester \u2014 bare ved at tegne et diagram, for eksempel. Tillykke \u2014 du har f\u00e5et en platform \u2014 og nu kan du skabe dit forretning. <\/p>\n

Konklusioner<\/h2>\n

<\/p>\n