Een Azure-rekenoptie kiezen voor microservices

  • Artikel

De term compute verwijst naar het hostingmodel voor de computing-resources waarmee uw toepassing wordt uitgevoerd. Voor een microservicearchitectuur zijn met name twee benaderingen populair:

  • Een service-orchestrator die services beheert die worden uitgevoerd op toegewezen knooppunten (VM's).
  • Een serverloze architectuur die gebruikmaakt van FaaS (Functions as a Service).

Hoewel dit niet de enige opties zijn, zijn het 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 over 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.

Overweeg op het Azure-platform 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, voert geautomatiseerde upgrades, automatische patching, automatische schaalaanpassing en andere beheertaken uit. U kunt AKS beschouwen als 'Kubernetes-API's als een service'.

  • Azure Container Apps is een beheerde service die is gebouwd op Kubernetes die de complexiteit van containerindeling en andere beheertaken abstraheert. Container Apps vereenvoudigt de implementatie en het beheer van toepassingen in containers en microservices in een serverloze omgeving, terwijl de functies van Kubernetes worden geboden.

  • Service Fabric is een platform voor gedistribueerde systemen voor het verpakken, implementeren en beheren van microservices. Microservices kunnen in Service Fabric worden geïmplementeerd 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 van het systeem te rapporteren, meldingen over configuratie- en codewijzigingen te ontvangen en andere services te detecteren. Een belangrijk verschil met Service Fabric is de sterke focus op het bouwen van stateful services met behulp van Betrouwbare verzamelingen.

  • Andere opties, zoals Docker-Enterprise Edition kunnen worden uitgevoerd in een IaaS-omgeving in Azure. U vindt implementatiesjablonen op Azure Marketplace.

Containers

Soms praten mensen over containers en microservices alsof ze hetzelfde zijn. Hoewel dat niet waar is( u hebt geen containers nodig om microservices te bouwen), hebben containers wel 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 zijn ze eenvoudig te implementeren. Containers kunnen snel worden gestart en gestopt, zodat u nieuwe exemplaren kunt instellen om meer belasting te verwerken of om te herstellen van knooppuntfouten.

  • Dichtheid. Containers zijn lichtgewicht in vergelijking met het uitvoeren van een virtuele machine, omdat ze besturingssysteemresources delen. Dat 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 zijn voor een container, wat kan helpen ervoor te zorgen dat een runaway-proces de hostresources niet uitput. Zie het Schottenpatroon voor meer informatie.

Serverloos (Functions as a Service)

Met een serverloze architectuur beheert u de VM's of de virtuele netwerkinfrastructuur niet. In plaats daarvan implementeert u code en zorgt de hostingservice ervoor dat deze code op een VIRTUELE machine wordt geïnstalleerd en uitgevoerd. Deze benadering heeft de voorkeur 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 uit de wachtrij leest 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 concepten voor triggers en bindingen Azure Functions voor een volledige lijst. Overweeg ook Azure Event Grid, een beheerde gebeurtenisrouteringsservice 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 sommige 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. Met een orchestrator hebt u veel controle over het configureren en beheren van uw services en het cluster. De afweging is extra complexiteit. Met een serverloze architectuur geeft u enige 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 aanpak.

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 aan de vraag te voldoen, op basis van het aantal binnenkomende gebeurtenissen. Met een orchestrator kunt u uitschalen door het aantal service-exemplaren dat in het cluster wordt uitgevoerd, te verhogen. U kunt ook schalen door extra VM's aan het cluster toe te voegen.

Onze referentie-implementatie maakt voornamelijk gebruik van Kubernetes, maar we hebben Azure Functions wel gebruikt voor één service, 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, had de service een minimale hoeveelheid code nodig. Bovendien maakt de service Delivery History geen deel uit van de hoofdwerkstroom, dus het uitvoeren ervan buiten het Kubernetes-cluster heeft geen invloed op de end-to-end latentie van door de gebruiker geïnitieerde bewerkingen.

Volgende stappen

Communicatie tussen services