Välj ett Azure-beräkningsalternativ för mikrotjänster
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änstdirigering som hanterar tjänster som körs på dedikerade noder (VM).
- En serverlös arkitektur med funktioner som en tjänst (FaaS).
Dessa är inte de enda alternativen, men båda är 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 hälsotillståndet för tjänster, starta om tjänster med feltillstånd, belastningsutjämna nätverkstrafik över tjänstinstanser, tjänstidentifiering, skala antalet instanser av en tjänst och tillämpa konfigurationsuppdateringar. Populära initierare ä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 tilldelar Kubernetes och exponerar Kubernetes API-slutpunkterna, men är värd för och hanterar Kubernetes-kontrollplanet, utför automatiska uppgraderingar, automatisk uppdatering, autoskalning och andra hanteringsuppgifter. Du kan tänka på AKS som "Kubernetes-API:er som en tjänst".
Service Fabric är en distribuerad systemplattform för paketering, distribution och hantering av mikrotjänster. Mikrotjänster kan distribueras till Service Fabric som containrar, binära körbara filer eller som Reliable Services. Med hjälp Reliable Services-programmeringsmodellen kan tjänster direkt använda Service Fabric 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 skillnad med Service Fabric är dess starka fokus på att skapa tillståndsful-tjänster med Reliable Collections.
Andra alternativ som Docker Enterprise Edition och Mesosphere DC/OS kan köras i en IaaS-miljö på 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 efter 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 cpu som är tillgängligt för en container, vilket kan bidra till att säkerställa att en skenande process inte tar slut på värdresurserna. Mer information finns i Mönstret Bulkhead.
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 prioritera små detaljerade funktioner som koordineras med hjälp av 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 även Azure Event Grid, som är en tjänst för routning av hanterade händelser i Azure.
Orkestrerare eller serverlös?
Här är några faktorer att tänka på när du väljer mellan en orkestreringsmetod och en serverlös metod.
Hanterbarhet Ett serverlöst program är enkelt att hantera eftersom plattformen hanterar alla beräkningsresurser åt dig. Även om en orkestrerare abstraherar vissa aspekter av att hantera och konfigurera ett kluster, döljer den inte helt de underliggande virtuella datorerna. Med en initierare behöver du tänka på problem som belastningsutjämning, processor- och minnesanvändning och nätverk.
Flexibilitet och kontroll. En initierare 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 viss grad av kontroll eftersom den här informationen är abstraherad.
Portabilitet. Alla initierare 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 initierare betalar du för de virtuella datorer som körs i klustret. Med ett serverlöst program betalar du bara för de faktiska beräkningsresurser som förbrukas. I båda fallen måste du ta med 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 initierare 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 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 Event Hubs en utlösare för att anropa funktionen behövde tjänsten en minimal mängd kod. Dessutom är tjänsten Leveranshistorik inte en del av huvudarbetsflödet, så att köra den utanför Kubernetes-klustret påverkar inte svarstiden från slutet till slut för användarinitierade åtgärder.