Välj ett Azure-beräkningsalternativ för mikrotjänster

Den här artikeln hjälper dig att välja en Azure-beräkningsplattform för en arbetsbelastning som bygger på en arkitektur för mikrotjänster. En mikrotjänstarkitektur består av små, oberoende distribuerade tjänster som kommunicerar via nätverket. Din beräkningsplattform måste ha stöd för oberoende skalning, oberoende distribution och tillförlitlig kommunikation mellan tjänster i många tjänster.

Beslutsfaktorer som gäller för alla arbetsbelastningar, till exempel teamkunskaper, nätverk och portabilitet, finns i Välja en Azure-beräkningstjänst. Den här artikeln fokuserar på de faktorer som är specifika för mikrotjänster.

Azure-beräkningsplattformar för mikrotjänster

Följande Azure-plattformar stöder arbetsbelastningar för mikrotjänster. De skiljer sig åt i hur mycket orkestrering, kommunikation mellan tjänster och skalningsbeteende som de tillhandahåller.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) är en hanterad Kubernetes-tjänst som ger direkt åtkomst till Kubernetes-API:er och kontrollplanet. AKS tillhandahåller nodhantering, korrigering och valfria automatiska uppgraderingar. Du konfigurerar principerna för kluster, nätverk och skalning.

För mikrotjänster har AKS stöd för tjänstnät som Istio för trafikhantering och ömsesidig transportnivåsäkerhet (mTLS), skalning per distribution via HPA (Horizontal Pod Autoscaler) och Kubernetes Event-driven autoskalning (KEDA) och Kubernetes-interna distributionsstrategier som löpande uppdateringar och kanarieversioner.

AKS Automatic är ett läge för AKS som förkonfigurerar nodhantering, skalning, säkerhet och observerbarhet baserat på AKS väldefinierade rekommendationer, så att teamen får ett produktionsklart kluster utan konfiguration per kapacitet.

Azure Container-applikationer

Azure Container Apps är en hanterad tjänst som bygger på Kubernetes som abstraherar klusterhantering.

Container Apps innehåller inbyggda funktioner för mikrotjänster, inklusive tjänstidentifiering, Dapr-integrering för tjänst-till-tjänst-anrop med mTLS, meddelanden för utgivare och prenumeranter och tillståndshantering. KEDA-baserad autoskalning möjliggör händelsedriven skalning, inklusive skalning till noll. Container Apps har också stöd för trafikdelning mellan revisioner för kanariedistributioner och jobb för aktiviteter på begäran, schemalagda aktiviteter eller händelsedrivna uppgifter.

Container Apps exponerar inte Kubernetes-API:er. Om konfigurationen av distributionsverktygen eller service mesh är beroende av Kubernetes-primitiver använder du AKS i stället.

Azure Functions

Azure Functions är en serverlös, händelsedriven beräkningstjänst som lämpar sig för mikrotjänster som svarar på utlösare som HTTP-begäranden, kömeddelanden eller timers. Functions skalar varje funktionsapp individuellt och kan skalas ned till noll. För mikrotjänster distribuerar du varje tjänst som en egen funktionsapp.

Functions tillhandahåller inte tjänstidentifiering på plattformsnivå eller kommunikation mellan tjänster. Implementera dessa funktioner i programkod eller via externa tjänster som Azure API Management.

Functions stöder flera programmeringsspråk. Du kan också köra programmeringsmodellen Functions i Container Apps, som kombinerar Functions-utlösare och bindningar med nätverks- och skalningsfunktioner för Container Apps.

Azure App-tjänst

Azure App Service passar HTTP-baserade mikrotjänster som webb-API:er. App Service stöder distribution som kod eller som en enda container. Den tillhandahåller inbyggd automatisk skalning, distributionsfack för blågröna distributioner och procentbaserad trafikroutning samt integrering med CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). App Service tillhandahåller inte tjänstidentifiering, så det passar mikrotjänster som kommunicerar via externa meddelanden eller en API-gateway i stället för att förlita sig på kommunikation mellan plattformar.

