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.
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.
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 och Designa 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.