In dit artikel wordt beschreven hoe u bedrijfskritieke webtoepassingen implementeert met behulp van Azure-app Service. De architectuur maakt gebruik van het betrouwbare web-app-patroon als uitgangspunt. Gebruik deze architectuur als u een verouderde workload hebt en paaS-services (Platform-as-a-Service) wilt gebruiken.
Betrouwbaar web-app-patroon voor .NET biedt richtlijnen voor het bijwerken of opnieuw platformen van web-apps die u naar de cloud verplaatst, het minimaliseren van vereiste codewijzigingen en het doel van een serviceniveaudoelstelling (SLO) van 99,9%. Bedrijfskritieke workloads hebben hoge betrouwbaarheids- en beschikbaarheidsvereisten. Als u een SLO van 99,95%, 99,99% of hoger wilt bereiken, moet u aanvullende bedrijfskritieke ontwerppatronen en operationele rigor toepassen. In dit artikel worden belangrijke technische gebieden beschreven en wordt uitgelegd hoe u essentiële ontwerpprocedures implementeert en introduceert.
Notitie
De richtlijnen in dit artikel zijn gebaseerd op de ontwerpmethodologie en best practices in de well-Architected Framework missiekritieke workloadreeks .
In de volgende secties wordt uitgelegd hoe u:
- Bekijk de bestaande workload om inzicht te hebben in de onderdelen, gebruikers- en systeemstromen en vereisten voor beschikbaarheid en schaalbaarheid.
- Ontwikkel en implementeer een architectuur voor schaaleenheden om end-to-end schaalbaarheid te optimaliseren door middel van compartimentalisatie en om het proces van het toevoegen en verwijderen van capaciteit te standaardiseren.
- Implementeer stateless, kortstondige schaaleenheden of implementatiestempels om schaalbaarheid en implementaties zonder downtime mogelijk te maken.
- Bepaal of u de workload kunt splitsen in onderdelen om u voor te bereiden op schaalbaarheid. Afzonderlijke onderdelen zijn vereist voor schaalbaarheids- en ontkoppelingsstromen.
- Bereid u voor op wereldwijde distributie door een workload in meerdere Azure-regio's te implementeren om de nabijheid van de klant te verbeteren en potentiële regionale storingen voor te bereiden.
- Koppel onderdelen los en implementeer een gebeurtenisgestuurde architectuur.
Architectuur
In het volgende diagram worden de vorige overwegingen toegepast op het betrouwbare web-app-patroon.
Een Visio-bestand van deze architectuur downloaden.
Het rode vak vertegenwoordigt een schaaleenheid met services die samen worden geschaald. Als u ze effectief wilt schalen, optimaliseert u de grootte, SKU en beschikbare IP-adressen van elke service. Het maximum aantal aanvragen dat Azure-app Configuration gebruikt, is bijvoorbeeld gerelateerd aan het aantal aanvragen per seconde dat een schaaleenheid biedt. Wanneer u meer capaciteit in een regio toevoegt, moet u ook meer afzonderlijke schaaleenheden toevoegen.
Deze afzonderlijke schaaleenheden hebben geen afhankelijkheden en communiceren alleen met gedeelde services buiten de afzonderlijke schaaleenheid. U kunt onafhankelijke schaaleenheden vooraf testen. Om te voorkomen dat dit van invloed is op andere implementatiegebieden, moet u onafhankelijke schaaleenheden implementeren en de optie introduceren om services in een nieuwe release te vervangen.
Voor bedrijfskritieke workloads zijn onafhankelijke schaaleenheden tijdelijk, waardoor de implementatieprocessen worden geoptimaliseerd en schaalbaarheid binnen en tussen regio's wordt geboden. Vermijd het opslaan van statussen in onafhankelijke schaaleenheden. Overweeg het gebruik van Azure Cache voor Redis voor opslag in de schaaleenheid en sla alleen kritieke status of gegevens op die ook in de database zijn opgeslagen. Als er een storing in de schaaleenheid is of als u overschakelt naar een andere schaaleenheid, is er mogelijk een vertraging of een nieuwe aanmelding vereist, maar Azure Cache voor Redis nog steeds wordt uitgevoerd.
Application Insights wordt uitgesloten van de schaaleenheid. Sluit services uit waarmee gegevens worden opgeslagen of bewaakt. Scheid ze in hun eigen resourcegroep met hun eigen levenscyclus.
Wanneer u een schaaleenheid vervangt of een nieuwe implementeert, bewaart u historische gegevens en gebruikt u één exemplaar per regio.
Zie Toepassingsontwerp van bedrijfskritieke workloads in Azure voor meer informatie.
Onderdelen
Deze architectuur maakt gebruik van de volgende onderdelen.
- App Service is het platform voor het hosten van toepassingen.
- Azure Cache voor Redis slaat aanvragen in de cache op.
- App Configuration slaat configuratie-instellingen op.
- Azure SQL is de back-enddatabase.
- Application Insights haalt telemetrie op van de toepassing.
Alternatieven
In het betrouwbare web-app-patroon kunt u het volgende doen:
- Gebruik Azure Kubernetes Service (AKS) in plaats van App Service. Deze optie werkt goed voor complexe workloads met een groot aantal microservices. AKS biedt meer controle over de onderliggende infrastructuur en maakt complexe instellingen met meerdere lagen mogelijk.
- Plaats de workload in een container. App Service ondersteunt containerisatie, maar in dit voorbeeld wordt de workload niet in een container geplaatst. Gebruik containers om de betrouwbaarheid en draagbaarheid te verhogen.
Zie Overwegingen voor het toepassingsplatform voor bedrijfskritieke workloads in Azure voor meer informatie.
Het toepassingsplatform kiezen
Het beschikbaarheidsniveau is afhankelijk van uw keuze en configuratie van het toepassingsplatform. Houd rekening met de volgende bedrijfskritieke richtlijnen:
- Gebruik waar mogelijk beschikbaarheidszones.
- Selecteer de juiste platformservice voor uw workload.
- Plaats de workload in een container.
Beschikbaarheidssets verspreiden implementaties over meerdere fout- en updatedomeinen binnen een datacenter. Beschikbaarheidszones verspreiden implementaties over afzonderlijke datacenters binnen een Azure-regio. Beschikbaarheidszones krijgen vaak prioriteit, maar welke strategie u gebruikt, is afhankelijk van uw workload. Latentiegevoelige of chatty-workloads kunnen bijvoorbeeld baat hebben bij het prioriteren van beschikbaarheidssets. Als u de workload verspreidt over beschikbaarheidszones, kunnen de latentie en kosten voor verkeer in meerdere zones toenemen. Wanneer u beschikbaarheidszones gebruikt, moet u ervoor zorgen dat alle services in een schaaleenheid deze ondersteunen. Alle services in het betrouwbare web-app-patroon ondersteunen beschikbaarheidszones.
Het gegevensplatform kiezen
Het databaseplatform dat u kiest, is van invloed op de algehele workloadarchitectuur, met name de actief-actief- of actief-passieve configuratieondersteuning van het platform. Het betrouwbare web-app-patroon maakt gebruik van Azure SQL, dat geen systeemeigen ondersteuning biedt voor actief-actieve implementaties met schrijfbewerkingen in meer dan één exemplaar. Het databaseniveau is dus beperkt tot een actief-passieve strategie. Een actief-actief strategie op toepassingsniveau is mogelijk als er alleen-lezen replica's zijn en u alleen naar één regio schrijft.
Een Visio-bestand van deze architectuur downloaden.
Meerdere databases zijn gebruikelijk in complexe architecturen, zoals microservicesarchitecturen met een database voor elke service. Meerdere databases maken het mogelijk om een multi-primaire schrijfdatabase zoals Azure Cosmos DB te gebruiken, waardoor hoge beschikbaarheid en lage latentie worden verbeterd. Latentie tussen regio's kan beperkingen veroorzaken. Het is van cruciaal belang om rekening te houden met niet-functionele vereisten en factoren, zoals consistentie, operabiliteit, kosten en complexiteit. Stel afzonderlijke services in staat om afzonderlijke gegevensarchieven en gespecialiseerde gegevenstechnologieën te gebruiken om te voldoen aan hun unieke vereisten. Zie Overwegingen voor gegevensplatformen voor bedrijfskritieke workloads in Azure voor meer informatie.
Een statusmodel definiëren
In complexe workloads met meerdere lagen die verspreid zijn over meerdere datacenters en geografische regio's, moet u een statusmodel definiëren. Definieer gebruikers- en systeemstromen, geef de afhankelijkheden tussen de services op en begrijp deze, begrijp het effect dat storingen of prestatievermindering op een van de services kunnen hebben op de algehele workload, en bewaak en visualiseer de klantervaring om de juiste bewaking en verbetering van handmatige en geautomatiseerde acties mogelijk te maken.
In het vorige diagram ziet u hoe een storing of een degradatie van één onderdeel, zoals App Configuration, kan leiden tot mogelijke prestatievermindering voor de klant.
Wanneer u onderdelen in schaaleenheden scheidt, kunt u stoppen met het verzenden van verkeer naar het betrokken deel van de toepassing, zoals een betrokken schaaleenheid of de volledige regio.
Zie Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure voor meer informatie.
Beveiliging en netwerken
Er zijn strikte netwerk- en beveiligingsvereisten voor workloads die worden gemigreerd vanuit een on-premises bedrijfsimplementatie. Niet alle gevestigde on-premises processen worden omgezet in een cloudomgeving. Evalueer deze vereisten als ze van toepassing zijn in cloudomgevingen.
Identiteit is vaak de primaire beveiligingsperimeter voor cloudeigen patronen. Enterprise-klanten hebben mogelijk meer aanzienlijke beveiligingsmaatregelen nodig. Om te voldoen aan hun netwerkbeveiligingsvereisten, kunnen de meeste Azure PaaS-services Azure Private Link gebruiken om het netwerk te implementeren als een beveiligingsperimeter. Private Link kan ervoor zorgen dat services alleen toegankelijk zijn vanuit een virtueel netwerk. Alle services zijn alleen toegankelijk via privé-eindpunten. In het volgende diagram ziet u hoe het enige openbare internetgerichte eindpunt Azure Front Door is.
Een Visio-bestand van deze architectuur downloaden.
Voor het betrouwbare web-app-patroon voor het instellen van een netwerk als een beveiligingsperimeter moet het volgende worden gebruikt:
- Private Link voor alle services die deze ondersteunen.
- Azure Front Door Premium als het enige openbare eindpunt op internet.
- Jumpboxes voor toegang tot services via Azure Bastion.
- Zelf-hostende buildagents die toegang hebben tot de services.
Een andere algemene netwerkvereiste voor bedrijfskritieke toepassingen is het beperken van uitgaand verkeer om gegevensexfiltratie te voorkomen. Beperk uitgaand verkeer door een Azure-firewall te routeren via een correct firewallapparaat en het te filteren met het apparaat. De bedrijfskritieke basislijnarchitectuur van Azure met netwerkbesturingselementen maakt gebruik van een firewall en Private Link.
Implementatie en testen
Downtime veroorzaakt door onjuiste releases of menselijke fouten kan een probleem zijn voor een workload die altijd beschikbaar moet zijn. Hier volgen enkele belangrijke gebieden die u moet overwegen:
- Implementaties zonder downtime
- Kortstondige blauw/groene implementaties
- De levenscyclus van afzonderlijke onderdelen analyseren en groeperen
- Continue validatie
Implementaties zonder downtime zijn essentieel voor bedrijfskritieke workloads. Een workload die altijd actief moet zijn, kan geen onderhoudsvenster hebben om nieuwere versies uit te rollen. Om deze beperking te omzeilen, volgt de bedrijfskritieke Architectuur van Azure het patroon implementaties zonder downtime. Wijzigingen worden uitgerold als nieuwe schaaleenheden of stempels die end-to-end zijn getest voordat het verkeer stapsgewijs naar hen wordt gerouteerd. Nadat al het verkeer naar de nieuwe stempel is gerouteerd, worden oude stempels uitgeschakeld en verwijderd.
Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie.
Volgende stappen
- Leertraject: Bedrijfskritieke workloads bouwen in Azure
- Uitdagingsproject: Een bedrijfskritieke webtoepassing ontwerpen
- Learn-module: Een statusmodel ontwerpen voor uw bedrijfskritieke workload