Arkitekturdesign för mikrotjänster

Azure DevOps

Mikrotjänster har blivit en populär arkitekturstil för att skapa molnprogram som är elastiska, mycket skalbara, kan distribueras oberoende av varandra och som kan utvecklas snabbt. Men för en lyckad mikrotjänstarkitektur krävs en annan metod för att utforma och skapa program.

En arkitektur för mikrotjänster består av en samling små, autonoma tjänster. Varje tjänst är fristående och bör implementera en enda affärsfunktion i en begränsad kontext. En avgränsad kontext är en naturlig division inom ett företag och ger en explicit gräns inom vilken en domänmodell finns.

Logiskt diagram över arkitekturformatet för mikrotjänster.

Vad är mikrotjänster?

  • Mikrotjänster är små, oberoende och löst kopplade. En liten grupp utvecklare ska kunna skriva och underhålla en sådan tjänst.

  • Varje tjänst utgör en separat kodbas som kan hanteras av ett litet utvecklingsteam.

  • Tjänster kan distribueras oberoende av varandra. Ett team kan uppdatera en befintlig tjänst utan att bygga om och omdistribuera hela programmet.

  • Tjänsterna svarar för att spara sina egna data eller externa tillstånd. Detta skiljer sig från den traditionella modellen, där ett separat datalager hanterar datapersistensen.

  • Tjänster kommunicerar med varandra med hjälp av väldefinierade API:er. Interna implementeringsdetaljer för varje tjänst är dolda från andra tjänster.

  • Stöder flerspråkig programmering. Tjänster behöver till exempel inte dela samma teknikstack, bibliotek eller ramverk.

Förutom tjänsterna själva visas vissa andra komponenter i en typisk mikrotjänstarkitektur:

Hantering/orkestrering. Den här komponenten ansvarar för att placera tjänster på noder, identifiera fel, ombalansera tjänster över flera noder och så vidare. Den här komponenten består vanligtvis av en startklar teknik, till exempel Kubernetes, i stället för något som är anpassat.

API-gateway. API-gatewayen är startpunkten för klienterna. I stället för att anropa tjänsten direkt anropar klienten API-gatewayen, som vidarebefordrar anropet till rätt tjänster på serverdelen.

Fördelarna med att använda en API-gateway är bland annat följande:

  • Den frikopplar klienter från tjänster. Tjänsterna kan versionshanteras eller omstruktureras utan att alla klienter behöver uppdateras.

  • Tjänsterna kan använda meddelandeprotokoll som inte är webbvänliga, till exempel AMQP.

  • API-gatewayen kan utföra andra övergripande funktioner, till exempel autentisering, loggning, SSL-avslutning och belastningsutjämning.

  • Färdiga principer, till exempel för begränsning, cachelagring, transformering eller validering.

Förmåner

  • Flexibilitet. Eftersom mikrotjänster distribueras oberoende är det enklare att hantera felkorrigeringar och kommande versioner. Du kan uppdatera en tjänst utan att omdistribuera hela programmet, och återställa en uppdatering om något blir fel. I många traditionella program kan hela versionsprocessen blockeras om ett fel påträffas i en del av programmet. Nya funktioner kan fördröjas i väntan på att en felkorrigering ska integreras, testas och publiceras.

  • Små, fokuserade team. En mikrotjänst bör vara så liten att ett enda funktionsteam ska kunna skapa, testa och distribuera den. Små teamstorlekar främjar mer flexibilitet. Stora grupper tenderar att vara mindre produktiva eftersom kommunikationen är långsammare, hanteringskostnaderna ökar och flexibiliteten minskar.

  • Liten kodbas. I ett monolitiskt program finns det en tendens att kodberoenden blir sammanflätade över tid. Att lägga till en ny funktion kräver att du trycker på kod på många platser. Eftersom en arkitektur för mikrotjänster inte delar kod eller datalager minimeras beroenden, vilket gör det enklare att lägga till nya funktioner.

  • Blandning av tekniker. Team kan välja den teknik som bäst passar deras tjänst med en blandning av teknikstackar efter behov.

  • Felisolering. Om en enskild mikrotjänst blir otillgänglig stör den inte hela programmet, förutsatt att alla överordnade mikrotjänster är utformade för att hantera fel korrekt. Du kan till exempel implementera kretsbrytarmönstret, eller så kan du utforma din lösning så att mikrotjänsterna kommunicerar med varandra med hjälp av asynkrona meddelandemönster.

  • Skalbarhet. Tjänsterna kan skalas oberoende av varandra, vilket gör att du kan skala ut delsystem som kräver mer resurser utan att skala ut hela programmet. Med hjälp av en orkestrerare som Kubernetes kan du packa en högre densitet av tjänster på en enda värd, vilket möjliggör effektivare användning av resurser.

  • Dataisolering. Det är mycket enklare att utföra schemauppdateringar eftersom endast en mikrotjänst påverkas. I ett monolitiskt program kan schemauppdateringar bli mycket utmanande eftersom olika delar av programmet kan röra samma data, vilket gör eventuella ändringar i schemat riskfyllda.

