Monolitiska arkitekturer och mikrotjänstarkitekturer

Slutförd

Fabrikam integrerade sin nya drönartjänst i sitt befintliga program. De inser att den här lösningen inte är en bra långsiktig plan för deras program. Det befintliga systemet är en monolitisk arkitektur, men vad exakt betyder det?

Vad är en monolitisk arkitektur?

En monolitisk arkitektur är en arkitektur där alla komponenter för ett program är samlokaliserade i en enda enhet. Den här enheten är vanligtvis begränsad inom en enda driftinstans av programmet. Traditionella program består ofta av ett webbgränssnitt, ett tjänstlager och ett datalager. I en monolitisk arkitektur kombineras dessa lager på en instans av programmet.

Monolitiska arkitekturer är ofta lämpliga lösningar för små program, men de kan bli svårhanterliga när programmet växer. Det som ursprungligen var ett litet program kan snabbt bli ett komplext system som är svårt att skala, svårt att distribuera till och svårt att förnya.

Alla tjänster finns i en enda enhet. Det här arrangemanget medför utmaningar i takt med att deras verksamhet och efterföljande systembelastning växer. Några av dessa utmaningar är:

• Svårt att skala tjänster oberoende av varandra.
• Komplext att utveckla och hantera distributioner i takt med att kodbasen växer, vilket saktar ned lanseringar och ny funktionsimplementering.
• Arkitekturen är knuten till en enda teknikstack som begränsar innovationen på nya plattformar och SDK:er.
• Uppdateringar av datascheman kan bli allt svårare.

Dessa utmaningar kan lösas genom att titta på alternativa arkitekturer, till exempel en arkitektur för mikrotjänster.

Vad är en arkitektur för mikrotjänster?

En mikrotjänstarkitektur består av tjänster som är små, oberoende och löst kopplade. Varje tjänst kan distribueras och skalas separat.

En mikrotjänst är tillräckligt liten för att ett enda litet team med utvecklare ska kunna skriva och underhålla den. Eftersom tjänster kan distribueras oberoende av varandra kan ett team uppdatera en befintlig tjänst utan att återskapa och distribuera om hela programmet.

Varje tjänst ansvarar vanligtvis för sina egna data. Dess datastruktur är isolerad, så uppgraderingar eller ändringar i schemat är inte beroende av andra tjänster. Begäranden om data hanteras vanligtvis via API:er och ger en väldefinierad och konsekvent åtkomstmodell. Intern implementeringsinformation är dold för tjänstkonsumenter.

Eftersom varje tjänst är oberoende kan de använda olika teknikstackar, ramverk och SDK:er. Det är vanligt att tjänster förlitar sig på REST-anrop för tjänst-till-tjänst-kommunikation med hjälp av väldefinierade API:er i stället för fjärrproceduranrop (RPCs) eller andra anpassade kommunikationsmetoder.

Mikrotjänstarkitekturer är teknikagnostiska, men du ser ofta containrar eller serverlösa tekniker som används för implementeringen. Kontinuerlig distribution och kontinuerlig integrering (CI/CD) används ofta för att öka hastigheten och kvaliteten på utvecklingsaktiviteter.

Fördelar med en arkitektur för mikrotjänster

Varför skulle du välja en arkitektur för mikrotjänster? Det finns flera huvudsakliga fördelar med en arkitektur för mikrotjänster:

• Smidighet
• Små koder, små team
• Blandning av tekniker
• Motståndskraft
• Skalbarhet
• Dataisolering

Smidighet

Eftersom mikrotjänster distribueras oberoende av varandra är det enklare att hantera felkorrigeringar och funktionsutgåvor. Du kan uppdatera en tjänst utan att distribuera om hela programmet och återställa en uppdatering om något går fel. Om en bugg hittas i en del av programmet i många traditionella program kan den blockera hela lanseringsprocessen. Därför kan nya funktioner fördröjas i väntan på att en felkorrigering ska integreras, testas och publiceras.

Liten kod, små team

En mikrotjänst bör vara tillräckligt liten för att ett enda funktionsteam ska kunna skapa, testa och distribuera den. Små kodbaser är lättare att förstå. I ett stort monolitiskt program tenderar kodberoenden att trassla till sig med tiden. Att lägga till en ny funktion kräver att du trycker på kod på många platser. En mikrotjänstarkitektur minimerar beroenden genom att inte dela kod eller datalager. Det gör det enklare att lägga till nya funktioner.

Små teamstorlekar ökar också flexibiliteten. "Tvåpizzaregeln" säger att ett team ska vara tillräckligt litet för att två pizzor ska räcka till för att mätta teamet. Uppenbarligen är det inte ett exakt mått och beror på teamets aptit! Men poängen är att stora grupper tenderar att vara mindre produktiva eftersom kommunikationen är långsammare, hanteringskostnaderna ökar och flexibiliteten minskar.

Blandning av tekniker

Team kan välja den teknik som passar bäst för deras tjänst. De kan använda en blandning av teknikstackar efter behov. Varje team kan utveckla de tekniker som stöder deras tjänst oberoende av varandra. Tjänster kan använda olika utvecklingsspråk, molntjänster, SDK:er med mera på grund av detta oberoende. Teams kan välja de bästa alternativen för sin tjänst, samtidigt som de minimerar eventuella externa effekter på användarna av tjänsten.

