Een Azure-rekenoptie voor microservices kiezen
De term compute verwijst naar het hostingmodel voor de computing-resources waarmee uw toepassing wordt uitgevoerd. Voor een microservicesarchitectuur zijn twee benaderingen vooral populair:
- Een service-orchestrator die services beheert die worden uitgevoerd op toegewezen knooppunten (VM's).
- Een serverloze architectuur met behulp van functies als een service (FaaS).
Hoewel dit niet de enige opties zijn, zijn ze beide bewezen benaderingen voor het bouwen van microservices. Een toepassing kan beide benaderingen bevatten.
Service-orchestrators
Een orchestrator verwerkt taken met betrekking tot het implementeren en beheren van een set services. Deze taken omvatten het plaatsen van services op knooppunten, het bewaken van de status van services, het opnieuw starten van beschadigde services, het verdelen van netwerkverkeer tussen service-exemplaren, servicedetectie, het schalen van het aantal exemplaren van een service en het toepassen van configuratie-updates. Populaire orchestrators zijn Kubernetes, Service Fabric, DC/OS en Docker Swarm.
Houd op het Azure-platform rekening met de volgende opties:
Azure Kubernetes Service (AKS) is een beheerde Kubernetes-service. AKS richt Kubernetes in en maakt de Kubernetes-API-eindpunten beschikbaar, maar host en beheert het Kubernetes-besturingsvlak, het uitvoeren van geautomatiseerde upgrades, geautomatiseerde patches, automatisch schalen en andere beheertaken. U kunt AKS beschouwen als 'Kubernetes-API's als een service'.
Azure Container Apps is een beheerde service die is gebouwd op Kubernetes waarmee de complexiteit van containerindeling en andere beheertaken wordt geabstraheerd. Container Apps vereenvoudigt de implementatie en het beheer van toepassingen in containers en microservices in een serverloze omgeving en biedt de functies van Kubernetes.
Service Fabric is een platform voor gedistribueerde systemen voor het verpakken, implementeren en beheren van microservices. Microservices kunnen worden geïmplementeerd in Service Fabric als containers, als binaire uitvoerbare bestanden of als Reliable Services. Met behulp van het Reliable Services-programmeermodel kunnen services rechtstreeks gebruikmaken van Service Fabric-programmeer-API's om query's uit te voeren op het systeem, de status te rapporteren, meldingen te ontvangen over configuratie- en codewijzigingen en andere services te detecteren. Een belangrijke differentiatie met Service Fabric is de sterke focus op het bouwen van stateful services met behulp van Reliable Collections.
Andere opties, zoals Docker Enterprise Edition, kunnen worden uitgevoerd in een IaaS-omgeving in Azure. U vindt implementatiesjablonen in Azure Marketplace.
Containers
Soms praten mensen over containers en microservices alsof ze hetzelfde waren. Hoewel dit niet waar is, hebt u geen containers nodig om microservices te bouwen, hebben containers enkele voordelen die met name relevant zijn voor microservices, zoals:
Draagbaarheid. Een containerinstallatiekopieën is een zelfstandig pakket dat wordt uitgevoerd zonder bibliotheken of andere afhankelijkheden te hoeven installeren. Hierdoor kunnen ze eenvoudig worden geïmplementeerd. Containers kunnen snel worden gestart en gestopt, zodat u nieuwe exemplaren kunt instellen om meer belasting te verwerken of om knooppuntfouten te herstellen.
Dichtheid. Containers zijn lichtgewicht vergeleken met het uitvoeren van een virtuele machine, omdat ze besturingssysteembronnen delen. Dit maakt het mogelijk om meerdere containers op één knooppunt te verpakken, wat vooral handig is wanneer de toepassing uit veel kleine services bestaat.
Resource-isolatie. U kunt de hoeveelheid geheugen en CPU beperken die beschikbaar is voor een container, wat kan helpen ervoor te zorgen dat een runaway-proces de hostbronnen niet verbruikt. Zie het patroon Bulkhead voor meer informatie.
Serverloos (Functions as a Service)
Met een serverloze architectuur beheert u de VM's of de infrastructuur van het virtuele netwerk niet. In plaats daarvan implementeert u code en de hostingservice om die code op een virtuele machine te plaatsen en uit te voeren. Deze benadering is meestal gunstig voor kleine gedetailleerde functies die worden gecoördineerd met behulp van triggers op basis van gebeurtenissen. Een bericht dat in een wachtrij wordt geplaatst, kan bijvoorbeeld een functie activeren die wordt gelezen uit de wachtrij en het bericht verwerkt.
Azure Functions is een serverloze rekenservice die ondersteuning biedt voor verschillende functietriggers, waaronder HTTP-aanvragen, Service Bus-wachtrijen en Event Hubs-gebeurtenissen. Zie Azure Functions-triggers en bindingsconcepten voor een volledige lijst. Overweeg ook Azure Event Grid, een beheerde service voor gebeurtenisroutering in Azure.
Orchestrator of serverloos?
Hier volgen enkele factoren waarmee u rekening moet houden bij het kiezen tussen een orchestrator-benadering en een serverloze benadering.
Beheerbaarheid Een serverloze toepassing is eenvoudig te beheren, omdat het platform alle rekenresources voor u beheert. Hoewel een orchestrator enkele aspecten van het beheren en configureren van een cluster abstraheert, worden de onderliggende VM's niet volledig verborgen. Met een orchestrator moet u nadenken over problemen zoals taakverdeling, CPU- en geheugengebruik en netwerken.
Flexibiliteit en controle. Een orchestrator biedt u veel controle over het configureren en beheren van uw services en het cluster. Het compromis is extra complexiteit. Met een serverloze architectuur geeft u enige mate van controle op, omdat deze details worden geabstraheerd.
Draagbaarheid. Alle orchestrators die hier worden vermeld (Kubernetes, DC/OS, Docker Swarm en Service Fabric) kunnen on-premises of in meerdere openbare clouds worden uitgevoerd.
Toepassingsintegratie. Het kan lastig zijn om een complexe toepassing te bouwen met behulp van een serverloze architectuur, vanwege de noodzaak om veel kleine onafhankelijke functies te coördineren, implementeren en beheren. Een optie in Azure is het gebruik van Azure Logic Apps om een set Azure Functions te coördineren. Zie Een functie maken die kan worden geïntegreerd met Azure Logic Apps voor een voorbeeld van deze benadering.
Kosten. Met een orchestrator betaalt u voor de VM's die in het cluster worden uitgevoerd. Met een serverloze toepassing betaalt u alleen voor de werkelijke verbruikte rekenresources. In beide gevallen moet u rekening houden met de kosten van aanvullende services, zoals opslag, databases en berichtenservices.
Schaalbaarheid. Azure Functions wordt automatisch geschaald om te voldoen aan de vraag, op basis van het aantal binnenkomende gebeurtenissen. Met een orchestrator kunt u uitschalen door het aantal service-exemplaren dat wordt uitgevoerd in het cluster te verhogen. U kunt ook schalen door extra VM's toe te voegen aan het cluster.
Onze referentie-implementatie maakt voornamelijk gebruik van Kubernetes, maar we hebben Azure Functions voor één service gebruikt, namelijk de Delivery History-service. Azure Functions was geschikt voor deze specifieke service, omdat het een gebeurtenisgestuurde workload is. Door een Event Hubs-trigger te gebruiken om de functie aan te roepen, heeft de service een minimale hoeveelheid code nodig. De Delivery History-service maakt ook geen deel uit van de hoofdwerkstroom, dus het uitvoeren buiten het Kubernetes-cluster heeft geen invloed op de end-to-end latentie van door de gebruiker geïnitieerde bewerkingen.