Jag ville länge skriva en artikel om ämnet mikrotjänstarkitektur, men två saker stoppade mig hela tiden - ju längre jag kastade mig in i ämnet, desto mer verkade det för mig att det jag vet är uppenbart, och vad jag gör. t vet behöver studeras och studeras. Däremot tror jag att det redan finns något att diskutera bland en bred publik. Så alternativa åsikter är välkomna.
Conways lag och förhållandet mellan verksamhet, organisation och informationssystem
Än en gång tillåter jag mig själv att citera:
"Varje organisation som designar ett system (i vid mening) kommer att få en design vars struktur replikerar strukturen hos teamen i den organisationen."
— Melvyn Conway, 1967
Enligt min åsikt är denna lag mer sannolikt att relatera till genomförbarheten av att organisera ett företag, snarare än direkt till informationssystemet. Låt mig förklara med ett exempel. Låt oss säga att vi har en ganska stabil affärsmöjlighet med en livscykel av sådan längd att det är vettigt att organisera ett företag (detta är inte ett stavfel, men jag gillar verkligen den här termen som jag stal). Naturligtvis stödsystemet för denna verksamhet kommer organisatoriskt och processuellt att motsvara denna verksamhet .
Affärsorientering av informationssystem
Låt mig förklara med ett exempel. Låt oss säga att det finns en affärsmöjlighet att organisera ett företag som säljer pizza. I V1-versionen (låt oss kalla det förinformation) var företaget en pizzeria, ett kassaregister och en leveranstjänst. Denna version var långlivad under förhållanden med låg miljövariabilitet. Sedan kom version 2 att ersätta den - mer avancerad och kunna använda ett informationssystem i sin kärna för företag med en monolitisk arkitektur. Och här, enligt min mening, finns det helt enkelt en fruktansvärd orättvisa i förhållande till monoliterna - påstådd monolitisk arkitektur motsvarar inte domänens affärsmodell. Ja, om det vore så skulle systemet inte alls kunna fungera – i strid med samma Conways lag och sunt förnuft. Nej, monolitisk arkitektur överensstämmer helt med affärsmodellen i detta skede av affärsutvecklingen – jag menar förstås det skede då systemet redan har skapats och tagits i drift. Det är ett helt underbart faktum att oavsett arkitekturupplägg så kommer både den tjänsteorienterade arkitekturen version 3 och mikroservicearkitekturen version N att fungera lika bra. Vad är haken?
Allt flyter, allt förändras, eller är mikrotjänster ett sätt att bekämpa komplexitet?
Innan vi fortsätter, låt oss titta på några missuppfattningar om mikrotjänstarkitektur.
Förespråkare för att använda en mikrotjänstmetod hävdar ofta att att bryta en monolit i mikrotjänster förenklar utvecklingsstrategin genom att minska kodbasen för enskilda tjänster. Enligt min mening är detta uttalande fullständigt nonsens. Seriöst, den uppenbara interaktionen inom en monolit och homogen kod verkar komplicerad? Om så verkligen vore fallet skulle alla projekt till en början byggas som mikrotjänster, medan praxis visar att migrering från en monolit till mikrotjänster är mycket vanligare. Komplexiteten försvinner inte, den går helt enkelt från enskilda moduler till gränssnitt (vare sig det är databussar, RPC, API:er och andra protokoll) och orkestreringssystem. Och det här är svårt!
Fördelen med att använda en heterogen stack är också tveksam. Jag kommer inte att argumentera för att detta också är möjligt, men i verkligheten förekommer det sällan (framöver - detta borde hända - utan snarare som en konsekvens än en fördel).
Produktens livscykel och servicelivscykel
Ta en ny titt på diagrammet ovan. Det är ingen slump att jag noterade den minskande livscykeln för en separat version av ett företag - under moderna förhållanden är det accelerationen av en verksamhets övergång mellan versioner som är avgörande för dess framgång. Framgången för en produkt bestäms av hastigheten för att testa affärshypoteser i den. Och här, enligt min mening, ligger den viktigaste fördelen med mikrotjänstarkitektur. Men låt oss gå i ordning.
Låt oss gå vidare till nästa steg i utvecklingen av informationssystem - till SOAs tjänsteorienterade arkitektur. Så, vid en viss punkt har vi lyft fram i vår produkt långlivade tjänster - långlivad i den meningen att när man flyttar mellan versioner av en produkt finns det en chans att tjänstens livscykel blir längre än livscykeln för nästa version av produkten. Det vore logiskt att inte ändra dem alls - vi Det som spelar roll är hastigheten för övergången till nästa version. Men tyvärr, vi tvingas göra ständiga förändringar av tjänster - och här fungerar allt för oss, DevOps-övningar, containerisering och så vidare - allt som kommer att tänka på. Men dessa är fortfarande inte mikrotjänster!
Mikrotjänster som ett sätt att bekämpa komplexitet... konfigurationshantering
Och här kan vi äntligen gå vidare till mikrotjänsternas avgörande roll - detta är ett tillvägagångssätt som förenklar produktkonfigurationshanteringen. Mer detaljerat beskriver varje mikrotjänsts funktion exakt affärsfunktionen inuti produkten enligt domänmodellen – och det är saker som inte lever i en kortlivad version, utan i en långlivad affärsmöjlighet. Och övergången till nästa version av produkten sker bokstavligen obemärkt - du ändrar/lägger till en mikrotjänst, och kanske bara schemat för deras interaktion, och plötsligt befinner du dig i framtiden och lämnar efter sig gråtande konkurrenter som fortsätter att hoppa mellan versioner av deras monoliter. Föreställ dig nu att det finns en ganska stor volym mikrotjänster med fördefinierade gränssnitt och affärsmöjligheter. Och du kommer och bygger strukturen på din produkt av färdiga mikrotjänster – helt enkelt genom att rita ett diagram till exempel. Grattis - du har en plattform - och nu kan du locka till dig affärer. Drömmar Drömmar.
Resultat
- Systemets arkitektur bör bestämmas av dess komponenters livscykel. Om en komponent finns i en produktversion, är det ingen idé att öka systemets komplexitet genom att använda en mikrotjänstmetod.
- Mikrotjänstarkitektur bör baseras på domänmodellen - eftersom affärsmöjligheten är den längsta livslängda domänen
- Leveranspraxis (DevOps praxis) och orkestrering är en av de viktigaste för mikrotjänstarkitektur - av anledningen att ökningen av byteshastigheten av komponenter ställer ökade krav på leveranshastighet och kvalitet.
Källa: will.com