Een Azure-rekenoptie voor microservices kiezen

Dit artikel helpt u bij het kiezen van een Azure-rekenplatform voor een workload die is gebaseerd op een microservicesarchitectuur. Een microservicesarchitectuur bestaat uit kleine, onafhankelijk implementeerbare services die communiceren via het netwerk. Uw rekenplatform moet onafhankelijke schaalaanpassing, onafhankelijke implementatie en betrouwbare communicatie tussen services ondersteunen.

Zie Een Azure-rekenservice kiezen voor beslissingsfactoren die van toepassing zijn op elke workload, zoals teamvaardigheden, netwerken en draagbaarheid. Dit artikel richt zich op de factoren die specifiek voor microservices belangrijk zijn.

Azure-rekenplatforms voor microservices

De volgende Azure-platforms ondersteunen microservicesworkloads. Ze verschillen in de mate van indeling, communicatie tussen services en schaalaanpassing die ze bieden.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is een beheerde Kubernetes-service die directe toegang biedt tot Kubernetes-API's en het besturingsvlak. AKS biedt knooppuntbeheer, patches en optionele automatische upgrades. U configureert het cluster-, netwerk- en schaalbeleid.

Voor microservices ondersteunt AKS service-meshes zoals Istio voor verkeerbeheer en wederzijdse MTLS (Transport Layer Security), schaalaanpassing per implementatie via Horizontale automatische schaalaanpassing van pods (HPA) en Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA) en Kubernetes-systeemeigen implementatiestrategieën zoals rolling updates en canary-releases.

AKS Automatic is een modus van AKS waarmee knooppuntbeheer, schalen, beveiliging en waarneembaarheid vooraf worden geconfigureerd op basis van goed ontworpen aanbevelingen van AKS, zodat teams een productieklaar cluster krijgen zonder configuratie per mogelijkheid.

Azure Container Apps - een dienst van Microsoft waarmee je containers kunt uitvoeren en beheren in de cloud.

Azure Container Apps is een beheerde service die is gebouwd op Kubernetes waarmee clusterbeheer wordt geabstraheerd.

Container Apps biedt ingebouwde functies voor microservices, waaronder servicedetectie, Dapr-integratie voor service-naar-service-aanroep met mTLS, berichten voor uitgeversabonnee en statusbeheer. Automatisch schalen op basis van KEDA maakt schaalaanpassing op basis van gebeurtenissen mogelijk, inclusief schalen naar nul. Container Apps ondersteunt ook verkeersverdeling tussen revisies voor canary-implementaties en jobs voor on-demand, geplande of gebeurtenisgestuurde taken.

In Container Apps worden kubernetes-API's niet weergegeven. Als de configuratie van uw implementatiehulpprogramma's of service-mesh afhankelijk is van Kubernetes-primitieven, gebruikt u in plaats daarvan AKS.

Azure Functions

Azure Functions is een serverloze, gebeurtenisgestuurde rekenservice die geschikt is voor microservices die reageren op triggers zoals HTTP-aanvragen, wachtrijberichten of timers. Functions schaalt elke functie-app onafhankelijk en kan naar nul worden geschaald. Voor microservices implementeert u elke service als een eigen functie-app.

Functions biedt geen servicedetectie op platformniveau of communicatie tussen services. Implementeer deze mogelijkheden in toepassingscode of via externe services zoals Azure API Management.

Functions ondersteunt meerdere programmeertalen. U kunt ook het Functions-programmeermodel uitvoeren in Container Apps, waarin Functions-triggers en -bindingen worden gecombineerd met Container Apps-netwerken en schaalfuncties.

Azure App Service

Azure App Service is geschikt voor op HTTP gebaseerde microservices, zoals web-API's. App Service ondersteunt het implementeren als code of als één container. Het biedt ingebouwde automatische schaalaanpassing, implementatiesites voor blauwgroene implementaties en op percentages gebaseerde verkeersroutering, en integratie met CI/CD-pijplijnen (continue integratie en continue levering). App Service biedt geen servicedetectie, dus het is geschikt voor microservices die communiceren via externe berichten of een API-gateway in plaats van te vertrouwen op communicatie op platformniveau.

