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 platform as a service-services (PaaS) wilt gebruiken.
reliable web-app-patroon voor .NET- bevat richtlijnen voor het bijwerken of opnieuwplatformen van web-apps die u naar de cloud verplaatst. Deze aanpak helpt u bij 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 bedrijfskritieke ontwerpprocedures kunt introduceren en implementeren.
Notitie
De richtlijnen in dit artikel zijn gebaseerd op de ontwerpmethodologie en best practices in de Well-Architected Framework-essentiële workload reeks.
In de volgende secties wordt beschreven hoe u:
- Bekijk een 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 de 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 zich voor te bereiden op potentiële regionale storingen.
- Koppel onderdelen los en implementeer een gebeurtenisgestuurde architectuur.
Architectuur
In het volgende diagram worden de vorige overwegingen toegepast op het betrouwbare web-app-patroon.
Download een Visio-bestand van deze architectuur.
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 dient, correleert bijvoorbeeld met 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 op elkaar en communiceren alleen met gedeelde services buiten de afzonderlijke schaaleenheid. U kunt deze schaaleenheden gebruiken in een blauwgroene implementatie door nieuwe schaaleenheden uit te rollen, te valideren dat ze correct werken en geleidelijk productieverkeer naar deze eenheden te verplaatsen.
In dit scenario beschouwen we schaaleenheden als tijdelijk, waardoor de implementatieprocessen worden geoptimaliseerd en schaalbaarheid binnen en tussen regio's wordt geboden. Wanneer u deze aanpak uitvoert, moet u alleen gegevens opslaan in de database omdat de database wordt gerepliceerd naar de secundaire regio. Als u gegevens in de schaaleenheid wilt opslaan, kunt u Overwegen Om Azure Cache voor Redis te gebruiken voor opslag in de schaaleenheid. Als een schaaleenheid moet worden verlaten, kan het opnieuw vullen van de cache de latentie verhogen, maar dit veroorzaakt geen storingen.
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 voor elke regio.
Zie Toepassingsontwerp van bedrijfskritieke workloads in Azurevoor meer informatie.
Onderdelen
Deze architectuur maakt gebruik van de volgende onderdelen.
- App Service- is het platform voor toepassingshosting.
- Azure Cache voor Redis aanvragen in de cache opgeslagen.
- App Configuration- configuratie-instellingen opslaat.
- Azure SQL- is de back-enddatabase.
- Application Insights- telemetrie van de toepassing ophaalt.
Alternatieven
In het betrouwbare web-app-patroon kunt u het volgende doen:
- Azure Kubernetes Service (AKS) gebruiken 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 Azurevoor meer informatie.
Overwegingen voor hoge beschikbaarheid
Ongeacht het toepassingsplatform dat u kiest, raden we u aan prioriteit te geven aan het gebruik van beschikbaarheidszones voor productieworkloads.
beschikbaarheidssets implementaties verspreid over meerdere fout- en updatedomeinen binnen een datacenter. beschikbaarheidszones implementaties verspreid 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. In deze configuratie is het gegevensplatform beperkt tot een actief-passieve strategie. Een (gedeeltelijke) actief-actieve strategie op toepassingsniveau is mogelijk als er alleen-lezen replica's in alle regio's zijn en u alleen naar één regio schrijft.
Meerdere databases zijn gebruikelijk in complexe architecturen, zoals microservicesarchitecturen met een database voor elke service. Met meerdere databases kan een database met meerdere primaire schrijfbewerkingen, zoals Azure Cosmos DB, worden geïmplementeerd, 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 gegevensplatform voor bedrijfskritieke workloads in Azurevoor 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.
Een statusmodel definiëren:
- Gebruikers- en systeemstromen definiëren
- De afhankelijkheden tussen de services opgeven en begrijpen
- Inzicht krijgen in het effect dat storingen of een prestatievermindering op een van de services kunnen hebben op de algehele workload
- Bewaak en visualiseer de klantervaring om de juiste bewaking in te schakelen en handmatige en geautomatiseerde acties te verbeteren.
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.
De criteria voor het bepalen van de status van een schaaleenheid worden gedefinieerd in het statusmodel. Dit model wordt vervolgens verbonden met het statuseindpunt van de schaaleenheid, waarmee de globale load balancer de status van een schaaleenheid kan opvragen en die informatie kan gebruiken voor routeringsbeslissingen.
Zie Health modeling en waarneembaarheid van bedrijfskritieke workloads in Azurevoor meer informatie.
Beveiliging en netwerken
Bedrijfskritieke workloads hebben strikte netwerk- en beveiligingsvereisten. Pas zorgvuldigheid toe op workloads die zijn gemigreerd vanuit een on-premises omgeving, omdat niet alle gevestigde on-premises beveiligingsprocedures worden omgezet in een cloudomgeving. Het is raadzaam om tijdens de migratie van de toepassing beveiligingsvereisten opnieuw te beoordelen.
Identiteit is vaak de primaire beveiligingsperimeter voor cloudeigen patronen. Enterprise-klanten hebben mogelijk meer aanzienlijke beveiligingsmaatregelen nodig. Azure PaaS-services kunnen Azure Private Link gebruiken om het netwerk te implementeren als een beveiligingsperimeter om aan hun netwerkbeveiligingsvereisten te voldoen. Private Link zorgt ervoor dat services alleen toegankelijk zijn vanuit een virtueel netwerk. Alle services zijn vervolgens alleen toegankelijk via privé-eindpunten. In het volgende diagram ziet u hoe het enige openbare internetgerichte eindpunt Azure Front Door is.
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.
- Jumpboxen 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. Filter vervolgens verkeer met behulp van het apparaat. De bedrijfskritieke basislijnarchitectuur van Azure met netwerkbesturingselementen maakt gebruik van een firewall en Private Link.
Implementatie en testen
Downtime die wordt 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 blauwgroene implementaties
- Levenscyclusanalyse van afzonderlijke en gegroepeerde onderdelen
- Continue validatie
implementaties zonder downtime essentieel zijn 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 doorgestuurd, worden de oude stempels uitgeschakeld en verwijderd.
Zie Implementatie en testen voor bedrijfskritieke workloads in Azurevoor meer informatie.
Volgende stappen
- leertraject: Bedrijfskritieke workloads bouwen in Azure
- Uitdagingsproject: een bedrijfskritieke webtoepassing ontwerpen
- Learn-module: Een statusmodel ontwerpen voor uw bedrijfskritieke workload