Microservices implementeren met Azure Container Apps en Dapr

In dit artikel wordt een oplossing beschreven voor het uitvoeren van een orderbeheersysteem met 10 microservices in Azure Container Apps. De oplossing maakt ook gebruik van aanbevolen procedures voor microservices via Distributed Application Runtime (Dapr) en gebeurtenisgestuurd schalen met Kubernetes-gebeurtenisgestuurde automatische schaalaanpassing (KEDA).

Dapr is een handelsmerk van zijn respectieve bedrijf. Er wordt geen goedkeuring geïmpliceerd door het gebruik van dit merk.

Architectuur

Download een PowerPoint-bestand van deze architectuur.

Gegevensstroom

In deze oplossing wordt een fictief Red Dog-bestelbeheersysteem en de ondersteunende Azure-infrastructuur beschreven. De architectuur bestaat uit één Container Apps-omgeving die als host fungeert voor 10 .NET microservicetoepassingen. Azure Container Apps maakt gebruik van een beheerde envoy-laag voor inkomend verkeer om extern verkeer van gebruikers naar de openbaar weergegeven gebruikersinterface te routeren. Interne service-naar-serviceaanroepen gaan niet via deze ingress. In plaats daarvan gebruiken ze dapr-service-aanroep en Container Apps-servicedetectie in de omgeving. De oplossing maakt gebruik van de Dapr SDK om te integreren met Azure-resources via bouwstenen voor publiceren/abonneren, status en binding. De services maken ook gebruik van KEDA-schaalregels om schaalaanpassing toe te staan op basis van triggergebeurtenissen en schaal-naar-nul-scenario's.

De volgende gegevensstroom komt overeen met het vorige diagram:

1. Beheerd inkomend verkeer: Azure Container Apps biedt een beheerde envoy-laag voor inkomend verkeer voor het routeren van gebruikersaanvragen naar de gebruikersinterface en API-eindpunten die ondersteuning bieden voor het interactieve dashboard.

2. ui: een dashboard met realtime order- en geaggregeerde verkoopgegevens voor het Red Dog-orderbeheersysteem.

3. Virtuele klant: een klantsimulatieprogramma dat klanten simuleert die orders plaatsen via de orderservice.

4. Bestelservice: Een API maken, lezen, bijwerken en verwijderen om orders te plaatsen en te beheren.

5. Boekhoudservice: een service die ordergegevens verwerkt, opslaat en samenvoegt. Het transformeert klantorders in zinvolle verkoopstatistieken die in de gebruikersinterface worden weergegeven.

6. Ontvangstservice: Een archiveringsprogramma dat orderbevestigingen genereert en opslaat voor controle en historische doeleinden.

7. Loyaliteitsservice: Een service die het loyaliteitsprogramma beheert door beloningspunten van klanten bij te houden op basis van orderuitgaven.

8. Makelineservice: Een service die een wachtrij met huidige orders beheert die wachten om te worden voltooid. Hiermee wordt de verwerking en voltooiing van de orders door de virtuele werknemerservice bijgehouden.

9. Virtuele werkrol: een werkrolsimulatieprogramma dat de voltooiing van klantorders simuleert.

Onderdelen

• Application Insights is een uitbreidbare service voor het beheer van toepassingsprestaties die u kunt gebruiken om livetoepassingen te bewaken en automatisch prestatieafwijkingen te detecteren. In deze architectuur gebruikt u Application Insights met Azure Monitor om de containerlogboeken te bekijken en metrische gegevens van de microservices te verzamelen.

• Blob Storage is een cloudoplossing voor het opslaan van enorme hoeveelheden ongestructureerde gegevens, zoals tekst- of binaire bestanden. In deze architectuur maakt een ontvangstservice gebruik van Blob Storage via een Dapr-uitvoerbinding om de orderbevestigingen op te slaan.

• Azure Managed Redis biedt een gegevensarchief in het geheugen op basis van Redis Enterprise-software. In deze architectuur wordt het gebruikt als een Dapr-statusopslagcomponent voor de Makelineservice om gegevens op te slaan over de orders die worden verwerkt.

• Azure Cosmos DB is een NoSQL-databaseservice met meerdere modellen. In deze architectuur wordt het gebruikt als een Dapr-statusarchiefonderdeel voor de loyaliteitsservice om de loyaliteitsgegevens van klanten op te slaan.