Motståndskraft

Om en enskild mikrotjänst blir otillgänglig stör den inte hela programmet, så länge som några överordnade mikrotjänster är utformade för att hantera fel korrekt (till exempel genom att implementera kretsbrytning). Fördelen för dina användare eller tjänstkonsumenter är en ständigt tillgänglig upplevelse för ditt program.

Skalbarhet

Med en mikrotjänstarkitektur kan varje mikrotjänst skalas oberoende av de andra. Du kan skala ut undersystem som kräver mer resurser utan att skala ut hela programmet. Det här arrangemanget förbättrar programmets övergripande prestanda. Det hjälper också till att minimera kostnaderna. Du kan bara lägga till fler resurser till de tjänster som behöver dem, i stället för att skala upp hela programmet.

Dataisolering

En mikrotjänstarkitektur förbättrar möjligheten att utföra uppdateringar av dataschemat eftersom endast en enskild mikrotjänst påverkas. I ett monolitiskt program kan schemauppdateringar bli utmanande. Olika delar av programmet kan röra samma data, vilket gör eventuella ändringar i schemat riskfyllda. Med en arkitektur för mikrotjänster kan du uppdatera ett schema men hålla API-ytan intakt. Tjänstkonsumenter har sedan samma upplevelse oavsett den underliggande dataarkitekturen.

Potentiella utmaningar med en mikrotjänstarkitektur

Det finns många fördelar med en arkitektur för mikrotjänster, men det är inte en universallösning. En arkitektur för mikrotjänster har en egen uppsättning utmaningar:

• Komplexitet
• Utveckling och testning
• Brist på styrning
• Nätverksbelastning och svarstid
• Dataintegritet
• Ledning
• Versionshantering
• Kompetensuppsättning

Komplexitet

Ett mikrotjänstprogram har fler rörliga delar än motsvarande monolitiska program. Varje tjänst är enklare, men hela systemet som helhet är mer komplext. Med verktyg för tjänstidentifiering, orkestrering och automatisering kan det finnas fler delar att hantera i det övergripande programmet.

Utveckling och testning

Att skriva en liten tjänst som förlitar sig på andra beroende tjänster kräver en annan metod än att skriva för ett traditionellt monolitiskt eller skiktat program. Befintliga verktyg är inte alltid utformade för att fungera med tjänstberoenden. Det kan vara svårt att omstrukturera över tjänstgränser. Det är också svårt att testa tjänstberoenden, särskilt när programmet utvecklas snabbt.

Brist på styrning

Den decentraliserade metoden för att skapa mikrotjänster har fördelar, men det kan också leda till problem. Du kan få så många olika språk och ramverk att programmet blir svårt att underhålla. Det kan vara bra att införa vissa projektomfattande standarder, utan att alltför begränsa teamens flexibilitet. Behovet av enhetliga standarder gäller särskilt för övergripande funktioner, till exempel loggning och mått.

Nätverksbelastning och svarstid

Användningen av många små, detaljerade tjänster kan leda till mer kommunikation mellan tjänster. Om kedjan av tjänstberoenden blir för lång, till exempel tjänst A anropar B, som anropar C..., kan den extra svarstiden för dessa nätverksanrop bli ett problem. Utforma DINA API:er noggrant. Undvik alltför pratsamma API:er, tänk på serialiseringsformat och leta efter platser där du kan använda asynkrona kommunikationsmönster.

Dataintegritet

Varje mikrotjänst ansvarar för sin egen datapersistence. Därför kan datakonsekvens vara en utmaning. Använd eventuell konsistens där det är möjligt. Du kan också få duplicerade data och en spretig dataarkitektur. Den här situationen kan öka kostnaderna för rådatalagring och dataplattformstjänsten med tjänst- och dataduplicering.

Ledning

Framgång med mikrotjänster kräver en mogen DevOps-kultur. Korrelerad loggning mellan tjänster kan vara utmanande. Loggning måste vanligtvis korrelera flera tjänstanrop för en enskild användaråtgärd.

Versionshantering

Uppdateringar av en tjänst får inte bryta tjänster som är beroende av den. Flera tjänster kan uppdateras vid en viss tidpunkt. Utan noggrann design kan du ha problem med bakåt- eller framåtkompatibilitet. Tjänster som fördröjer införandet av nya API-versioner kan öka de resurser och underhåll som krävs för äldre API:er.

Kompetensuppsättning

Mikrotjänster är mycket distribuerade system. Dessa distribuerade system kräver ofta en annan kompetensuppsättning för att utveckla, hantera och underhålla korrekt. Utvärdera noggrant om teamet har de kunskaper och den erfarenhet som behövs för att lyckas. Tillåt den tid och planering som dina team behöver för att utveckla sina förmågor.

När ska du välja en arkitektur för mikrotjänster?

Vilka situationer passar bäst för en mikrotjänstarkitektur baserat på den här bakgrundsinformationen?

• Stora program som kräver hög lanseringshastighet.
• Komplexa program som måste vara mycket skalbara.
• Program med omfattande domäner eller många underdomäner.
• En organisation som består av små utvecklingsteam.