Azure Red Hat OpenShift

Azure Red Hat OpenShift tillhandahåller fullständigt hanterade OpenShift-kluster och utökar Kubernetes med en åsiktsbaserad utvecklarupplevelse. Red Hat och Microsoft utvecklar, driver och stöder tjänsten gemensamt. Använd Azure Red Hat OpenShift när din organisation standardiserar på OpenShift.

Jämföra plattformar för mikrotjänster

I följande tabell jämförs hur varje plattform stöder de funktioner som är viktiga för en mikrotjänstarkitektur. En mer detaljerad jämförelse av Azure-containervärdplattformar och deras funktioner finns i Välj en Azure-containertjänst.

Appnivå i den här tabellen innebär att plattformen inte tillhandahåller funktionen som en inbyggd funktion. Du implementerar den i programkod via en SDK eller en extern tjänst, vilket introducerar ett beroende av den tjänsten.

Välj din plattform

• Börja med Container Apps när du vill ha inbyggda mikrotjänster, till exempel tjänstidentifiering, Dapr och skalning per app som inkluderar skalning till noll, utan klusterhantering.

• Välj AKS när du behöver direkt Åtkomst till Kubernetes API, konfiguration av anpassade tjänstnät eller detaljerad kontroll över klusterinfrastruktur som nodpooler, nätverksprinciper eller schemaläggningsbegränsningar.

• Använd Functions för händelsedrivna mikrotjänster som har sporadiska eller plötsliga trafikmönster som drar nytta av fakturering med skalning till noll och triggerbaserad exekvering.

• Använd App Service för enkla HTTP-baserade tjänster som inte behöver tjänstidentifiering på plattformsnivå eller kommunikationsfunktioner mellan tjänster.

Din arbetsbelastning för mikrotjänster behöver inte köras på en enda plattform. Du kan till exempel köra kärntjänster på AKS eller Container Apps medan Functions hanterar händelsedrivna arbetsbelastningar. Utvärdera varje tjänst i din sammansättning mot sitt eget trafikmönster, skalningskrav och kommunikationsbehov. Välj den plattform som passar den tjänsten i stället för att tvinga tjänsten att passa plattformen.

Viktiga beslutsfaktorer

Jämförelsetabellen visar vad varje plattform stöder. Följande avsnitt hjälper dig att väga dessa funktioner baserat på vilka mikrotjänster som är viktigast för din arbetsbelastning.

Kommunikation mellan tjänster

Mikrotjänster är beroende av tillförlitlig tjänst-till-tjänst-kommunikation med funktioner som tjänstidentifiering, återförsök och mTLS.

Om din arkitektur beror på synkrona tjänst-till-tjänst-anrop över många tjänster prioriterar du en plattform som har inbyggda kommunikationsprimitiver. Container Apps tillhandahåller dessa primitiver via Dapr utan extra infrastruktur. AKS tillhandahåller dem via tjänstnät som Istio, som ger dig kontroll över trafikprinciper, återförsök och kretsbrytning på nätnivå. Du hanterar mesh-livscykeln, konfigurationen och uppgraderingarna.

Om dina tjänster främst kommunicerar via asynkrona meddelanden som köer eller händelseströmmar spelar plattformens inbyggda kommunikationsfunktioner mindre roll eftersom du behöver interagera med dessa tjänster via en SDK eller en abstraktion. Använd det asynkrona Request-Reply-mönstret för långvariga operationer eftersom tidsgränser på plattformen kan orsaka problem. Till exempel framtvingar Functions och App Service en tidsgräns på 230 sekunder för HTTP-svar på grund av Azure Load Balancer-gränser.

Oberoende skalning

Varje mikrotjänst i en sammansättning har olika belastningsegenskaper.