• Azure Monitor is een geïntegreerd platform waarmee u klantinhoudsgegevens uit uw Azure-infrastructuuromgevingen kunt verzamelen, analyseren en erop kunt reageren. In deze architectuur gebruikt u Azure Monitor met Application Insights om de containerlogboeken te bekijken en metrische gegevens van de microservices te verzamelen.

• Service Bus is een volledig beheerde berichtenbroker voor ondernemingen met wachtrijen en onderwerpen over publiceren/abonneren. In deze architectuur gebruikt u Service Bus voor de implementatie van het publiceren/abonneren van dapr-onderdelen. Meerdere services gebruiken dit onderdeel. De orderservice publiceert berichten in de bus en de Makeline-, accounting-, loyaliteits- en ontvangstdiensten abonneren zich op deze berichten.

• Container Apps is een volledig beheerde, serverloze containerservice die wordt gebruikt voor het bouwen en implementeren van moderne apps op schaal. In deze architectuur host u alle microservices in Container Apps en implementeert u deze in één Container Apps-omgeving. Deze omgeving fungeert als een veilige afbakening rond het systeem en biedt beheerde, op Envoy gebaseerde ingress voor routering van extern verkeer naar de UI.

• SQL Database is een intelligente, schaalbare relationele databaseservice die is gebouwd voor de cloud. In deze architectuur fungeert het als het gegevensarchief voor de accountingservice, die gebruikmaakt van Entity Framework Core om te interfacen met de database. De bootstrapper-service is verantwoordelijk voor het instellen van de SQL-tabellen in de database. Vervolgens wordt deze één keer uitgevoerd voordat de verbinding met de boekhoudservice tot stand wordt gebracht.

Alternatieven

In deze architectuur maakt het standaardrouteringspad gebruik van de ingebouwde Container Apps-toegangslaag, die wordt geïmplementeerd via een beheerde Envoy-proxy. Als voor een workload aangepast middleware- of protocolgedrag is vereist buiten de systeemeigen functies voor inkomend verkeer, zijn speciale proxy's zoals NGINX of HAProxy alternatieven.

Alle Azure-infrastructuur, met uitzondering van SQL Database, maakt gebruik van Dapr-onderdelen voor interoperabiliteit. Een voordeel van Dapr is dat u al deze onderdelen kunt wisselen door de implementatieconfiguratie van container-apps te wijzigen. In dit scenario laten Service Bus, Azure Cosmos DB, Azure Managed Redis en Blob Storage enkele van de meer dan 70 beschikbare Dapr-onderdelen zien. Een lijst met alternatieve brokers voor publiceren/abonneren, toestandsopslag en uitvoerbindingen is beschikbaar in de Dapr-documenten.

Details van het scenario

Microservices zijn een veelgebruikte architectuurstijl. Ze bieden voordelen zoals schaalbaarheid, flexibiliteit en onafhankelijke implementaties. U kunt containers gebruiken als mechanisme voor het implementeren van microservicestoepassingen en vervolgens een containerorchestrator zoals Kubernetes gebruiken om bewerkingen te vereenvoudigen. Er zijn veel factoren die u kunt overwegen voor grootschalige microservicesarchitecturen. Normaal gesproken vereist het infrastructuurplatform een aanzienlijk begrip van complexe technologieën zoals containerorchestrators.

Container Apps is een volledig beheerde serverloze containerservice voor het uitvoeren van moderne toepassingen op schaal. Hiermee kunt u container-apps implementeren via een abstractie van het onderliggende platform. Met deze methode hoeft u geen ingewikkelde infrastructuur te beheren.

Deze architectuur maakt gebruik van Container Apps-integratie met een beheerde versie van de Dapr. Dapr is een opensource-project waarmee ontwikkelaars de inherente uitdagingen in gedistribueerde toepassingen kunnen overwinnen, zoals statusbeheer en serviceaanroepen.

Container Apps biedt ook een beheerde versie van KEDA. Met KEDA kunnen uw containers automatisch worden geschaald op basis van binnenkomende gebeurtenissen van externe services, zoals Service Bus en Azure Managed Redis.

Container Apps biedt ook beheerde, op Envoy gebaseerde ingress, zodat u HTTP-eindpunten kunt blootstellen, aangepaste domeinen en beheerde TLS kunt gebruiken en scenario’s voor verkeerssplitsing kunt ondersteunen zonder een afzonderlijke proxylaag te implementeren.

Zie Container Apps vergelijken met andere Azure-containeropties voor meer informatie.

