Format för Mikrotjänster-arkitekturen

  • Artikel
  • 5 minuter för att läsa

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 avgrä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 för format för arkitektur 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.

  • Har stöd för polyglobt-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.

  • In-of-the-box-principer, till exempel för begränsning, cachelagring, transformering eller validering.

Fördelar

  • Agility. Eftersom mikrotjänster distribueras oberoende är det enklare att hantera felkorrigeringar och nya 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 därför skjutas upp medan en felkorrigering 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 trasslar till sig med tiden. Om du vill lägga till en ny funktion måste du röra 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 så länge överordnade mikrotjänster är utformade för att hantera fel på rätt sätt (till exempel via implementering av kretsnedbrytning).

  • 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 initierare som Kubernetes eller Service Fabric kan du också placera tjänster med högre densitet i en enda värd, vilket effektiviserar utnyttjandet av resurser.

  • Dataisolering. Det är mycket enklare att utföra schemauppdateringar eftersom endast en mikrotjänst påverkas. I ett monolitiskt program kan schemauppdateringar utgöra en stor utmaning. Det beror på att olika delar av programmet kan beröra samma data, vilket gör det riskfyllt att ändra något i schemat.

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 använder andra beroende tjänster kräver en annan metod än att skriva ett traditionellt monolitiskt eller flernivåsprogram. Befintliga verktyg är inte alltid utformade för att fungera med tjänstberoenden. Omstrukturering över tjänstgränserna kan vara svårt. Det är också svårt för 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 kan få 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 alltför begränsa teamets 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 trafikiga API:er, tänk på serialiseringsformat och leta efter platser där du kan använda asynkrona kommunikationsmönster som köbaserad belastningsutjämning.

  • Dataintegritet. Med varje mikrotjänst som ansvarar för den egna datapersistensen. 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.

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

Bästa praxis

  • Modellera tjänster runt företagsdomänen.

  • Decentralisera allt. Enskilda team ansvarar för att designa och skapa tjänster. Undvik att dela kod eller datascheman.

  • Datalagringen ska vara privat för den tjänst som äger data. Använd det bästa lagringsalternativet för varje tjänst och datatyp.

  • Tjänster kommunicerar via väl utformad API:er. Undvik att implementeringsdetaljer läcker. API:er bör modellera domänen, inte den interna implementeringen av tjänsten.

  • Undvik koppling mellan tjänster. Orsakerna till kopplingen vara delade databasscheman och fasta kommunikationsprotokoll.

  • Övergripande frågor, till exempel autentisering och SSL-avslutning till gatewayen.

  • Håll domänkunskap utanför gatewayen. Gatewayen ska hantera och vidarebefordra klientbegäranden utan kännedom om affärsregler eller domänlogik. Annars blir gatewayen ett beroende och kan orsaka koppling mellan tjänster.

  • Tjänster bör ha lösa kopplingar och hög funktionell sammanhållning. Funktioner som sannolikt kommer att ändra tillsammans måste paketeras och distribueras tillsammans. Om de finns i separata tjänster hamnar tjänsterna nära tillsammans, eftersom en ändring i en tjänst kräver att den andra tjänsten uppdateras. Alltför trafikintensiv kommunikation mellan två tjänster kan vara ett symtom på nära koppling och låg sammanhållning.

  • Isolera fel. Använd återhämtningsstrategier för att förhindra fel inom en tjänst från att sprida sig. Se Återhämtningsmönster ochUtforma tillförlitliga program.

Nästa steg

Detaljerad information om hur du skapar en arkitektur för mikrotjänster i Azure finns i Utforma, skapa och driva mikrotjänster på Azure.