Om dina tjänster har mycket varierande eller plötsliga trafiktoppar skalar Container Apps och Functions per tjänst och kan skala inaktiva tjänster till noll. Den här metoden undviker oanvända kapacitetsavgifter. För Functions är varje funktionsapp skalningsenhet, så distribuera varje mikrotjänst som en egen funktionsapp. AKS tillhandahåller skalning per utplacering. Du hanterar delade nodpooler som förblir provisionerade, och användarnodpooler kan minska till noll.

Plattformar som kan skalas till noll innebär fördröjning vid kallstart när en inaktiv tjänst tar emot sin första begäran. I en arkitektur för mikrotjänster kan en enskild användarbegäran passera flera tjänster. Om flera tjänster i samtalskedjan är kalla, förvärras svarstiden. För synkrona intertjänstanrop som kräver låg svarstid använder du plattformens funktioner för åtgärder mot kallstart eller betalar kostnaden för att hålla minsta antal instanser aktiva för att undvika kallstarter.

Om dina tjänster har stadig, förutsägbar belastning kan AKS eller App Service minska kostnaderna eftersom du betalar för reserverad kapacitet i stället för förbrukningsbaserad fakturering.

Oberoende distribuerbarhet

Du måste distribuera, uppdatera och återställa enskilda mikrotjänster utan att påverka resten av systemet. Alla fyra plattformarna har stöd för oberoende distribution, men de skiljer sig åt i hur du validerar ändringar. Container Apps och AKS tillhandahåller inbyggd trafikdelning för gradvisa lanseringar. App Service stöder procentbaserad trafikroutning mellan distributionsplatser. Functions har stöd för distributionsplatser i Premium- och dedikerade planer.

Distribuerad observerbarhet

En enskild användarbegäran kan passera många tjänster. Om du behöver korrelerade spårningar i hela samtalskedjan kontrollerar du att plattformens observerbarhetsverktyg integreras med din spårningsstrategi. Container Apps ger inbyggd observerbarhet med Dapr-spårning. AKS integreras med OpenTelemetry- och spårningsverktyg med öppen källkod, vilket gör att du kan välja din spårningsserverdel (till exempel Jaeger, Zipkin eller Azure Monitor) men kräver att du distribuerar och konfigurerar insamlingspipelinen. Functions och App Service integreras med Application Insights för transaktionsspårning från slutpunkt till slutpunkt med minimal konfiguration.

Se till att varje tjänst i kompositionen exponerar mått per tjänst, till exempel begärandefrekvens, felfrekvens och svarstid. Dessa mått hjälper dig att identifiera vilken tjänst som försämras utan att korrelera loggar i hela anropskedjan.

Tillståndshantering

I en mikrotjänstarkitektur äger varje tjänst vanligtvis sina data och externaliserar tillståndet till en dedikerad databas eller cache. Det här mönstret gör att tjänster kan distribueras oberoende av varandra, och alla fyra plattformarna stöder det på samma sätt eftersom datalagret är en separat Azure-resurs.

Plattformarna skiljer sig åt när en tjänst behöver plattformshanterade tillståndsabstraktioner, till exempel aktörsbaserade mönster, arbetsflödesorkestrering eller dedikerad lagring per instans:

• AKS ger mest flexibilitet genom beständiga volymer och StatefulSets, som stöder datalager i klustret och stabil identitet per instans.

• Container Apps stöder volymmonteringar och Dapr-tillståndshantering, inklusive Dapr-aktörer.

• Functions stöder tillståndskänsliga orkestreringar och entiteter via Durable Functions.

• App Service stöder delad lagring via Azure Files-monteringar men tillhandahåller inte tillståndsabstraktioner per instans eller på plattformsnivå.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

I en mikrotjänstarkitektur är den primära tillförlitlighetsrisken ett sammanhängande fel. En ohälsosam tjänst leder till att anropare drabbas av timeouter, och problemet sprider sig genom anropskedjan. Ditt plattformsalternativ påverkar hur du minimerar den här risken.