In dit artikel wordt een oplossing beschreven voor het uitvoeren van een orderbeheersysteem met 10 microservices in Container Apps. De oplossing maakt ook gebruik van best practices voor microservices via Dapr en gebeurtenisgestuurd schalen met KEDA.

Potentiële gebruikscases

Deze oplossing is van toepassing op elke organisatie die staatloze en stateful microservices gebruikt voor gedistribueerde systemen. De oplossing is het beste voor consumenten verpakte goederen en productiebranches die een bestel- en leveringssysteem hebben.

De volgende oplossingen hebben vergelijkbare ontwerpen:

• Architectuur op basis van microservices in AKS (Azure Kubernetes Service)
• Microservicesarchitectuur in Azure Functions
• Gebeurtenisgestuurde architecturen

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 Frameworkvoor meer informatie.

Betrouwbaarheid

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

Container Apps is gebouwd op een Kubernetes-basis, die fungeert als de onderliggende infrastructuur. Tolerantiemechanismen zijn ingebouwd in Kubernetes die containers of pods bewaken en opnieuw opstarten als er problemen zijn. De tolerantiemechanismen omvatten een ingebouwde load balancer die verkeer distribueert over meerdere replica's van elke container-app. Met deze redundantie kan het systeem operationeel blijven, zelfs als één replica niet beschikbaar is.

Container Apps biedt ook servicedetectie- en tolerantiebeleid dat u kunt gebruiken om time-outs en circuitonderbrekergedrag tussen services toe te passen. Voor services waarvoor Dapr is ingeschakeld, configureer app-statusinstellingen zodat replica's met een slechte status eerder worden gedetecteerd en verkeer wordt weggeleid van gedegradeerde instanties voordat storingen zich trapsgewijs uitbreiden naar downstreamonderdelen.

Veiligheid

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

De volgende lijst bevat een overzicht van verschillende beveiligingsfuncties die in deze architectuur worden weggelaten, samen met andere aanbevelingen en overwegingen:

• Deze architectuur maakt geen gebruik van privé-eindpunten, waardoor beveiligdere privéconnectiviteit met Azure-services mogelijk is door ze een IP-adres toe te wijzen vanuit uw virtuele netwerk. Wanneer privé-eindpunten worden gebruikt, kan openbare netwerktoegang worden uitgeschakeld. Deze aanpak houdt verkeer op de Microsoft-backbone en verbetert de beveiliging en naleving.

  Als alternatief voor privé-eindpunten kunt u overwegen Azure Network Security Perimeter te gebruiken om de netwerktoegang tot Microsoft.ServiceBus/namespaces en Microsoft.Storage/storageAccounts te beperken. Met een netwerkbeveiligingsperimeter kunt u deze resources koppelen aan een gedeelde perimeter en regels voor binnenkomende toegang definiëren. In deze architectuur wordt Container Apps niet geïmplementeerd met een aangepast virtueel netwerk of een statisch uitgaand IP-adres, dus beperk de regel voor inkomend verkeer voor het abonnement dat als host fungeert voor de Container Apps-omgeving in plaats van een IP-bereik, waarvoor een stabiel, bekend bron-IP-adres effectief moet zijn.

• Netwerkactiviteit moet continu worden bewaakt om misbruik te detecteren en te voorkomen. U kunt deze aanpak bereiken met behulp van een Azure Firewall en routetabellen. Met de routetabellen kan verkeer dat een virtueel netwerk verlaat eerst worden doorgegeven via de firewall. Dit proces is een belangrijke stap om ervoor te zorgen dat uw architectuur niet kwetsbaar is voor aanvallen op gegevensexfiltratie.

• Gebruik een WAF (Web Application Firewall) om te beschermen tegen veelvoorkomende beveiligingsproblemen. Gebruik Azure Front Door of Azure Application Gateway om een WAF in deze architectuur te implementeren.

• Overweeg het gebruik van de ingebouwde verificatie- en autorisatiefunctie voor Container Apps, ook wel Easy Auth genoemd. Easy Auth verwerkt integratie met id-providers buiten uw web-app, waardoor de hoeveelheid code die u moet onderhouden, wordt verminderd.

• Beheerde identiteit gebruiken voor workload-identiteiten. Beheerde identiteit elimineert de noodzaak voor ontwikkelaars om verificatiereferenties te beheren. De basisarchitectuur wordt bijvoorbeeld geverifieerd bij SQL Server via een wachtwoord in een verbindingsreeks. Gebruik indien mogelijk Microsoft Entra-id's om te verifiëren bij Azure SQL Server.

