Jag har länge velat skriva en artikel om mikrotjänstarkitektur, men jag har stannat upp av två skäl – ju mer jag gräver i ämnet, desto mer verkar det som om det jag redan vet är uppenbart, och det jag inte vet behöver jag fortfarande studera. Å andra sidan anser jag att det finns mycket att diskutera för en bredare publik. Så alternativa åsikter välkomnas.
Conways lag och kopplingen mellan företag, organisation och informationssystem
Jag tillåter mig ännu en gång att citera:
“Varje organisation som designar ett system (i vid bemärkelse) kommer att få ett design vars struktur speglar strukturen av de team som finns i organisationen”
— Melvyn Conway, 1967
Jag anser att denna lag i större utsträckning relaterar till effektiviteten hos företagsorganisationen snarare än direkt till informationssystemet. Låt mig förklara med ett exempel. Anta att vi har en tillräckligt stabil affärsmöjlighet med en livscykel som är så långvarig att det är meningsfullt att organisera en verksamhet (detta är ingen skrivfel, men jag gillar verkligen det här termen som jag har snott). Naturligtvis kommer det stödjande systemet för detta företag att organisatoriskt och processmässigt stämma överens med detta företag.
Affärsorientering av informationssystem
Låt mig förklara med ett exempel. Anta att det finns en affärsmöjlighet att organisera en verksamhet för att sälja pizza. I version V1 (låt oss kalla den den icke-informationsbaserade) var företaget en pizzeria, en kassa och en leveranstjänst. Denna version var långlivad under förhållanden med låg förändlighet i omvärlden. Sedan kom version 2 — mer avancerad och kapabel att använda ett informationssystem som grund för verksamheten med en monolitisk arkitektur. Och här, enligt mig, uppstår verkligen en förfärlig orättvisa gentemot monoliter — den påstått monolitisk arkitektur motsvarar inte domänmodellen för affärsverksamheten. Om så var fallet, skulle systemet inte kunna fungera alls - vilket strider mot samma Conway's lag och sunt förnuft. Nej, en monolitisk arkitektur motsvarar helt affärsmodellen i detta utvecklingsstadium av verksamheten - jag menar naturligtvis det stadium när systemet redan har skapats och implementerats. Det är en helt fantastisk fakta att oavsett arkitektonisk metod kommer både den tjänsteorienterade arkitekturen version 3 och den mikroservicesarkitekturen version N att fungera lika bra. Vad är fällan?
Allt flyter, allt förändras eller är mikroservicer ett medel för att bekämpa komplexitet?
Innan vi fortsätter, låt oss titta på några missuppfattningar kring mikroservicesarkitektur.
Förespråkare för mikroservicesmetoden säger ofta att nedbrytning av monoliten till mikroservicer förenklar utvecklingsprocessen genom att minska kodbasen för varje tjänst. Enligt min åsikt är detta påstående ren nonsens. Seriöst, verkar det uppenbara samarbetet inom en monolit och homogen kod svårt? Om det verkligen var så, skulle alla projekt initialt byggas som mikroservicer, medan praktiken visar att migration från en monolit till mikroservicer är mycket mer vanlig. Komplexiteten försvinner inte, den övergår bara från individuella moduler till gränssnitt (vare sig det är databusser, RPC, API och andra protokoll) och orkestrerande system. Och det är komplext!
Fördelarna med att använda en heterogen stack är också tveksamma. Jag kommer inte att hävda att det också är möjligt, men i verkligheten förekommer det sällan (För att gå före — detta bör faktiskt förekomma — men snarare som en konsekvens än en fördel).
Produktens livscykel och tjänstens livscykel
Titta en gång till på diagrammet ovan. Jag påpekade inte av en slump den minskande livscykeln för varje version av verksamheten — i moderna förhållanden är det just påskyndandet av övergången mellan versioner som är avgörande för dess framgång. Framgången för produkten bestäms av hastigheten att verifiera affärshypoteser i den.. Och här ligger enligt min åsikt den viktigaste fördelen med mikroservicesarkitektur. Men låt oss ta det steg för steg.
Låt oss gå vidare till nästa steg i evolutionen av informationssystem — till serviceorienterad arkitektur (SOA). Så, vid en viss punkt har vi identifierat i vår produkt långlivade tjänster — långlivade i den meningen att när vi gör övergångar mellan produktversioner finns det en chans att tjänstens livscykel kommer att vara längre än livscykeln för den aktuella produktversionen. Det skulle vara logiskt att inte ändra dem överhuvudtaget — vi är faktiskt intresserade av just hastigheten för övergången till nästa version. Men tyvärr måste vi konstant göra ändringar i tjänster — och här går allt bra, inklusive DevOps-praktiker, containerisering och annat — allt som kommer att tänka på. Men det är fortfarande inte mikrotjänster!
Mikrotjänster som ett medel för att hantera komplexitet... konfigurationshantering
Och här kan vi äntligen gå över till den avgörande rollen som mikrotjänster spelar — det är en metod som förenklar konfigurationshanteringen av produkten. Mer specifikt beskriver funktionen för varje mikrotjänst just affärsfunktionen inom produkten enligt domänmodellen — och det är redan sådana aspekter som inte lever i en kortlivad version, utan i en långlivad affärsmöjlighet. Och övergången till nästa produktversion sker bokstavligen obemärkt — du ändrar/lägger till en mikrotjänst, eller kanske bara deras interaktionsschema, och plötsligt är du redan i framtiden, medan dina gråtande konkurrenter fortsätter att hoppa mellan versionerna av sina monoliter. Tänk nu att det finns en tillräckligt stor mängd mikrotjänster med förutbestämda gränssnitt och affärsmöjligheter. Och du kommer och bygger strukturen för din produkt av färdiga mikrotjänster — bara genom att rita ett diagram till exempel. Grattis — du har skapat en plattform — och nu kan du börja generera affärer. Drömmar, drömmar.
Slutsatser
- Systemarkitekturen bör bestämmas av livscykeln för de komponenter som ingår. Om en komponent lever inom ramen för en produktversion — finns det ingen mening med att öka systemets komplexitet genom att använda ett mikrotjänstansats.
- Mikrotjänstarkitektur bör grunda sig på domänmodellen — av den anledningen att affärsmöjligheten är den mest långlivade området
- Leveransmetoder (DevOps-praktik) och orkestrering har en av de viktigaste betydelserna för mikrotjänstarkitektur, eftersom en ökning av hastigheten för komponentförändringar ställer högre krav på hastighet och kvalitet i leveransen.
Källa: habr.com