Azure Red Hat OpenShift

Azure Red Hat OpenShift biedt volledig beheerde OpenShift-clusters en breidt Kubernetes uit met een ervaren ontwikkelaarservaring. Red Hat en Microsoft ontwikkelen, voeren uit en ondersteunen de dienst gezamenlijk. Gebruik Azure Red Hat OpenShift wanneer uw organisatie standaardiseert op OpenShift.

Platforms voor microservices vergelijken

In de volgende tabel wordt vergeleken hoe elk platform de mogelijkheden ondersteunt die van belang zijn voor een microservicesarchitectuur. Zie Een Azure-containerservice kiezen voor een gedetailleerdere vergelijking van Azure-platformen voor containerhosting en hun mogelijkheden.

App-niveau in deze tabel betekent dat het platform niet de mogelijkheid biedt als een ingebouwde functie. U implementeert deze in toepassingscode via een SDK of een externe service, die een afhankelijkheid van die service introduceert.

Uw platform kiezen

• Begin met Container Apps als u ingebouwde microservices-primitieven wilt, zoals serviceontdekking, Dapr en schaalbaarheid per app, inclusief terugschalen naar nul, zonder clusterbeheer.

• Kies AKS wanneer u directe Kubernetes-API-toegang, aangepaste service-meshconfiguratie of fijnmazige controle over clusterinfrastructuur nodig hebt, zoals knooppuntgroepen, netwerkbeleid of planningsbeperkingen.

• Gebruik Functies voor gebeurtenisgestuurde microservices met sporadische of plotselinge pieken in verkeerspatronen die baat hebben bij schaal-tot-nul-facturering en uitvoering op basis van triggers.

• Gebruik App Service voor eenvoudige HTTP-services die geen servicedetectie of communicatiefuncties tussen services op platformniveau nodig hebben.

Uw microservicesworkload hoeft niet op één platform te worden uitgevoerd. U kunt bijvoorbeeld kernservices uitvoeren op AKS of Container Apps terwijl Functions gebeurtenisgestuurde workloads verwerkt. Evalueer elke service in uw samenstelling op basis van een eigen verkeerspatroon, schaalvereisten en communicatiebehoeften. Kies het platform dat past bij die service in plaats van de service af te dwingen om het platform aan te passen.

Belangrijke beslissingsfactoren

In de vergelijkingstabel ziet u wat elk platform ondersteunt. In de volgende secties kunt u deze mogelijkheden afwegen op basis van welke microservices het belangrijkst zijn voor uw workload.

Communicatie tussen services

Microservices zijn afhankelijk van betrouwbare service-naar-service-communicatie met mogelijkheden zoals servicedetectie, nieuwe pogingen en mTLS.

Als uw architectuur afhankelijk is van synchrone service-tot-service-oproepen tussen veel services, geef prioriteit aan een platform met ingebouwde communicatieprimitieven. Container Apps biedt deze primitieven via Dapr zonder extra infrastructuur. AKS biedt ze via service-meshes zoals Istio, waarmee u controle hebt over verkeersbeleid, nieuwe pogingen en circuitonderbrekingen op mesh-niveau. U beheert de levenscyclus, configuratie en upgrades van mesh.

Als uw services voornamelijk communiceren via asynchrone berichten zoals wachtrijen of gebeurtenisstromen, zijn de ingebouwde communicatiefuncties van het platform minder belangrijk omdat u met deze services moet communiceren via een SDK of een abstractie. Gebruik het Asynchrone Request-Reply patroon voor langlopende bewerkingen, omdat time-outs van platformen een probleem kunnen worden. Functions en App Service dwingen bijvoorbeeld een time-out van 230 seconden http-respons af vanwege limieten van Azure Load Balancer.

Onafhankelijk schalen

Elke microservice in een samenstelling heeft verschillende belastingskenmerken.

