{"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\/sv\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikrotj\u00e4nster: vad de \u00e4r, varf\u00f6r de \u00e4r viktiga och n\u00e4r man b\u00f6r implementera dem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jag har l\u00e4nge velat skriva en artikel om mikrotj\u00e4nstarkitektur, men jag har stannat upp av tv\u00e5 sk\u00e4l \u2013 ju mer jag gr\u00e4ver i \u00e4mnet, desto mer verkar det som om det jag redan vet \u00e4r uppenbart, och det jag inte vet beh\u00f6ver jag fortfarande studera. \u00c5 andra sidan anser jag att det finns mycket att diskutera f\u00f6r en bredare publik. S\u00e5 alternativa \u00e5sikter v\u00e4lkomnas.
\n<\/a><\/noindex><\/p>\n

Conways lag och kopplingen mellan f\u00f6retag, organisation och informationssystem<\/h2>\n

\nJag till\u00e5ter mig \u00e4nnu en g\u00e5ng att citera:<\/p>\n

\u201cVarje organisation som designar ett system (i vid bem\u00e4rkelse) kommer att f\u00e5 ett design vars struktur speglar strukturen av de team som finns i organisationen\u201d
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Jag anser att denna lag i st\u00f6rre utstr\u00e4ckning relaterar till effektiviteten hos f\u00f6retagsorganisationen snarare \u00e4n direkt till informationssystemet. L\u00e5t mig f\u00f6rklara med ett exempel. Anta att vi har en tillr\u00e4ckligt stabil aff\u00e4rsm\u00f6jlighet med en livscykel som \u00e4r s\u00e5 l\u00e5ngvarig att det \u00e4r meningsfullt att organisera en verksamhet (detta \u00e4r ingen skrivfel, men jag gillar verkligen det h\u00e4r termen som jag har snott). Naturligtvis kommer det st\u00f6djande systemet f\u00f6r detta f\u00f6retag att organisatoriskt och processm\u00e4ssigt st\u00e4mma \u00f6verens med detta f\u00f6retag.<\/p>\n

Aff\u00e4rsorientering av informationssystem<\/h2>\n

\n\"Mikrotj\u00e4nster:
\n
\nL\u00e5t mig f\u00f6rklara med ett exempel. Anta att det finns en aff\u00e4rsm\u00f6jlighet att organisera en verksamhet f\u00f6r att s\u00e4lja pizza. I version V1 (l\u00e5t oss kalla den den icke-informationsbaserade) var f\u00f6retaget en pizzeria, en kassa och en leveranstj\u00e4nst. Denna version var l\u00e5nglivad under f\u00f6rh\u00e5llanden med l\u00e5g f\u00f6r\u00e4ndlighet i omv\u00e4rlden. Sedan kom version 2 \u2014 mer avancerad och kapabel att anv\u00e4nda ett informationssystem som grund f\u00f6r verksamheten med en monolitisk arkitektur. Och h\u00e4r, enligt mig, uppst\u00e5r verkligen en f\u00f6rf\u00e4rlig or\u00e4ttvisa gentemot monoliter \u2014 den p\u00e5st\u00e5tt monolitisk arkitektur motsvarar inte dom\u00e4nmodellen f\u00f6r aff\u00e4rsverksamheten<\/b>. Om s\u00e5 var fallet, skulle systemet inte kunna fungera alls - vilket strider mot samma Conway's lag och sunt f\u00f6rnuft. Nej, en monolitisk arkitektur motsvarar helt aff\u00e4rsmodellen i detta utvecklingsstadium av verksamheten - jag menar naturligtvis det stadium n\u00e4r systemet redan har skapats och implementerats. Det \u00e4r en helt fantastisk fakta att oavsett arkitektonisk metod kommer b\u00e5de den tj\u00e4nsteorienterade arkitekturen version 3 och den mikroservicesarkitekturen version N att fungera lika bra. Vad \u00e4r f\u00e4llan?<\/p>\n

Allt flyter, allt f\u00f6r\u00e4ndras eller \u00e4r mikroservicer ett medel f\u00f6r att bek\u00e4mpa komplexitet?<\/h2>\n

\n Innan vi forts\u00e4tter, l\u00e5t oss titta p\u00e5 n\u00e5gra missuppfattningar kring mikroservicesarkitektur.<\/p>\n

F\u00f6respr\u00e5kare f\u00f6r mikroservicesmetoden s\u00e4ger ofta att nedbrytning av monoliten till mikroservicer f\u00f6renklar utvecklingsprocessen genom att minska kodbasen f\u00f6r varje tj\u00e4nst. Enligt min \u00e5sikt \u00e4r detta p\u00e5st\u00e5ende ren nonsens. Seri\u00f6st, verkar det uppenbara samarbetet inom en monolit och homogen kod sv\u00e5rt? Om det verkligen var s\u00e5, skulle alla projekt initialt byggas som mikroservicer, medan praktiken visar att migration fr\u00e5n en monolit till mikroservicer \u00e4r mycket mer vanlig. Komplexiteten f\u00f6rsvinner inte, den \u00f6verg\u00e5r bara fr\u00e5n individuella moduler till gr\u00e4nssnitt (vare sig det \u00e4r databusser, RPC, API och andra protokoll) och orkestrerande system. Och det \u00e4r komplext! <\/p>\n

F\u00f6rdelarna med att anv\u00e4nda en heterogen stack \u00e4r ocks\u00e5 tveksamma. Jag kommer inte att h\u00e4vda att det ocks\u00e5 \u00e4r m\u00f6jligt, men i verkligheten f\u00f6rekommer det s\u00e4llan (F\u00f6r att g\u00e5 f\u00f6re \u2014 detta b\u00f6r faktiskt f\u00f6rekomma \u2014 men snarare som en konsekvens \u00e4n en f\u00f6rdel).<\/p>\n

Produktens livscykel och tj\u00e4nstens livscykel<\/h2>\n

\nTitta en g\u00e5ng till p\u00e5 diagrammet ovan. Jag p\u00e5pekade inte av en slump den minskande livscykeln f\u00f6r varje version av verksamheten \u2014 i moderna f\u00f6rh\u00e5llanden \u00e4r det just p\u00e5skyndandet av \u00f6verg\u00e5ngen mellan versioner som \u00e4r avg\u00f6rande f\u00f6r dess framg\u00e5ng. Framg\u00e5ngen f\u00f6r produkten best\u00e4ms av hastigheten att verifiera aff\u00e4rshypoteser i den.<\/b>. Och h\u00e4r ligger enligt min \u00e5sikt den viktigaste f\u00f6rdelen med mikroservicesarkitektur. Men l\u00e5t oss ta det steg f\u00f6r steg. <\/p>\n

L\u00e5t oss g\u00e5 vidare till n\u00e4sta steg i evolutionen av informationssystem \u2014 till serviceorienterad arkitektur (SOA). S\u00e5, vid en viss punkt har vi identifierat i v\u00e5r produkt l\u00e5nglivade tj\u00e4nster<\/b> \u2014 l\u00e5nglivade i den meningen att n\u00e4r vi g\u00f6r \u00f6verg\u00e5ngar mellan produktversioner finns det en chans att tj\u00e4nstens livscykel kommer att vara l\u00e4ngre \u00e4n livscykeln f\u00f6r den aktuella produktversionen. Det skulle vara logiskt att inte \u00e4ndra dem \u00f6verhuvudtaget \u2014 vi \u00e4r faktiskt intresserade av just hastigheten f\u00f6r \u00f6verg\u00e5ngen till n\u00e4sta version<\/b>. Men tyv\u00e4rr m\u00e5ste vi konstant g\u00f6ra \u00e4ndringar i tj\u00e4nster \u2014 och h\u00e4r g\u00e5r allt bra, inklusive DevOps-praktiker, containerisering och annat \u2014 allt som kommer att t\u00e4nka p\u00e5. Men det \u00e4r fortfarande inte mikrotj\u00e4nster! <\/p>\n

Mikrotj\u00e4nster som ett medel f\u00f6r att hantera komplexitet... konfigurationshantering<\/h2>\n

\n Och h\u00e4r kan vi \u00e4ntligen g\u00e5 \u00f6ver till den avg\u00f6rande rollen som mikrotj\u00e4nster spelar \u2014 det \u00e4r en metod som f\u00f6renklar konfigurationshanteringen av produkten. Mer specifikt beskriver funktionen f\u00f6r varje mikrotj\u00e4nst just aff\u00e4rsfunktionen inom produkten enligt dom\u00e4nmodellen \u2014 och det \u00e4r redan s\u00e5dana aspekter som inte lever i en kortlivad version, utan i en l\u00e5nglivad aff\u00e4rsm\u00f6jlighet. Och \u00f6verg\u00e5ngen till n\u00e4sta produktversion sker bokstavligen obem\u00e4rkt \u2014 du \u00e4ndrar\/l\u00e4gger till en mikrotj\u00e4nst, eller kanske bara deras interaktionsschema, och pl\u00f6tsligt \u00e4r du redan i framtiden, medan dina gr\u00e5tande konkurrenter forts\u00e4tter att hoppa mellan versionerna av sina monoliter. T\u00e4nk nu att det finns en tillr\u00e4ckligt stor m\u00e4ngd mikrotj\u00e4nster med f\u00f6rutbest\u00e4mda gr\u00e4nssnitt och aff\u00e4rsm\u00f6jligheter. Och du kommer och bygger strukturen f\u00f6r din produkt av f\u00e4rdiga mikrotj\u00e4nster \u2014 bara genom att rita ett diagram till exempel. Grattis \u2014 du har skapat en plattform \u2014 och nu kan du b\u00f6rja generera aff\u00e4rer. Dr\u00f6mmar, dr\u00f6mmar. <\/p>\n

Slutsatser<\/h2>\n

<\/p>\n