Betrouwbaar web-app-patroon voor .NET : het patroon toepassen

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

In dit artikel leest u hoe u het patroon Reliable Web App toepast. Het patroon Reliable Web App is een set principes en implementatietechnieken waarmee wordt gedefinieerd hoe u web-apps (opnieuw platformen) moet wijzigen bij het migreren naar de cloud. Het richt zich op de minimale code-updates die u moet uitvoeren om succesvol te zijn in de cloud.

Om de toepassing van deze richtlijnen te vergemakkelijken, is er een referentie-implementatie van het Reliable Web App-patroon dat u kunt implementeren.

Architectuur van de referentie-implementatie. Download een Visio-bestand van deze architectuur.

In de volgende richtlijnen wordt de referentie-implementatie als voorbeeld gebruikt. Als u het patroon Reliable Web App wilt toepassen, volgt u deze aanbevelingen die zijn afgestemd op de pijlers van het Well-Architected Framework:

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. Het patroon Reliable Web App introduceert twee belangrijke ontwerppatronen op codeniveau om de betrouwbaarheid te verbeteren: het patroon Opnieuw proberen en het patroon Circuitonderbreker.

Het patroon Opnieuw proberen gebruiken

Het patroon Voor opnieuw proberen behandelt tijdelijke serviceonderbrekingen, tijdelijke fouten, die meestal binnen enkele seconden worden opgelost. Deze fouten zijn vaak het gevolg van servicebeperking, dynamische belastingdistributie en netwerkproblemen in cloudomgevingen. Het implementeren van het patroon Opnieuw proberen omvat het opnieuw verzenden van mislukte aanvragen, waardoor configureerbare vertragingen en pogingen mogelijk zijn voordat de fout wordt toegestaan.

Toepassingen die gebruikmaken van het patroon Voor opnieuw proberen moeten de SDK's (Client Software Development Kits) van Azure en servicespecifieke mechanismen voor opnieuw proberen integreren voor verbeterde efficiëntie. Toepassingen die dit patroon missen, moeten het gebruiken met behulp van de volgende richtlijnen.

Probeer eerst de Azure-service- en client-SDK's

De meeste Azure-services en client-SDK's hebben een ingebouwd mechanisme voor opnieuw proberen. U moet het ingebouwde mechanisme voor opnieuw proberen voor Azure-services gebruiken om de implementatie te versnellen.

Voorbeeld: De referentie-implementatie maakt gebruik van de verbindingstolerantie in Entity Framework Core om het patroon Opnieuw proberen toe te passen in aanvragen in Azure SQL Database (zie de volgende code).

services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));

De Polly-bibliotheek gebruiken wanneer de clientbibliotheek geen ondersteuning biedt voor nieuwe pogingen

Mogelijk moet u aanroepen uitvoeren naar een afhankelijkheid die geen Azure-service is of het patroon Opnieuw proberen niet systeemeigen ondersteunt. In dat geval moet u de Polly-bibliotheek gebruiken om het patroon Opnieuw proberen te implementeren. Polly is een .NET-tolerantie- en tijdelijke foutafhandelingsbibliotheek. Hiermee kunt u fluent-API's gebruiken om gedrag op een centrale locatie van de toepassing te beschrijven.

Voorbeeld: De referentie-implementatie maakt gebruik van Polly om de ASP.NET Core-afhankelijkheidsinjectie in te stellen. Polly dwingt het patroon Opnieuw proberen af telkens wanneer de code een object maakt dat het IConcertSearchService object aanroept. In het Polly-framework wordt dat gedrag een beleid genoemd. De code extraheert dit beleid in de GetRetryPolicy methode en de GetRetryPolicy methode past het patroon Opnieuw proberen toe telkens wanneer de front-endweb-app web-API concertzoekservices aanroept (zie de volgende code).

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

De beleidshandler voor het RelecloudApiConcertSearchService exemplaar past het patroon Opnieuw proberen toe op alle aanvragen naar de API. Er wordt gebruikgemaakt van de logica voor het HandleTransientHttpError detecteren van HTTP-aanvragen die veilig opnieuw kunnen worden geprobeerd en vervolgens om de aanvraag opnieuw uit te voeren op basis van de configuratie. Het omvat enige willekeurigheid om potentiële bursts in het verkeer naar de API te vereffenen als er een fout optreedt.

Het circuitonderbrekerpatroon gebruiken