Als uw services zeer variabel of plotseling piekverkeer hebben, kunnen Container Apps en Functions per service worden geschaald en kunnen niet-actieve services naar nul worden geschaald. Deze aanpak voorkomt ongebruikte capaciteitskosten. Voor Functions is elke functie-app de schaaleenheid, dus implementeer elke microservice als een eigen functie-app. AKS biedt schaalaanpassing per implementatie. U beheert gedeelde knooppuntenpools die geselecteerd blijven en gebruikersknooppuntenpools kunnen worden geschaald tot nul.

Schaal-naar-nulplatforms zorgen voor koude startlatentie wanneer een niet-actieve service de eerste aanvraag ontvangt. In een microservicesarchitectuur kan één gebruikersaanvraag meerdere services doorlopen. Als verschillende services in de oproepketen koud zijn, neemt de latentie toe. Voor synchrone interserviceaanroepen waarvoor lage latentie is vereist, gebruikt u de koude startbeperkingsfuncties van het platform of betaalt u de kosten om minimale exemplaren actief te houden om koude start te voorkomen.

Als uw services een stabiele, voorspelbare belasting hebben, kunnen AKS of App Service de kosten verlagen omdat u betaalt voor gereserveerde capaciteit in plaats van facturering op basis van verbruik.

Onafhankelijke implementeerbaarheid

U moet afzonderlijke microservices implementeren, bijwerken en terugdraaien zonder dat dit van invloed is op de rest van het systeem. Alle vier platforms bieden ondersteuning voor onafhankelijke implementatiemogelijkheden, maar ze verschillen in de wijze waarop u wijzigingen valideert. Container Apps en AKS ondersteunen verkeerssplitsing als basisfunctie voor geleidelijke uitrollen. App Service biedt ondersteuning voor verkeersroutering op basis van percentages over deploymentslots. Functions ondersteunt implementatieslots op Premium- en Dedicated-abonnementen.

Gedistribueerde waarneembaarheid

Eén gebruikersaanvraag kan veel services doorkruisen. Als u gecorreleerde traceringen in de volledige oproepketen nodig hebt, controleert u of de waarneembaarheidsprogramma's van uw platform zijn geïntegreerd met uw traceringsstrategie. Container Apps biedt ingebouwde waarneembaarheid met Dapr-tracering. AKS kan worden geïntegreerd met OpenTelemetry en opensource-traceringsprogramma's, waarmee u de back-end voor tracering (zoals Jaeger, Zipkin of Azure Monitor) kunt kiezen, maar hiervoor moet u de verzamelingspijplijn implementeren en configureren. Functies en App Service kunnen worden geïntegreerd met Application Insights voor end-to-end transactietracering met minimale configuratie.

Zorg ervoor dat elke service in de samenstelling metrische gegevens per service weergeeft, zoals aanvraagsnelheid, foutpercentage en latentie. Deze metrische gegevens helpen u bij het identificeren van welke service verslechtert zonder logboeken in de volledige oproepketen te correleren.

Toestandbeheer

In een microservicesarchitectuur is elke service doorgaans eigenaar van de gegevens en externaliseert deze naar een toegewezen database of cache. Dit patroon zorgt ervoor dat services onafhankelijk kunnen worden geïmplementeerd en alle vier de platforms ondersteunen het evenzeer omdat het gegevensarchief een afzonderlijke Azure-resource is.

De platformen verschillen wanneer een service abstracties van door het platform beheerde status nodig heeft, zoals op actor gebaseerde patronen, werkstroomindeling of toegewezen opslag per exemplaar:

• AKS biedt de meeste flexibiliteit via permanente volumes en StatefulSets, die ondersteuning bieden voor in-clustergegevensarchieven en stabiele identiteit per instantie.

• Container Apps ondersteunt volumekoppelingen en Dapr-statusbeheer, inclusief Dapr-actoren.

• Functions ondersteunt stateful orkestraties en entiteiten via Durable Functions.

• App Service biedt ondersteuning voor gedeelde opslag via Azure Files-koppelingen, maar biedt geen opslagruimte per exemplaar of statusabstracties op platformniveau.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

In een microservicesarchitectuur is het primaire betrouwbaarheidsrisico een cascadefout. Een beschadigde service zorgt ervoor dat bellers time-outs verzamelen en het probleem wordt doorgegeven via de oproepketen. Uw platformkeuze is van invloed op de wijze waarop u dit risico beperkt.