Utmaningar

Fördelarna med mikrotjänster är dock inte gratis. Här är några av utmaningar du bör tänka på när du väljer en arkitektur för dina mikrotjänster.

  • Komplexitet. Ett mikrotjänstprogram har fler rörliga delar än motsvarande monolitiska program. Varje enskild tjänst är enklare, men systemet som helhet är mer komplext.

  • 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 ett traditionellt monolitiskt eller skiktat program. Befintliga verktyg är inte alltid utformade att fungera med tjänstberoenden. Omstrukturering över tjänstgränserna kan vara svårt. Det är även svårt att testa tjänstens beroenden, i synnerhet när programmet utvecklas snabbt.

  • Brist på styrning. Den decentraliserade lösningen att skapa mikrotjänster har sina fördelar, men den kan även leda till problem. Du kanske använder så många olika språk och ramverk att programmet blir svårt att underhålla. Det kan vara praktiskt att införa vissa projektövergripande standarder utan att begränsa teamens flexibilitet alltför mycket. Detta gäller särskilt för övergripande funktioner, till exempel loggning.

  • Nätverksbelastning och svarstid. När du använder många små, detaljerade tjänster kan kommunikationen mellan tjänsterna öka. Även om kedjan av tjänsteberoenden blir för lång (tjänst A anropar B, som anropar C osv.), kan den förlängda svarstiden bli ett problem. Du behöver designa API:erna noggrant. Undvik alltför pratsamma API:er, tänk på serialiseringsformat och leta efter platser där du kan använda asynkrona kommunikationsmönster som köbaserad belastningsnivå.

  • Dataintegritet. Varje mikrotjänst ansvarar för sin egen datapersistens. Det här gör det svårt att hålla datakonsekvensen. Utnyttja slutlig konsekvens där det är möjligt.

  • Hantering. För att lyckas med mikrotjänster krävs en mogen DevOps-kultur. Det kan vara svårt med korrelerad loggning för flera tjänster. Normalt måste loggningen samordna flera tjänstanrop för en enskild användaråtgärd.

  • Versionshantering. Uppdateringar av en tjänst får inte störa andra tjänster som är beroende av den. Flera tjänster kan uppdateras när som helst, så utan noggrann design kan du få problem med bakåt- eller framåtkompatibilitet.

  • Kunskaper. Mikrotjänster är starkt distribuerade system. Utvärdera noga om teamet har de kunskaper och den erfarenhet som krävs för att lyckas.

Process för att utforma en arkitektur för mikrotjänster

Artiklarna i den här listan visar en strukturerad metod för att utforma, skapa och driva en arkitektur för mikrotjänster.

Domänanalys. För att undvika en del vanliga fallgropar när du skapar mikrotjänster kan du använda domänanalys för att definiera mikrotjänsternas gränser. Följ de här stegen:

  1. Använda domänanalys för att utforma mikrotjänstmodeller.
  2. Använda taktisk DDD för att utforma mikrotjänster.
  3. Identifiera gränser för mikrotjänster.

Utforma tjänsterna. Mikrotjänster kräver en annan metod än när du utformar och skapar program. Mer information hittar du i Utforma en arkitektur för mikrotjänster.

Bearbeta i produktionen. Eftersom arkitekturer för mikrotjänster distribueras måste du ha robusta åtgärder för distribution och övervakning.

Referensarkitekturer för mikrotjänster för Azure