• AKS och Container Apps tillhandahåller hälsokontroller på plattformsnivå som identifierar ohälsosamma instanser och tar bort dem ur rotationen automatiskt.

• Functions försöker utföra misslyckade körningar på nytt baserat på utlösartypen.

Oavsett plattform implementerar du kretsbrytare, återförsöksprinciper med backoff och timeouter i kommunikationen mellan tjänster för att förhindra att ett enda tjänstfel blir ett systemomfattande avbrott.

Distribuera varje tjänst mellan tillgänglighetszoner för att skydda mot fel på datacenternivå. Kontrollera i en blandad plattformssammansättning att alla plattformar som används stöder zonredundans för distributionsregionen.

Information om plattformsspecifik tillförlitlighet finns i avsnittet om tillförlitlighet i Well-Architected Framework-tjänstguiderna för AKS, Container Apps och Functions.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Mikrotjänster ökar attackytan eftersom varje tjänst-till-tjänst-anrop korsar en nätverksgräns. Behandla all trafik mellan tjänster som obetrodd och kryptera den via mTLS. AKS stöder mTLS via tjänstnät som Istio. Container Apps tillhandahåller mTLS via Dapr- eller miljönivåkonfiguration. Functions och App Service tillhandahåller inte mTLS på plattformsnivå. Om dessa plattformar är värdar för tjänster i din sammansättning, framtvingar du transportsäkerhet via HTTPS på programnivå, API Gateway-principer eller isolering av virtuella nätverk.

I en sammansättning av många tjänster bör varje tjänst endast autentiseras mot de resurser som krävs. Tilldela identiteter för varje tjänst i stället för att dela en enda identitet över arbetsbelastningen. För plattformsspecifika mekanismer, se identitetsraden per tjänst i jämförelsetabellen.

För plattformsspecifik säkerhetsvägledning, se säkerhetsavsnitten i Well-Architected Framework-tjänstguiderna för AKS, Container Apps och Functions.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

En arkitektur för mikrotjänster kan innehålla dussintals tjänster och varje tjänst hanterar olika trafikvolymer. Matcha varje tjänst med den faktureringsmodell som passar dess trafikmönster. Förbrukningsbaserade plattformar som Container Apps och Functions skalar inaktiva tjänster till noll, men dedikerad beräkning som AKS kan vara mer kostnadseffektiv för tjänster som har varaktig belastning. I en sammansättning med blandad plattform är faktureringsflexiteten per tjänst en av de största kostnadsfördelarna. Men ta hänsyn till kostnaderna för att underhålla separata distributionspipelines, övervakningskonfigurationer och teamexpertis på olika plattformar.

Information om plattformsspecifika kostnader finns i avsnittet om kostnadsoptimering i Well-Architected Framework-tjänstguiderna för AKS, Container Apps och Functions.

Referensarkitekturer

Begränsa alternativen till en eller två plattformar genom att tillämpa jämförelsekriterierna i den här artikeln. Kör ett konceptbevis genom att distribuera en representativ delmängd av dina tjänster och testa kommunikation mellan tjänster, skalningsbeteende och distributionsarbetsflöden mot dina behov. Bekräfta att plattformen uppfyller teamets operativa förväntningar innan du förbinder dig till produktion. Följande arkitekturer ger produktionsklara utgångspunkter:

• AKS:Baslinjearkitektur för ett AKS-kluster
• Container Apps:Mikrotjänster med Container Apps och Dapr
• App Service:Grundläggande hög tillgänglighet zon-redundant webbapp
• Azure Red Hat OpenShift:Azure Red Hat OpenShift i en hybridmiljö

Gå vidare

Relaterade resurser

• Utforma en mikrotjänstarkitektur
• Utforma API:er för mikrotjänster
• Använda domänanalys till att modellera mikrotjänster
• Välj en Azure-beräkningstjänst
• Välj en Azure-containertjänst
• Arkitekturöverväganden för att välja en Azure-containertjänst