• AKS en Container Apps bieden statuscontroles op platformniveau waarmee beschadigde exemplaren worden gedetecteerd en die automatisch uit roulatie worden verwijderd.

• Functies probeert mislukte uitvoeringen opnieuw uit te voeren op basis van het triggertype.

Implementeer circuitonderbrekers, beleid voor opnieuw proberen met back-offs en time-outs in uw interservicecommunicatie, ongeacht het platform, om te voorkomen dat één servicefout een systeembrede storing wordt.

Implementeer elke service in beschikbaarheidszones om te beschermen tegen storingen op datacenterniveau. Controleer in een gemengde-platformsamenstelling of alle gebruikte platforms zoneredundantie ondersteunen voor uw implementatieregio.

Zie de secties over betrouwbaarheid van de Well-Architected Framework-servicehandleidingen voor AKS, Container Apps en Functions voor platformspecifieke richtlijnen voor betrouwbaarheid.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

Microservices vergroten de kwetsbaarheid voor aanvallen omdat elke service-naar-service-aanroep een netwerkgrens overschrijdt. Behandel al het interserviceverkeer als niet-vertrouwd en versleutel het via mTLS. AKS ondersteunt mTLS via service-meshes zoals Istio. Container Apps voorziet van mTLS via Dapr of configuratie op het niveau van de omgeving. Functions en App Service bieden geen mTLS op platformniveau. Als deze platforms diensten in uw samenstelling hosten, zorg voor transportbeveiliging via HTTPS op applicatielaag, API-gatewaybeleid of isolatie van virtuele netwerken.

In een samenstelling van veel services moet elke service zich alleen authentiseren met de middelen die het nodig heeft. Wijs identiteiten per service toe in plaats van één identiteit te delen in de workload. Zie voor platformspecifieke mechanismen de rij per-service-identiteit in de vergelijkingstabel.

Zie de beveiligingssecties van de Well-Architected Framework-servicehandleidingen voor AKS, Container Apps en Functions voor platformspecifieke beveiligingsrichtlijnen.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

Een microservicesarchitectuur kan tientallen services bevatten en elke service verwerkt verschillende verkeersvolumes. Koppel elke service aan het factureringsmodel dat past bij het verkeerspatroon. Platformen op basis van verbruik, zoals Container Apps en Functions, schalen niet-actieve services naar nul, maar toegewezen rekenkracht zoals AKS kan rendabeler zijn voor services die langdurige belasting hebben. In een combinatie van platformsamenstelling is flexibiliteit per service facturering een van de belangrijkste kostenvoordelen. Houd echter rekening met de overhead voor het onderhouden van afzonderlijke implementatiepijplijnen, bewakingsconfiguraties en teamexpertise op verschillende platforms.

Zie de secties voor kostenoptimalisatie van de Well-Architected Framework-servicehandleidingen voor AKS, Container Apps en Functions voor informatie over platformspecifieke kosten.

Referentiearchitecturen

Beperk uw opties tot één of twee platforms door de vergelijkingscriteria in dit artikel toe te passen. Voer een proof-of-concept uit door een representatieve subset van uw services te implementeren en communicatie tussen services, schaalgedrag en implementatiewerkstromen te testen op basis van uw vereisten. Controleer of het platform voldoet aan de operationele verwachtingen van uw team voordat u zich gaat inzetten voor productie. De volgende architecturen bieden uitgangspunten die gereed zijn voor productie:

• AKS:Basislijnarchitectuur voor een AKS-cluster
• Container Apps:Microservices met Container Apps en Dapr
• App Service:Maximaal beschikbare zone-redundante webtoepassing basislijn
• Azure Red Hat OpenShift:Azure Red Hat OpenShift in een hybride omgeving

Volgende stap

Verwante middelen

• Een microservicearchitectuur ontwerpen
• API's ontwerpen voor microservices
• Domeinanalyse gebruiken om microservices te modelleren
• Een Azure Compute-service kiezen
• Een Azure-containerservice kiezen
• Overwegingen voor architectuur voor het kiezen van een Azure-containerservice