Als u de patronen voor opnieuw proberen en circuitonderbreker koppelt, wordt de mogelijkheid van een toepassing uitgebreid om serviceonderbrekingen af te handelen die niet zijn gerelateerd aan tijdelijke fouten. Het circuitonderbrekerpatroon voorkomt dat een toepassing continu toegang probeert te krijgen tot een service die niet reageert. Het circuitonderbrekerpatroon publiceert de toepassing en voorkomt cpu-cycli, zodat de toepassing de prestatie-integriteit voor eindgebruikers behoudt.

Voorbeeld: De referentie-implementatie voegt het circuitonderbrekerpatroon toe in de GetCircuitBreakerPolicy methode (zie de volgende code).

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

In de code past de beleidshandler voor het RelecloudApiConcertSearchService exemplaar het circuitonderbrekerpatroon toe op alle aanvragen voor de API. De logica wordt gebruikt HandleTransientHttpError om HTTP-aanvragen te detecteren die veilig opnieuw kunnen worden geprobeerd, maar beperkt het aantal cumulatieve fouten gedurende een opgegeven periode.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie. Het patroon Reliable Web App maakt gebruik van beheerde identiteiten om identiteitsgerichte beveiliging te implementeren. Privé-eindpunten, webtoepassingsfirewall en beperkte toegang tot de web-app bieden een veilig inkomend verkeer.

Minimale bevoegdheden afdwingen

Om beveiliging en efficiëntie te garanderen, verleent u alleen gebruikers (gebruikersidentiteiten) en Azure-services (workloadidentiteiten) de machtigingen die ze nodig hebben.

Machtigingen toewijzen aan gebruikersidentiteiten

Evalueer de behoeften van uw toepassing om een set rollen te definiëren die betrekking hebben op alle gebruikersacties zonder overlapping. Wijs elke gebruiker toe aan de meest geschikte rol. Zorg ervoor dat ze alleen toegang krijgen tot wat nodig is voor hun taken.

Machtigingen toewijzen aan workloadidentiteiten

Alleen de machtigingen verlenen die essentieel zijn voor de bewerkingen, zoals CRUD-acties in databases of toegang tot geheimen. Machtigingen voor workloadidentiteit zijn permanent, zodat u geen Just-In-Time- of Korte-termijnmachtigingen kunt opgeven voor workloadidentiteiten.

Voorkeur voor op rollen gebaseerd toegangsbeheer (RBAC). Begin altijd met Azure RBAC om machtigingen toe te wijzen. Het biedt nauwkeurige controle en zorgt ervoor dat de toegang zowel controleerbaar als gedetailleerd is. Gebruik Azure RBAC om alleen de machtigingen te verlenen die nodig zijn voor de service om de beoogde functies uit te voeren.
Aanvulling op toegangsbeheer op azure-serviceniveau. Als Azure RBAC geen specifiek scenario omvat, moet u een aanvulling op het toegangsbeleid op Azure-serviceniveau instellen.

Gebruikersverificatie en -autorisatie configureren

Verificatie en autorisatie zijn essentiële aspecten van beveiliging van webtoepassingen. Verificatie is het proces van het verifiëren van de identiteit van een gebruiker. Autorisatie geeft aan welke acties een gebruiker mag uitvoeren in de toepassing. Het doel is om verificatie en autorisatie te implementeren zonder uw beveiligingspostuur te verzwakken. Als u dit doel wilt bereiken, moet u de functies van het Azure-toepassingsplatform (Azure-app Service) en id-provider (Microsoft Entra ID) gebruiken.

Gebruikersverificatie configureren

Beveilig uw web-app door gebruikersverificatie in te schakelen via de functies van uw platform. Azure-app Service ondersteunt verificatie met id-providers zoals Microsoft Entra ID, waarbij de verificatieworkload uit uw code wordt offloaden.

Serviceverificatie en autorisatie configureren

Configureer serviceverificatie en autorisatie zodat de services in uw omgeving over de machtigingen beschikken om de benodigde functies uit te voeren. Gebruik beheerde identiteiten in Microsoft Entra ID om het maken en beheren van service-identiteiten te automatiseren, waardoor handmatig referentiebeheer wordt geëlimineerd. Met een beheerde identiteit kan uw web-app veilig toegang krijgen tot Azure-services, zoals Azure Key Vault en databases. Het vereenvoudigt ook CI/CD-pijplijnintegraties voor implementaties naar Azure-app Service. In scenario's zoals hybride implementaties of met verouderde systemen kunt u echter uw on-premises verificatieoplossingen blijven gebruiken om de migratie te vereenvoudigen. Overgang naar beheerde identiteiten wanneer uw systeem klaar is voor een moderne benadering voor identiteitsbeheer. Zie Beheerde identiteiten bewaken voor meer informatie.