Kostenoptimalisatie

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

Gebruik de Azure-prijscalculator om de kosten van de services in deze architectuur te schatten.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.

Dapr voegt een draagbaarheidslaag toe tussen uw services en de bijbehorende back-upinfrastructuur. Deze laag biedt waarde wanneer u verwacht dat de backing-services worden gewijzigd of wanneer u een onderdeel, zoals een statusarchief of berichtenbroker, wilt wisselen via configuratie in plaats van code. Dapr voegt ook een afhankelijkheid en een niveau van indirectie toe. Wanneer u een redelijk stabiele set Azure systeemeigen eindpunten hebt die u niet verwacht te vervangen, is het aanroepen van de systeemeigen Azure-SDK's rechtstreeks een redelijk alternatief waarmee de Dapr-abstractie wordt verwijderd. Weeg de flexibiliteit van Dapr-onderdelen af tegen de operationele eenvoud van directe SDK-aanroepen.

U kunt Azure Monitor en Application Insights gebruiken om Container Apps te bewaken. Gebruik voor gedistribueerde toepassingen een pijplijn op basis van OpenTelemetry om traceringen, logboeken en metrische gegevens te verzenden naar Azure Monitor en Application Insights. U kunt ook containerlogboeken weergeven door in de portal naar het deelvenster Logboeken in elke container-app te navigeren en vervolgens de volgende Kusto-query uit te voeren. In dit voorbeeld ziet u logboeken voor de Makeline-service-app.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Het toepassingsoverzicht in Application Insights laat ook zien hoe de services in realtime communiceren. U kunt ze vervolgens gebruiken voor foutopsporingsscenario's. Navigeer naar het toepassingsoverzicht onder de Application Insights-resource om iets als de volgende kaart weer te geven.

Zie Een app bewaken in Container Apps voor meer informatie.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

Deze oplossing is sterk afhankelijk van de KEDA-implementatie in Container Apps voor gebeurtenisgestuurd schalen. Wanneer u de virtuele klantenservice implementeert, plaatst deze continu orders. Deze schaalactie zorgt ervoor dat de orderservice omhoog wordt geschaald via een HTTP-schaalregel. Wanneer de orderservice de orders publiceert op de service bus, zorgen Service Bus schaalregels ervoor dat de boekhoud-, ontvangst-, Makeline- en loyaliteitsservices omhoog worden geschaald. De gebruikersinterface en Makeline-service kunnen ook HTTP-schaalregels gebruiken, zodat de apps worden geschaald naarmate meer gebruikers toegang hebben tot het dashboard.

Wanneer de virtuele klant niet actief is, worden alle microservices in deze oplossing geschaald naar nul, met uitzondering van de virtuele medewerker- en Makeline-services. De virtuele werker wordt niet afgeschaald omdat het continu orders controleert op afhandeling. Zie Schaalregels instellen in Container Apps voor meer informatie.

Werkbelastingprofielen

Gebruik workloadprofielen om services te scheiden die een warme capaciteit nodig hebben van services die het meeste profiteren van serverloze elasticiteit. In dit diagram zijn de services Order en Accounting weergegeven op een Dedicated-profiel, omdat ze transactioneel werk verwerken en live bedrijfsstatistieken ondersteunen. De ontvangstservice en loyaliteitsservice worden weergegeven in een verbruiksprofiel omdat ze gebeurtenisgestuurde services zijn die beter kunnen profiteren van serverloze elasticiteit.

Op KEDA gebaseerde schaalregels werken voor zowel verbruiks- als toegewezen workloadprofielen. Verbruik is het beste voor services die naar nul kunnen schalen, terwijl Dedicated beter is voor services die nog steeds profiteren van automatisch schalen, maar warme capaciteit of stabielere prestaties nodig hebben.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• Alice Gibbons | Cloud Native Global Black Belt

Andere Inzenders:

• Lynn Orrell | Principal Solution Specialist (GBB)
• Kendall Roden | Senior Program Manager

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Container Apps-documentatie
• Container Apps vergelijken met andere Azure-containeropties

Verwante bronnen

• Microservicesarchitectuur op AKS
• Geavanceerde AKS-microservicesarchitectuur
• Continue integratie en continue levering voor AKS-apps met Azure-pipelines