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

  • Artikel

Termen beräkning är värdmodellen för de beräkningsresurser som ditt program körs på. För en mikrotjänstarkitektur är två metoder särskilt populära:

  • En tjänstorkestrerare som hanterar tjänster som körs på dedikerade noder (VM).
  • En serverlös arkitektur med funktioner som en tjänst (FaaS).

Även om dessa inte är de enda alternativen är de båda beprövade metoder för att skapa mikrotjänster. Ett program kan innehålla båda metoderna.

Tjänstorkestrerare

En orkestrerare hanterar uppgifter som rör distribution och hantering av en uppsättning tjänster. Dessa uppgifter omfattar att placera tjänster på noder, övervaka tjänsternas hälsotillstånd, starta om tjänster som inte är felfria, belastningsutjämning av nätverkstrafik mellan tjänstinstanser, tjänstidentifiering, skala antalet instanser av en tjänst och tillämpa konfigurationsuppdateringar. Populära orkestrerare är Kubernetes, Service Fabric, DC/OS och Docker Swarm.

Överväg följande alternativ på Azure-plattformen:

  • Azure Kubernetes Service (AKS) är en hanterad Kubernetes-tjänst. AKS etablerar Kubernetes och exponerar Kubernetes API-slutpunkter, men är värd för och hanterar Kubernetes-kontrollplanet, utför automatiserade uppgraderingar, automatisk korrigering, automatisk skalning och andra hanteringsuppgifter. Du kan betrakta AKS som "Kubernetes-API:er som en tjänst".

  • Azure Container Apps är en hanterad tjänst som bygger på Kubernetes som sammanfattar komplexiteten i containerorkestrering och andra hanteringsuppgifter. Container Apps förenklar distributionen och hanteringen av containerbaserade program och mikrotjänster i en serverlös miljö och tillhandahåller samtidigt funktionerna i Kubernetes.

  • Service Fabric är en distribuerad systemplattform för paketering, distribution och hantering av mikrotjänster. Mikrotjänster kan distribueras till Service Fabric som containrar, som binär körbara filer eller som Reliable Services. Med hjälp av programmeringsmodellen Reliable Services kan tjänster direkt använda Service Fabric-programmerings-API:er för att fråga systemet, rapportera hälsotillstånd, ta emot meddelanden om konfigurations- och kodändringar och identifiera andra tjänster. En viktig differentiering med Service Fabric är dess starka fokus på att skapa tillståndskänsliga tjänster med hjälp av Reliable Collections.

  • Andra alternativ som Docker-Enterprise Edition kan köras i en IaaS-miljö i Azure. Du hittar distributionsmallar på Azure Marketplace.

Containers

Ibland pratar man om containrar och mikrotjänster som om de vore samma sak. Även om det inte är sant – du behöver inte containrar för att skapa mikrotjänster – har containrar vissa fördelar som är särskilt relevanta för mikrotjänster, till exempel:

  • Portabilitet. En containeravbildning är ett fristående paket som körs utan att behöva installera bibliotek eller andra beroenden. Det gör dem enkla att distribuera. Containrar kan startas och stoppas snabbt, så att du kan starta nya instanser för att hantera mer belastning eller återställa från nodfel.

  • Densitet. Containrar är lätta jämfört med att köra en virtuell dator eftersom de delar OS-resurser. Det gör det möjligt att packa flera containrar på en enda nod, vilket är särskilt användbart när programmet består av många små tjänster.

  • Resursisolering. Du kan begränsa mängden minne och processor som är tillgänglig för en container, vilket kan bidra till att säkerställa att en skenande process inte uttömmer värdresurserna. Mer information finns i Bulkhead-mönstret .

Serverlös (Funktioner som en tjänst)

Med en serverlös arkitektur hanterar du inte de virtuella datorerna eller den virtuella nätverksinfrastrukturen. I stället distribuerar du kod och värdtjänsten hanterar att placera koden på en virtuell dator och köra den. Den här metoden tenderar att gynna små detaljerade funktioner som samordnas med händelsebaserade utlösare. Ett meddelande som placeras i en kö kan till exempel utlösa en funktion som läser från kön och bearbetar meddelandet.

Azure Functions är en serverlös beräkningstjänst som stöder olika funktionsutlösare, inklusive HTTP-begäranden, Service Bus-köer och Event Hubs-händelser. En fullständig lista finns i Azure Functions utlösare och bindningar. Överväg också Azure Event Grid, som är en hanterad händelseroutningstjänst i Azure.

Orchestrator eller serverlös?

Här är några faktorer att tänka på när du väljer mellan en orchestrator-metod och en serverlös metod.

Hanterbarhet Ett serverlöst program är enkelt att hantera eftersom plattformen hanterar alla beräkningsresurser åt dig. En dirigerare abstraherar vissa aspekter av att hantera och konfigurera ett kluster, men döljer inte helt de underliggande virtuella datorerna. Med en orkestrerare måste du tänka på problem som belastningsutjämning, processor- och minnesanvändning och nätverk.

Flexibilitet och kontroll. En orkestrerare ger dig stor kontroll över att konfigurera och hantera dina tjänster och klustret. Kompromissen är ytterligare komplexitet. Med en serverlös arkitektur ger du upp en viss grad av kontroll eftersom informationen är abstrakt.

Portabilitet. Alla orkestrerare som anges här (Kubernetes, DC/OS, Docker Swarm och Service Fabric) kan köras lokalt eller i flera offentliga moln.

Programintegrering. Det kan vara svårt att skapa ett komplext program med hjälp av en serverlös arkitektur på grund av behovet av att samordna, distribuera och hantera många små oberoende funktioner. Ett alternativ i Azure är att använda Azure Logic Apps för att samordna en uppsättning Azure Functions. Ett exempel på den här metoden finns i Skapa en funktion som integreras med Azure Logic Apps.

Kostnad. Med en orchestrator betalar du för de virtuella datorer som körs i klustret. Med ett serverlöst program betalar du bara för de faktiska förbrukade beräkningsresurserna. I båda fallen måste du ta hänsyn till kostnaden för ytterligare tjänster, till exempel lagring, databaser och meddelandetjänster.

Skalbarhet. Azure Functions skalas automatiskt för att möta efterfrågan, baserat på antalet inkommande händelser. Med en orchestrator kan du skala ut genom att öka antalet tjänstinstanser som körs i klustret. Du kan också skala genom att lägga till ytterligare virtuella datorer i klustret.

Vår referensimplementering använder främst Kubernetes, men vi använde Azure Functions för en tjänst, nämligen leveranshistoriktjänsten. Azure Functions passade bra för just den här tjänsten, eftersom det är en händelsedriven arbetsbelastning. Genom att använda en Event Hubs-utlösare för att anropa funktionen behövde tjänsten en minimal mängd kod. Dessutom är leveranshistoriktjänsten inte en del av huvudarbetsflödet, så att köra den utanför Kubernetes-klustret påverkar inte svarstiden från slutpunkt till slutpunkt för användarinitierade åtgärder.

Nästa steg

Kommunikation mellan tjänster