DefaultAzureCredential gebruiken om code in te stellen

Gebruik DefaultAzureCredential dit om referenties op te geven voor lokale ontwikkeling en beheerde identiteiten in de cloud. DefaultAzureCredential genereert een TokenCredential voor OAuth-tokenverwerving. Het verwerkt de meeste Azure SDK-scenario's en Microsoft-clientbibliotheken. Het detecteert de omgeving van de toepassing om de juiste identiteit te gebruiken en vraagt zo nodig toegangstokens aan. DefaultAzureCredential stroomlijnt verificatie voor door Azure geïmplementeerde toepassingen Voor meer informatie raadpleegt u DefaultAzureCredential.

Voorbeeld: De referentie-implementatie gebruikt de klasse tijdens het DefaultAzureCredential opstarten om het gebruik van beheerde identiteit tussen de web-API en Key Vault in te schakelen (zie de volgende code).

builder.Configuration.AddAzureAppConfiguration(options =>
{
     options
        .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
        .ConfigureKeyVault(kv =>
        {
            // Some of the values coming from Azure App Configuration are stored Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Infrastructuur als code gebruiken om beheerde identiteiten te maken

U moet Bicep-sjablonen gebruiken om de Azure-infrastructuur te maken en te configureren ter ondersteuning van beheerde identiteiten. Beheerde identiteiten gebruiken geen geheimen of wachtwoorden, dus u hebt Key Vault of een strategie voor geheimrotatie niet nodig om de integriteit te garanderen. U kunt de verbindingsreeks s opslaan in de App Configuration Service.

Voorbeeld: De referentie-implementatie maakt gebruik van Bicep-sjablonen om (1) de beheerde identiteit te maken, (2) koppelt de identiteit aan de web-app en (3) verleent de identiteit toestemming voor toegang tot de SQL-database. Het Authentication argument in de verbindingsreeks vertelt de Microsoft-clientbibliotheek om verbinding te maken met een beheerde identiteit (zie de volgende code).

    Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default

Zie Verbinding maken met SQL-database vanuit .NET App Service voor meer informatie.

Een centraal geheimenarchief gebruiken om geheimen te beheren

Wanneer u uw toepassing naar de cloud verplaatst, gebruikt u Azure Key Vault om al deze geheimen veilig op te slaan. Deze gecentraliseerde opslagplaats biedt beveiligde opslag, sleutelrotatie, toegangscontrole en bewaking voor services die geen beheerde identiteiten ondersteunen. Voor toepassingsconfiguraties wordt Azure-app Configuratie aanbevolen.

Voorbeeld: In de referentie-implementatie worden de volgende geheimen opgeslagen in Key Vault: (1) Gebruikersnaam en wachtwoord van PostgreSQL-database, (2) Redis Cache-wachtwoord en (3) het clientgeheim voor Microsoft Entra-id die is gekoppeld aan de implementatie van Microsoft Authentication Library (MSAL).

Plaats Key Vault niet in de HTTP-aanvraagstroom

Laad geheimen uit Key Vault bij het opstarten van de toepassing in plaats van tijdens elke HTTP-aanvraag. Key Vault is bedoeld voor het veilig opslaan en ophalen van gevoelige gegevens tijdens de implementatie. Toegang met hoge frequentie binnen HTTP-aanvragen kan de doorvoermogelijkheden van Key Vault overschrijden, wat leidt tot aanvraagbeperkingen en HTTP-statuscode 429-fouten. Zie Key Vault-transactielimieten voor meer informatie.

Eén methode gebruiken voor toegang tot geheimen in Key Vault

Wanneer u een web-app configureert voor toegang tot geheimen in Key Vault, hebt u twee primaire opties:

App Service-app-instelling: gebruik een app-instelling in App Service om het geheim rechtstreeks als een omgevingsvariabele te injecteren.
Directe geheime verwijzing: rechtstreeks verwijzen naar het geheim in uw toepassingscode. Voeg een specifieke verwijzing toe in het eigenschappenbestand van uw toepassing, zoals application.properties voor Java-toepassingen, zodat uw app kan communiceren met Key Vault.

Het is belangrijk om een van deze methoden te kiezen en dit zo eenvoudig mogelijk te houden en onnodige complexiteit te voorkomen.

Voorkeur geven aan tijdelijke toegangsmethoden

Gebruik tijdelijke machtigingen om te beschermen tegen onbevoegde toegang en schendingen. Handtekeningen voor gedeelde toegang (SASs) gebruiken voor tijdelijke toegang. Gebruik SAS voor gebruikersdelegering om de beveiliging te maximaliseren bij het verlenen van tijdelijke toegang. Het is de enige SAS die gebruikmaakt van Microsoft Entra-referenties en waarvoor geen opslagaccountsleutel is vereist.

Privé-eindpunten gebruiken

Gebruik privé-eindpunten in alle productieomgevingen voor alle ondersteunde Azure-services. Privé-eindpunten bieden privéverbindingen tussen resources in een virtueel Azure-netwerk en Azure-services. Standaard overschrijdt communicatie met de meeste Azure-services het openbare internet. Voor privé-eindpunten zijn geen codewijzigingen, app-configuraties of verbindingsreeks s vereist. Zie Een privé-eindpunt en aanbevolen procedures voor eindpuntbeveiliging maken voor meer informatie.

Voorbeeld: Azure-app Configuratie, Azure SQL Database, Azure Cache voor Redis, Azure Storage, Azure-app Service en Key Vault gebruiken een privé-eindpunt.

Web Application Firewall gebruiken en binnenkomend internetverkeer beperken

Al het inkomende internetverkeer naar de web-app moet via een webtoepassingsfirewall worden doorgegeven om bescherming te bieden tegen veelvoorkomende webexplots. Dwing al het binnenkomende internetverkeer af om via de openbare load balancer te gaan, als u er een hebt en de firewall van de webtoepassing.

Voorbeeld: De referentie-implementatie dwingt al het binnenkomende internetverkeer via Front Door en Azure Web Application Firewall af. Behoud in productie de oorspronkelijke HTTP-hostnaam.

Databasebeveiliging configureren

Toegang op beheerdersniveau tot de database verleent machtigingen om bevoegde bewerkingen uit te voeren. Uitgebreide bewerkingen omvatten het maken en verwijderen van databases, het wijzigen van tabelschema's of het wijzigen van gebruikersmachtigingen. Ontwikkelaars hebben vaak toegang op beheerdersniveau nodig om de database te onderhouden of om problemen op te lossen.

Vermijd permanente verhoogde machtigingen. U moet de ontwikkelaars alleen Just-In-Time-toegang verlenen om bevoegde bewerkingen uit te voeren. Met Just-In-Time-toegang krijgen gebruikers tijdelijke machtigingen om bevoegde taken uit te voeren
Geef de toepassing geen verhoogde machtigingen. U moet geen toegang op beheerdersniveau verlenen tot de toepassingsidentiteit. U moet de toegang met minimale bevoegdheden configureren voor de toepassing naar de database. Het beperkt de straal van bugs en beveiligingsschendingen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige kosten en beheeroverhead te verminderen. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie. Het patroon Betrouwbare web-app implementeert rechtentechnieken, automatisch schalen en efficiënt resourcegebruik voor een meer kosten geoptimaliseerde web-app.

Resources voor elke omgeving rechten toewijzen

Krijg inzicht in de verschillende prestatielagen van Azure-services en gebruik alleen de juiste SKU voor de behoeften van elke omgeving. Productieomgevingen hebben SKU's nodig die voldoen aan de SLA(Service Level Agreements), functies en schaal die nodig zijn voor productie. Niet-productieomgevingen hebben doorgaans niet dezelfde mogelijkheden nodig. Voor extra besparingen kunt u azure Dev/Test-prijsopties, Azure-reserveringen en Azure-besparingsplannen voor rekenkracht overwegen.

Voorbeeld: De referentie-implementatie maakt gebruik van Bicep-parameters om configuraties voor resource-implementatie te activeren. Een van deze parameters geeft de resourcelagen (SKU's) aan die moeten worden geïmplementeerd. De web-app maakt gebruik van de krachtigere en dure SKU's voor de productieomgevingen en de goedkopere SKU's voor de niet-productieomgeving (zie de volgende code).

var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
var redisCacheFamilyName = isProd ? 'C' : 'C'
var redisCacheCapacity = isProd ? 1 : 0

Automatisch schalen gebruiken

Automatisch schalen automatiseert horizontaal schalen voor productieomgevingen. Automatisch schalen op basis van metrische prestatiegegevens. Prestatietriggers voor CPU-gebruik zijn een goed uitgangspunt als u de schaalcriteria van uw toepassing niet begrijpt. U moet schaaltriggers (CPU, RAM, netwerk en schijf) configureren en aanpassen zodat deze overeenkomen met het gedrag van uw webtoepassing. Schaal niet verticaal om te voldoen aan frequente veranderingen in de vraag. Het is minder kostenefficiënt. Zie Schalen in Azure-app Service en Automatisch schalen in Microsoft Azure voor meer informatie.

Voorbeeld: De referentie-implementatie maakt gebruik van de volgende configuratie in de Bicep-sjabloon. Er wordt een regel voor automatisch schalen gemaakt voor de Azure-app Service. De regel schaalt maximaal 10 exemplaren en wordt standaard ingesteld op één exemplaar. Het gebruikt CPU-gebruik als trigger voor in- en uitschalen. Het hostingplatform van de web-app schaalt uit op 85% CPU-gebruik en schaalt in op 60%. De uitschaalinstelling van 85%, in plaats van een percentage dichter bij 100%, biedt een buffer om te beschermen tegen verzameld gebruikersverkeer dat wordt veroorzaakt door plaksessies. Het beschermt ook tegen hoge pieken van verkeer door vroeg te schalen om maximaal CPU-gebruik te voorkomen. Deze regels voor automatisch schalen zijn niet universeel (zie de volgende code).

resource autoScaleRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = if (autoScaleSettings != null) { 
  name: '${name}-autoscale' 
  location: location 
  tags: tags 
  properties: { 
    targetResourceUri: appServicePlan.id 
    enabled: true 
    profiles: [ 
      { 
        name: 'Auto created scale condition' 
        capacity: { 
          minimum: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
          maximum: string(autoScaleSettings!.maxCapacity) 
          default: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
        } 
        rules: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Resources efficiënt gebruiken

Gedeelde services gebruiken. Het centraliseren en delen van bepaalde resources biedt kostenoptimalisatie en lagere beheeroverhead. Plaats gedeelde netwerkbronnen in het virtuele hubnetwerk.

Voorbeeld: De referentie-implementatie plaatst Azure Firewall, Azure Bastion en Key Vault in het virtuele hubnetwerk.
Verwijder ongebruikte omgevingen. Verwijder niet-productieomgevingen na uren of tijdens feestdagen om de kosten te optimaliseren. U kunt infrastructuur als code gebruiken om Azure-resources en volledige omgevingen te verwijderen. Verwijder de declaratie van de resource die u wilt verwijderen uit de Bicep-sjabloon. Gebruik de wat-als-bewerking om een voorbeeld van de wijzigingen te bekijken voordat deze van kracht worden. Maak een back-up van de gegevens die u later nodig hebt. Inzicht in de afhankelijkheden van de resource die u verwijdert. Als er afhankelijkheden zijn, moet u deze resources mogelijk ook bijwerken of verwijderen. Zie de what-if-bewerking van Bicep-implementatie voor meer informatie.
Colocate-functionaliteit. Als er reservecapaciteit is, kunt u toepassingsresources en -functionaliteit op één Azure-resource plaatsen. Meerdere web-apps kunnen bijvoorbeeld gebruikmaken van één server (App Service-plan) of één cache kan meerdere gegevenstypen ondersteunen.

Voorbeeld: De referentie-implementatie maakt gebruik van één Azure Cache voor Redis exemplaar voor sessiebeheer in zowel front-end -tokens (opslaan van winkelwagen als MSAL-tokens) en back-end -apps (met gegevens over geplande concerten). Het kiest voor de kleinste Redis-SKU, die meer dan de benodigde capaciteit biedt, efficiënt wordt gebruikt door meerdere gegevenstypen te gebruiken om de kosten te beheren.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie. Het patroon Reliable Web App implementeert infrastructuur als code voor infrastructuurimplementaties en bewaking voor waarneembaarheid.

Implementatie automatiseren

Gebruik een CI/CD-pijplijn om wijzigingen van broncodebeheer naar productie te implementeren. Als u Azure DevOps gebruikt, moet u Azure Pipelines gebruiken. Als u GitHub gebruikt, gebruikt u GitHub Actions. ondersteuning voor Azure s ARM-sjabloon (JSON), Bicep en Terraform en bevat sjablonen voor elke Azure-resource voor meer informatie Bicep-, Azure Resource Manager- en Terraform-sjablonen en herhaalbare infrastructuur.

Voorbeeld: De referentie-implementatie maakt gebruik van Azure Dev CLI en infrastructuur als code (Bicep-sjablonen) om Azure-resources te maken, configuratie in te stellen en de vereiste resources te implementeren.

Bewaking configureren

Als u uw web-app wilt bewaken, verzamelt en analyseert u metrische gegevens en logboeken van uw toepassingscode, infrastructuur (runtime) en het platform (Azure-resources). Voeg een diagnostische instelling toe voor elke Azure-resource in uw architectuur. Elke Azure-service heeft een andere set logboeken en metrische gegevens die u kunt vastleggen. Zie Het platform bewaken en App Service bewaken voor meer informatie.

Metrische basislijngegevens bewaken

Gebruik Azure-toepassing Insights om metrische basislijngegevens bij te houden, zoals aanvraagdoorvoer, gemiddelde aanvraagduur, fouten en afhankelijkheidsbewaking. Gebruik AddApplicationInsightsTelemetry dit vanuit het NuGet-pakket Microsoft.ApplicationInsights.AspNetCore om telemetrieverzameling in te schakelen. Zie Application Insights-telemetrie en afhankelijkheidsinjectie inschakelen in .NET voor meer informatie.

Voorbeeld: De referentie-implementatie maakt gebruik van code voor het configureren van metrische basislijngegevens in Application Insights (zie de volgende code).

public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}

Aangepaste telemetrie maken indien nodig

Gebruik Application Insights om aangepaste telemetrie te verzamelen om uw web-app-gebruikers beter te begrijpen. Maak een exemplaar van de TelemetryClient klasse en gebruik de TelemetryClient methoden om de juiste metrische gegevens te maken. Zet de query om in een Azure Dashboard-widget.

Voorbeeld: Met de referentie-implementatie worden metrische gegevens toegevoegd waarmee het operations-team kan vaststellen dat de web-app transacties met succes voltooit. Hiermee wordt gevalideerd dat de web-app online is door te controleren of klanten orders kunnen plaatsen, niet door het aantal aanvragen of het CPU-gebruik te meten. De referentie-implementatie maakt gebruik TelemetryClient van afhankelijkheidsinjectie en de TrackEvent methode om telemetrie te verzamelen over gebeurtenissen met betrekking tot de winkelwagenactiviteit. De telemetrie houdt de tickets bij die gebruikers toevoegen, verwijderen en kopen (zie de volgende code).

AddToCart telt hoe vaak gebruikers een bepaald ticket (ConcertID) aan de winkelwagen toevoegen.
RemoveFromCart registreert tickets die gebruikers uit de winkelwagen verwijderen.
CheckoutCart registreert een gebeurtenis telkens wanneer een gebruiker een ticket koopt.

this.telemetryClient.TrackEvent telt de tickets die aan de winkelwagen zijn toegevoegd. Hiermee wordt de gebeurtenisnaam (AddToCart) geleverd en wordt een woordenlijst opgegeven met de concertId en count (zie de volgende code).

this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});

Zie voor meer informatie:

Metrische gegevens op basis van logboeken verzamelen

Houd metrische gegevens op basis van logboeken bij om meer inzicht te krijgen in essentiële toepassingsstatus en metrische gegevens. U kunt Kusto-querytaal (KQL)-query's in Application Insights gebruiken om gegevens te zoeken en te ordenen. Zie voor meer informatie Azure-toepassing metrische gegevens op basis van logboeken en logboeken en vooraf geaggregeerde metrische gegevens in Application Insights.

Platformdiagnose inschakelen

Met een diagnostische instelling in Azure kunt u de platformlogboeken en metrische gegevens opgeven die u wilt verzamelen en waar ze moeten worden opgeslagen. Platformlogboeken zijn ingebouwde logboeken die diagnostische en controlegegevens bieden. U kunt platformdiagnose inschakelen voor de meeste Azure-services, maar elke service definieert zijn eigen logboekcategorieën. Verschillende Azure-services hebben logboekcategorieën die u kunt kiezen.

Schakel diagnostische gegevens in voor alle ondersteunde services. Azure-services maken automatisch platformlogboeken, maar de service slaat ze niet automatisch op. U moet de diagnostische instelling voor elke service inschakelen en u moet deze inschakelen voor elke Azure-service die diagnostische gegevens ondersteunt.
Verzend diagnostische gegevens naar dezelfde bestemming als de toepassingslogboeken. Wanneer u diagnostische gegevens inschakelt, kiest u de logboeken die u wilt verzamelen en waar u ze wilt verzenden. U moet de platformlogboeken naar dezelfde bestemming verzenden als de toepassingslogboeken, zodat u de twee gegevenssets kunt correleren.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie. Het patroon Reliable Web App maakt gebruik van het patroon Cache-Aside om de latentie voor zeer aangevraagde gegevens te minimaliseren.

Het cache-aside-patroon gebruiken

Het cache-aside-patroon is een cachestrategie die het gegevensbeheer in het geheugen verbetert. Het patroon wijst de toepassing de verantwoordelijkheid toe voor het verwerken van gegevensaanvragen en zorgt voor consistentie tussen de cache en een permanente opslag, zoals een database. Wanneer de web-app een gegevensaanvraag ontvangt, wordt eerst in de cache gezocht. Als de gegevens ontbreken, worden deze opgehaald uit de database, gereageerd op de aanvraag en wordt de cache dienovereenkomstig bijgewerkt. Deze aanpak verkort de reactietijden en verbetert de doorvoer en vermindert de behoefte aan meer schaalaanpassing. Het versterkt ook de beschikbaarheid van de service door de belasting van het primaire gegevensarchief te verminderen en de risico's van storingen te minimaliseren.

Voorbeeld: De referentie-implementatie verbetert de efficiëntie van toepassingen door kritieke gegevens in de cache op te cachen, zoals informatie voor aanstaande concerten die cruciaal zijn voor de ticketverkoop. Het maakt gebruik van de gedistribueerde geheugencache van ASP.NET Core voor in-memory itemopslag. De toepassing gebruikt automatisch Azure Cache voor Redis wanneer er een specifieke verbindingsreeks wordt gevonden. Het biedt ook ondersteuning voor lokale ontwikkelomgevingen zonder Redis om de installatie te vereenvoudigen en kosten en complexiteit te verlagen. De methode (AddAzureCacheForRedis) configureert de toepassing voor het gebruik van Azure Cache voor Redis (zie de volgende code).

private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}

Zie gedistribueerde caching in ASP.NET Core - en AddDistributedMemoryCache-methode voor meer informatie.

Gegevens met hoge behoefte in cache opslaan

Prioriteit geven aan caching voor de meest gebruikte gegevens. Identificeer belangrijke gegevenspunten die gebruikersbetrokkenheid en systeemprestaties stimuleren. Implementeer cachestrategieën specifiek voor deze gebieden om de effectiviteit van het Cache-Aside-patroon te optimaliseren, waardoor latentie en databasebelasting aanzienlijk worden verminderd. Gebruik Azure Monitor om de CPU, het geheugen en de opslag van de database bij te houden. Met deze metrische gegevens kunt u bepalen of u een kleinere database-SKU kunt gebruiken.

Voorbeeld: De referentie-implementatie slaat de gegevens in de cache op die ondersteuning bieden voor geplande concerten. De pagina Geplande concerten maakt de meeste query's voor SQL Database en produceert een consistente uitvoer voor elk bezoek. Met het patroon Cache-Aside worden de gegevens na de eerste aanvraag voor deze pagina in de cache opgeslagen om de belasting van de database te verminderen. De volgende code gebruikt de GetUpcomingConcertsAsync methode om gegevens op te halen uit SQL Database in de Redis-cache. De methode vult de cache met de nieuwste concerten. De methode filtert op tijd, sorteert de gegevens en retourneert de gegevens naar de controller om de resultaten weer te geven (zie de volgende code).

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

Cachegegevens actueel houden

Plan regelmatige cache-updates om te synchroniseren met de meest recente databasewijzigingen. Bepaal de optimale vernieuwingsfrequentie op basis van gegevensvolatiliteit en gebruikersbehoeften. Deze procedure zorgt ervoor dat de toepassing gebruikmaakt van het cache-aside-patroon om zowel snelle toegang als huidige informatie te bieden.

Voorbeeld: Met de referentie-implementatie worden gegevens slechts één uur in de cache opgeslagen. Het heeft een proces voor het wissen van de cachesleutel wanneer de gegevens worden gewijzigd. Met CreateConcertAsync de methode wordt de cachesleutel gewist (zie de volgende code).

public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}

Gegevensconsistentie garanderen

Implementeer mechanismen voor het bijwerken van de cache direct na een schrijfbewerking van de database. Gebruik gebeurtenisgestuurde updates of toegewezen gegevensbeheerklassen om cachecoherentie te garanderen. Het consistent synchroniseren van de cache met databasewijzigingen is centraal in het cache-aside-patroon.

Voorbeeld: De referentie-implementatie maakt gebruik van de UpdateConcertAsync methode om de gegevens consistent te houden in de cache (zie de volgende code).

public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}

Databaseprestaties testen

Databaseprestaties kunnen van invloed zijn op de prestaties en schaalbaarheid van een toepassing. Het is belangrijk om de prestaties van uw database te testen om ervoor te zorgen dat deze is geoptimaliseerd. Enkele belangrijke overwegingen zijn het kiezen van de juiste cloudregio, verbindingspooling, cache-aside-patroon en het optimaliseren van query's.

Netwerkhops testen. Als u een toepassing naar de cloud verplaatst, kunt u extra netwerkhops en latentie toevoegen aan uw database. U moet testen op extra hops die in de nieuwe cloudomgeving worden geïntroduceerd.
Stel een basislijn voor de prestaties vast. U moet metrische gegevens over on-premises prestaties gebruiken als de eerste basislijn om de prestaties van toepassingen in de cloud te vergelijken.

Volgende stappen

Implementeer de referentie-implementatie door de instructies in de GitHub-opslagplaats te volgen. Gebruik de volgende bronnen voor meer informatie over .NET-toepassingen, web-apps, aanbevolen procedures voor de cloud en migratie.

.NET Framework-toepassingen upgraden

De referentie-implementatie wordt geïmplementeerd in een App Service waarop Windows wordt uitgevoerd, maar kan worden uitgevoerd op Linux. Met het App Service Windows-platform kunt u .NET Framework-web-apps verplaatsen naar Azure zonder een upgrade uit te voeren naar nieuwere frameworkversies. Zie de volgende richtlijnen voor informatie over Linux App Service-plannen of nieuwe functies en prestatieverbeteringen die zijn toegevoegd aan de nieuwste versies van .NET.

Overzicht van het overzetten van .NET Framework naar .NET. Krijg richtlijnen op basis van uw specifieke type .NET-app.
Overzicht van de .NET-upgradeassistent. Meer informatie over een consolehulpprogramma waarmee u veel taken kunt automatiseren die zijn gekoppeld aan het upgraden van .NET Framework-projecten.
Migreren van ASP.NET naar ASP.NET Core in Visual Studio. Meer informatie over een Visual Studio-extensie die u kan helpen bij incrementele migraties van web-apps.

Inleiding tot web-apps in Azure

Zie deze richtlijnen voor het implementeren van een eenvoudige .NET-webtoepassing voor een praktische inleiding tot .NET-webtoepassingen in Azure.

Best practices voor cloud

Zie voor richtlijnen voor acceptatie en architectuur van Azure:

Cloud Adoption Framework. Kan uw organisatie helpen bij het voorbereiden en uitvoeren van een strategie voor het bouwen van oplossingen in Azure.
Goed ontworpen framework. Een reeks richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren.

Zie bedrijfskritieke workloads voor toepassingen waarvoor een hogere SLO is vereist dan het patroon Reliable Web App.

Migratierichtlijnen

Met de volgende hulpprogramma's en resources kunt u on-premises resources migreren naar Azure.

Azure Migrate biedt een vereenvoudigde migratie-, moderniserings- en optimalisatieservice voor Azure die de evaluatie en migratie van web-apps, SQL Server en virtuele machines afhandelt.
Azure Database Migration Guides biedt resources voor verschillende databasetypen en verschillende hulpprogramma's die zijn ontworpen voor uw migratiescenario.
Azure-app Service-landingszoneversneller biedt richtlijnen voor het beveiligen en schalen van App Service-implementaties.
Azure Migrate-toepassings- en code-evaluatie

Delen via