Betrouwbaar web-app-patroon voor .NET

Dit artikel bevat richtlijnen voor het implementeren van het patroon Reliable Web App. In dit patroon wordt beschreven hoe u web-apps wijzigt (opnieuw platformen) voor cloudmigratie. Het biedt prescriptieve architectuur, code en configuratierichtlijnen die zijn afgestemd op de principes van het Well-Architected Framework.

Waarom het patroon Reliable Web App voor .NET?

Het patroon Reliable Web App is een set principes en implementatietechnieken waarmee wordt gedefinieerd hoe u web-apps opnieuw moet platformen wanneer u naar de cloud migreert. Het richt zich op de minimale code-updates die u moet uitvoeren om succesvol te zijn in de cloud. In de volgende richtlijnen wordt de referentie-implementatie als voorbeeld gebruikt en wordt het herplatformtraject van het fictieve bedrijf, Relecloud, gevolgd om uw reis bedrijfscontext te bieden. Voordat het patroon Reliable Web App voor .NET werd geïmplementeerd, had Relecloud een monolithische on-premises web-app voor ticketing die gebruikmaakt van het ASP.NET framework.

Het patroon Reliable Web App implementeren

Dit artikel bevat richtlijnen voor architectuur, code en configuratie voor het implementeren van het patroon Reliable Web App. Gebruik de volgende koppelingen om naar de specifieke richtlijnen te navigeren die u nodig hebt:

• Bedrijfscontext: stem deze richtlijnen af op uw bedrijfscontext en leer hoe u onmiddellijke en langetermijndoelen definieert die bepalend zijn voor het opnieuw platformeren van beslissingen.
• Richtlijnen voor architectuur: leer hoe u de juiste cloudservices selecteert en een architectuur ontwerpt die voldoet aan uw bedrijfsvereisten.
• Coderichtlijnen: Implementeer drie ontwerppatronen om de betrouwbaarheid en prestatie-efficiëntie van uw web-app in de cloud te verbeteren: Opnieuw proberen, Circuitonderbreker en Cache-Aside-patronen
• Configuratierichtlijnen: verificatie en autorisatie configureren, beheerde identiteiten, gerechtende omgevingen, infrastructuur als code en bewaking.

Zakelijke context

De eerste stap bij het opnieuw platformen van een web-app is het definiëren van uw bedrijfsdoelstellingen. U moet onmiddellijke doelen instellen, zoals serviceniveaudoelstellingen en kostenoptimalisatiedoelen, evenals toekomstige doelen voor uw webtoepassing. Deze doelstellingen zijn van invloed op uw keuze van cloudservices en de architectuur van uw webtoepassing in de cloud. Definieer een doel-SLO voor uw web-app, zoals 99,9% uptime. Bereken de samengestelde SLA voor alle services die van invloed zijn op de beschikbaarheid van uw web-app.

Relecloud heeft bijvoorbeeld een positieve verkoopprognose en verwacht een toegenomen vraag op hun web-app voor ticketing. Om aan deze vraag te voldoen, hebben ze de doelstellingen voor de webtoepassing gedefinieerd:

• Wijzigingen in code met lage kosten en hoge waarden toepassen
• Bereik een serviceniveaudoelstelling (SLO) van 99,9%
• DevOps-procedures gebruiken
• Voor kosten geoptimaliseerde omgevingen maken
• Betrouwbaarheid en beveiliging verbeteren

De on-premises infrastructuur van Relecloud was geen rendabele oplossing om deze doelen te bereiken. Daarom hebben ze besloten dat het migreren van hun webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken.

Uitleg bij architectuur

Het patroon Reliable Web App heeft enkele essentiële architecturale elementen. U hebt DNS nodig voor het beheren van eindpuntomzetting, een webtoepassingsfirewall om schadelijk HTTP-verkeer te blokkeren en een load balancer om binnenkomende gebruikersaanvragen te beveiligen en te routeren. Het toepassingsplatform fungeert als host voor uw web-app-code en roept alle back-endservices aan via privé-eindpunten in een virtueel netwerk. Een hulpprogramma voor bewaking van toepassingsprestaties legt metrische gegevens en logboeken vast om inzicht te hebben in uw web-app.

Figuur 1. Essentiële architecturale elementen van het patroon Reliable Web App.

De architectuur ontwerpen

Ontwerp uw infrastructuur ter ondersteuning van uw metrische herstelgegevens, zoals RTO (Recovery Time Objective) en RPO (Recovery Point Objective). De RTO beïnvloedt de beschikbaarheid en moet ondersteuning bieden voor uw SLO. Bepaal een beoogde herstelpunt (RPO) en configureer gegevensredundantie om te voldoen aan de RPO.

• Kies de betrouwbaarheid van de infrastructuur. Bepaal hoeveel beschikbaarheidszones en regio's u nodig hebt om te voldoen aan uw beschikbaarheidsbehoeften. Voeg beschikbaarheidszones en regio's toe totdat de samengestelde SLA voldoet aan uw SLO. Het patroon Reliable Web App ondersteunt meerdere regio's voor een actief-actief- of actief-passieve configuratie. De referentie-implementatie maakt bijvoorbeeld gebruik van een actief-passieve configuratie om te voldoen aan een SLO van 99,9%.

  Voor een web-app met meerdere regio's configureert u uw load balancer om verkeer naar de tweede regio te routeren ter ondersteuning van een actief-actief- of actief-passieve configuratie, afhankelijk van de behoeften van uw bedrijf. Voor de twee regio's zijn dezelfde services vereist, behalve één regio, een virtueel hubnetwerk waarmee de regio's worden verbonden. Gebruik een hub-and-spoke-netwerktopologie om resources, zoals een netwerkfirewall, te centraliseren en te delen. Als u virtuele machines hebt, voegt u een bastionhost toe aan het virtuele hubnetwerk om deze veilig te beheren (zie afbeelding 2).

  

  Figuur 2. Het patroon Reliable Web App met een tweede regio en een hub-and-spoke-topologie.

• Kies een netwerktopologie. Kies de juiste netwerktopologie voor uw web- en netwerkvereisten. Als u van plan bent meerdere virtuele netwerken te hebben, gebruikt u een hub- en spoke-netwerktopologie. Het biedt voordelen van kosten, beheer en beveiliging met hybride connectiviteitsopties voor on-premises en virtuele netwerken.

De juiste Azure-services kiezen

Wanneer u een web-app naar de cloud verplaatst, moet u Azure-services selecteren die voldoen aan uw zakelijke vereisten en overeenkomen met de huidige functies van de on-premises web-app. De uitlijning helpt bij het minimaliseren van de herplatformingsinspanning. Gebruik bijvoorbeeld services waarmee u dezelfde database-engine kunt behouden en bestaande middleware en frameworks kunt ondersteunen. De volgende secties bevatten richtlijnen voor het selecteren van de juiste Azure-services voor uw web-app.

Voordat de overstap naar de cloud werd uitgevoerd, was de web-app voor ticketing van Relecloud bijvoorbeeld een on-premises, monolithische, ASP.NET-app. Het werd uitgevoerd op twee virtuele machines en had een Microsoft SQL Server-database. De web-app heeft last van veelvoorkomende uitdagingen bij schaalbaarheid en functie-implementatie. Dit uitgangspunt, hun bedrijfsdoelen en SLO hebben hun servicekeuzen aangereden.

• Toepassingsplatform: gebruik Azure-app Service als uw toepassingsplatform. Relecloud koos Azure-app Service als het toepassingsplatform om de volgende redenen:

  • Sla (High Service Level Agreement): Het heeft een hoge SLA die voldoet aan de SLO van de productieomgeving van 99,9%.
  • Verminderde beheeroverhead: het is een volledig beheerde oplossing die schaalaanpassing, statuscontroles en taakverdeling afhandelt.
  • .NET-ondersteuning: het ondersteunt de versie van .NET waarin de toepassing is geschreven.
  • Containerisatiemogelijkheid: de web-app kan worden geconvergeerd in de cloud zonder containeriseren, maar het toepassingsplatform biedt ook ondersteuning voor containerisatie zonder azure-services te wijzigen.
  • Automatisch schalen: de web-app kan automatisch in- en uitschalen op basis van gebruikersverkeer en configuratie-instellingen. Het platform biedt ook ondersteuning voor omhoog of omlaag schalen om aan verschillende hostingvereisten te voldoen.

• Identiteitsbeheer: Gebruik Microsoft Entra-id als uw oplossing voor identiteits- en toegangsbeheer. Relecloud koos om de volgende redenen voor Microsoft Entra-id :

  • Verificatie en autorisatie: de toepassing moet medewerkers van het callcenter verifiëren en autoriseren.
  • Schaalbaar: deze schaalt om grotere scenario's te ondersteunen.
  • Beheer van gebruikersidentiteiten: callcentermedewerkers kunnen hun bestaande bedrijfsidentiteiten gebruiken.
  • Autorisatieprotocolondersteuning: Het ondersteunt OAuth 2.0 voor beheerde identiteiten.

• Database: Gebruik een service waarmee u dezelfde database-engine kunt behouden. Gebruik de beslissingsstructuur van het gegevensarchief. De web-app van Relecloud heeft on-premises SQL Server gebruikt. Daarom wilden ze het bestaande databaseschema, opgeslagen procedures en functies gebruiken. Er zijn verschillende SQL-producten beschikbaar in Azure, maar Relecloud koos Azure SQL Database om de volgende redenen:

  • Betrouwbaarheid: de laag algemeen gebruik biedt een hoge SLA en redundantie voor meerdere regio's. Het kan een hoge gebruikersbelasting ondersteunen.
  • Beperkte beheeroverhead: Het biedt een beheerd SQL-database-exemplaar.
  • Migratieondersteuning: het biedt ondersteuning voor databasemigratie vanaf on-premises SQL Server.
  • Consistentie met on-premises configuraties: het ondersteunt de bestaande opgeslagen procedures, functies en weergaven.
  • Tolerantie: het ondersteunt back-ups en herstel naar een bepaald tijdstip.
  • Expertise en minimale herwerkbewerking: SQL Database maakt gebruik van interne expertise en vereist minimale werkzaamheden.

• Bewaking van toepassingsprestaties: Gebruik Application Insights om telemetrie op uw toepassing te analyseren. Relecloud heeft ervoor gekozen Om de volgende redenen Application Insights te gebruiken:

  • Integratie met Azure Monitor: Het biedt de beste integratie met Azure Monitor.
  • Anomaliedetectie: Hiermee worden prestatieafwijkingen automatisch gedetecteerd.
  • Probleemoplossing: Hiermee kunt u problemen vaststellen in de actieve app.
  • Bewaking: Het verzamelt informatie over hoe gebruikers de app gebruiken en stelt u in staat om eenvoudig aangepaste gebeurtenissen bij te houden.
  • Zichtbaarheidsverschil: de on-premises oplossing heeft geen oplossing voor bewaking van toepassingsprestaties. Application Insights biedt eenvoudige integratie met het toepassingsplatform en code.

• Cache: Kies of u cache wilt toevoegen aan uw web-app-architectuur. Azure Cache voor Redis is de primaire cacheoplossing van Azure. Het is een beheerd gegevensarchief in het geheugen op basis van de Redis-software. De belasting van de web-app van Relecloud is sterk vertekend voor het bekijken van concerten en locatiedetails, en het heeft om de volgende redenen Azure Cache voor Redis toegevoegd:

  • Minder beheeroverhead: het is een volledig beheerde service.
  • Snelheid en volume: het heeft leesbewerkingen met hoge gegevensdoorvoer en lage latentie voor veelgebruikte, trage veranderende gegevens.
  • Diverse ondersteuningsmogelijkheden: het is een uniforme cachelocatie voor alle exemplaren van de web-app die moet worden gebruikt.
  • Externe gegevensopslag: de on-premises toepassingsservers hebben vm-lokale caching uitgevoerd. Met deze installatie zijn niet zeer frequente gegevens overgeslagen en kunnen gegevens niet ongeldig worden.
  • Niet-plaksessies: De sessiestatus externaliseren ondersteunt niet-plakgebonden sessies.

• Load balancer: webtoepassingen die PaaS-oplossingen gebruiken, moeten Gebruikmaken van Azure Front Door, Azure-toepassing Gateway of beide op basis van de architectuur en vereisten van web-apps. Gebruik de beslissingsstructuur van de load balancer om de juiste load balancer te kiezen. Relecloud had een load balancer van laag 7 nodig waarmee verkeer naar meerdere regio's kan worden gerouteerd. Relecloud heeft een web-app met meerdere regio's nodig om te voldoen aan de SLO van 99,9%. Relecloud koos Om de volgende redenen voor Azure Front Door :

  • Globale taakverdeling: het is een load balancer van laag 7 die verkeer kan routeren over meerdere regio's.
  • Web Application Firewall: Het integreert systeemeigen met Azure Web Application Firewall.
  • Flexibiliteit voor routering: hiermee kan het toepassingsteam inkomend verkeer configureren om toekomstige wijzigingen in de toepassing te ondersteunen.
  • Verkeersversnelling: Er wordt gebruikgemaakt van anycast om het dichtstbijzijnde Azure-aanwezigheidspunt te bereiken en de snelste route naar de web-app te vinden.
  • Aangepaste domeinen: het ondersteunt aangepaste domeinnamen met flexibele domeinvalidatie.
  • Statustests: De toepassing heeft intelligente statustestbewaking nodig. Azure Front Door gebruikt reacties van de test om de beste oorsprong te bepalen voor het routeren van clientaanvragen.
  • Ondersteuning voor bewaking: het ondersteunt ingebouwde rapporten met een alles-in-één dashboard voor zowel Front Door als beveiligingspatronen. U kunt waarschuwingen configureren die worden geïntegreerd met Azure Monitor. Hiermee kan de toepassing elke aanvraag en mislukte statustests registreren.
  • DDoS-beveiliging: het heeft ingebouwde DDoS-beveiliging op laag 3-4.
  • Netwerk voor contentlevering: Het positioneert Relecloud voor het gebruik van een netwerk voor contentlevering. Het netwerk voor contentlevering biedt siteversnelling.

• Web Application Firewall: Gebruik Azure Web Application Firewall om gecentraliseerde beveiliging te bieden tegen veelvoorkomende aanvallen en beveiligingsproblemen op internet. Relecloud heeft Azure Web Application Firewall gebruikt om de volgende redenen:

  • Wereldwijde beveiliging: Het biedt verbeterde wereldwijde web-app-beveiliging zonder dat dit ten koste gaat van de prestaties.
  • Botnet-beveiliging: het team kan instellingen bewaken en configureren om beveiligingsproblemen met betrekking tot botnets aan te pakken.
  • Pariteit met on-premises: de on-premises oplossing werd uitgevoerd achter een webtoepassingsfirewall die wordt beheerd door IT.
  • Gebruiksgemak: Web Application Firewall kan worden geïntegreerd met Azure Front Door.

• Configuratieopslag: kies of u app-configuratieopslag wilt toevoegen aan uw web-app. Azure-app Configuration is een service voor het centraal beheren van toepassingsinstellingen en functievlagmen. Bekijk aanbevolen procedures voor App Configuration om te bepalen of deze service geschikt is voor uw app. Relecloud wilde de configuratie op basis van bestanden vervangen door een centraal configuratiearchief dat kan worden geïntegreerd met het toepassingsplatform en de code. Om de volgende redenen hebben ze App Configuration toegevoegd aan de architectuur:

  • Flexibiliteit: het ondersteunt functievlagmen. Met functievlagmen kunnen gebruikers zich afmelden voor vroege preview-functies in een productieomgeving zonder de app opnieuw te implementeren.
  • Ondersteunt Git-pijplijn: de bron van waarheid voor configuratiegegevens moet een Git-opslagplaats zijn. De pijplijn die nodig is om de gegevens in het centrale configuratiearchief bij te werken.
  • Ondersteunt beheerde identiteiten: het ondersteunt beheerde identiteiten om de verbinding met het configuratiearchief te vereenvoudigen en te beveiligen.

• Geheimenbeheerder: Gebruik Azure Key Vault als u geheimen hebt om te beheren in Azure. U kunt Key Vault opnemen in .NET-apps met behulp van het ConfigurationBuilder-object. De on-premises web-app van Relecloud heeft geheimen opgeslagen in codeconfiguratiebestanden, maar het is een betere beveiligingspraktijk om geheimen op te slaan op een locatie die RBAC en controlebesturingselementen ondersteunt. Hoewel beheerde identiteiten de voorkeursoplossing zijn voor het maken van verbinding met Azure-resources, had Relecloud toepassingsgeheimen die ze nodig hadden om te beheren. Relecloud heeft Key Vault gebruikt om de volgende redenen:

  • Versleuteling: het ondersteunt versleuteling at rest en in transit.
  • Ondersteuning voor beheerde identiteiten: de toepassingsservices kunnen beheerde identiteiten gebruiken voor toegang tot het geheime archief.
  • Bewaking en logboekregistratie: het vereenvoudigt de toegang tot audit en genereert waarschuwingen wanneer opgeslagen geheimen worden gewijzigd.
  • Integratie: Het biedt systeemeigen integratie met het Azure-configuratiearchief (App Configuration) en het webhostingplatform (App Service).

• Opslagoplossing: Bekijk de Opties voor Azure-opslag om de juiste opslagoplossing te kiezen op basis van uw vereisten. De on-premises web-app van Relecloud had schijfopslag gekoppeld aan elke webserver, maar het team wilde een oplossing voor externe gegevensopslag gebruiken. Relecloud koos om de volgende redenen voor Azure Blob Storage :

  • Beveiligde toegang: de web-app kan eindpunten elimineren voor toegang tot opslag die beschikbaar is voor het openbare internet met anonieme toegang.
  • Versleuteling: hiermee worden data-at-rest en in transit versleuteld.
  • Tolerantie: Het ondersteunt zone-redundante opslag (ZRS). Zone-redundante opslag repliceert gegevens synchroon over drie Azure-beschikbaarheidszones in de primaire regio. Elke beschikbaarheidszone bevindt zich op een afzonderlijke fysieke locatie met onafhankelijke voeding, koeling en netwerken. Deze configuratie moet ervoor zorgen dat de ticketinstallatiekopieën bestand zijn tegen verlies.

• Eindpuntbeveiliging: Gebruik Azure Private Link om toegang te krijgen tot platform-as-a-service-oplossingen via een privé-eindpunt in uw virtuele netwerk. Verkeer tussen uw virtuele netwerk en de service loopt over het Backbone-netwerk van Microsoft. Relecloud koos Private Link om de volgende redenen:

  • Verbeterde beveiligingscommunicatie: Hiermee kan de toepassing privé toegang krijgen tot services op het Azure-platform en vermindert de netwerkvoetafdruk van gegevensarchieven om bescherming te bieden tegen gegevenslekken.
  • Minimale inspanning: de privé-eindpunten ondersteunen het web-app-platform en het databaseplatform dat de web-app gebruikt. Beide platforms spiegelen bestaande on-premises configuraties voor minimale wijzigingen.

• Netwerkbeveiliging: Gebruik Azure Firewall om inkomend en uitgaand verkeer op netwerkniveau te beheren. Gebruik Azure Bastion om veilig verbinding te maken met virtuele machines zonder RDP-/SSH-poorten weer te geven. Relecloud heeft een sternetwerktopologie aangenomen en wilde gedeelde netwerkbeveiligingsservices in de hub plaatsen. Azure Firewall verbetert de beveiliging door al het uitgaande verkeer van de spokes te inspecteren om de netwerkbeveiliging te verbeteren. Relecloud heeft Azure Bastion nodig voor beveiligde implementaties vanaf een jumphost in het DevOps-subnet.

Richtlijnen voor code

Als u een web-app naar de cloud wilt verplaatsen, moet u de code van uw web-app bijwerken met het patroon Voor opnieuw proberen, circuitonderbreker en ontwerppatroon Cache-Aside.

Figuur 3. Rol van de ontwerppatronen.

Elk ontwerppatroon biedt voordelen van workloadontwerp die zijn afgestemd op een van de meer pijlers van het goed ontworpen framework. Hier volgt een overzicht van de patronen die u moet implementeren:

1. Patroon voor opnieuw proberen: het patroon Opnieuw proberen verwerkt tijdelijke fouten door bewerkingen opnieuw uit te voeren die af en toe kunnen mislukken. Implementeer dit patroon voor alle uitgaande aanroepen naar andere Azure-services.

2. Circuitonderbrekerpatroon: Het circuitonderbrekerpatroon voorkomt dat een toepassing bewerkingen opnieuw probeert uit te voeren die niet tijdelijk zijn. Implementeer dit patroon in alle uitgaande aanroepen naar andere Azure-services.

3. Cache-Aside-patroon: het cache-aside-patroon wordt vaker toegevoegd aan en opgehaald uit een cache dan een gegevensarchief. Implementeer dit patroon voor aanvragen naar de database.

Het patroon Opnieuw proberen implementeren

Voeg het patroon Opnieuw proberen toe aan uw toepassingscode om tijdelijke serviceonderbrekingen aan te pakken. Deze onderbrekingen worden tijdelijke fouten genoemd. Tijdelijke fouten lossen zichzelf meestal binnen enkele seconden op. Met het patroon Opnieuw proberen kunt u mislukte aanvragen opnieuw verzenden. Hiermee kunt u ook de aanvraagvertragingen en het aantal pogingen configureren voordat een fout wordt toegestaan.

• Gebruik ingebouwde mechanismen voor opnieuw proberen Gebruik het ingebouwde mechanisme voor opnieuw proberen dat de meeste Azure-services nodig hebben om de implementatie te versnellen. De referentie-implementatie maakt bijvoorbeeld gebruik van de verbindingstolerantie in Entity Framework Core om het patroon Opnieuw proberen toe te passen in aanvragen naar 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);
      }));
  

• Gebruik programmeerbibliotheken voor opnieuw proberen. Integreer voor HTTP-communicatie een standaardbibliotheek voor tolerantie, zoals Polly of Microsoft.Extensions.Http.Resilience. Deze bibliotheken bieden uitgebreide mechanismen voor opnieuw proberen die essentieel zijn voor het beheren van communicatie met externe webservices. De referentie-implementatie maakt bijvoorbeeld gebruik van Polly om het patroon Opnieuw proberen af te dwingen telkens wanneer de code een object samenstelt dat het IConcertSearchService object 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);
  }
  

Het circuitonderbrekerpatroon implementeren

Gebruik het circuitonderbrekerpatroon om serviceonderbrekingen af te handelen die geen tijdelijke fouten zijn. Het circuitonderbrekerpatroon voorkomt dat een toepassing continu toegang probeert te krijgen tot een service die niet reageert. De toepassing wordt vrijgegeven en cpu-cycli worden vermeden, zodat de toepassing de prestatie-integriteit voor eindgebruikers behoudt.

De referentie-implementatie past bijvoorbeeld het circuitonderbrekerpatroon toe op alle aanvragen voor de API. Er wordt gebruikgemaakt van de HandleTransientHttpError logica om HTTP-aanvragen te detecteren die veilig opnieuw kunnen worden geprobeerd, maar beperkt het aantal cumulatieve fouten gedurende een opgegeven periode (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));
}

Het cache-aside-patroon implementeren

Voeg het cache-aside-patroon toe aan uw web-app om het gegevensbeheer in het geheugen te verbeteren. 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. Het verkort de reactietijden, verbetert de doorvoer en vermindert de behoefte aan meer schaalaanpassing. Het vermindert ook de belasting van het primaire gegevensarchief, waardoor de betrouwbaarheid en kostenoptimalisatie worden verbeterd. Volg deze aanbevelingen om het cache-aside-patroon te implementeren:

• Configureer de toepassing voor het gebruik van een cache. Productie-apps moeten gebruikmaken van de gedistribueerde Redis-cache omdat deze de prestaties verbetert door databasequery's te verminderen en niet-plaksessies mogelijk te maken, zodat de load balancer verkeer gelijkmatig kan distribueren. De referentie-implementatie maakt bijvoorbeeld gebruik van gedistribueerde Redis-cache. De AddAzureCacheForRedis methode 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();
      }
  }
  

• Gegevens die veel nodig zijn in de cache opslaan. Pas het cache-aside-patroon toe op gegevens die veel nodig zijn om de effectiviteit ervan te vergroten. 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 nadat u het cache-aside-patroon hebt toegepast. De referentie-implementatie slaat bijvoorbeeld gegevens met een hoge behoefte in de cache op die ondersteuning bieden voor de pagina Geplande concerten. De GetUpcomingConcertsAsync methode haalt gegevens op uit de SQL Database in de Redis-cache en vult de cache met de meest recente concertengegevens (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>();
  }
  

• Houd cachegegevens actueel. 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. De referentie-implementatie slaat bijvoorbeeld slechts één uur gegevens in de cache op en gebruikt de CreateConcertAsync methode om de cachesleutel te wissen wanneer de gegevens worden gewijzigd (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);
  }
  

• Zorg voor gegevensconsistentie. 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. De referentie-implementatie gebruikt bijvoorbeeld 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();
  }
  

Configuratierichtlijnen

De volgende secties bevatten richtlijnen voor het implementeren van de configuratie-updates. Elke sectie wordt uitgelijnd met een of meer pijlers van het Well-Architected Framework.

Gebruikersverificatie en -autorisatie configureren

Wanneer u webtoepassingen naar Azure migreert, configureert u gebruikersverificatie en autorisatiemechanismen. Volg deze aanbevelingen:

• Gebruik een identiteitsplatform. Gebruik het Microsoft Identity Platform om verificatie van web-apps in te stellen. Dit platform ondersteunt toepassingen die gebruikmaken van één Microsoft Entra-directory, meerdere Microsoft Entra-mappen van verschillende organisaties en Microsoft-identiteiten of sociale accounts.

• Maak een app-registratie. Microsoft Entra ID vereist een toepassingsregistratie in de primaire tenant. De toepassingsregistratie zorgt ervoor dat de gebruikers die toegang krijgen tot de web-app identiteiten hebben in de primaire tenant.

• Platformfuncties gebruiken. Minimaliseer de noodzaak van aangepaste verificatiecode met behulp van platformmogelijkheden om gebruikers te verifiëren en toegang te krijgen tot gegevens. App Service biedt bijvoorbeeld ingebouwde verificatieondersteuning, zodat u gebruikers kunt aanmelden en toegang hebt tot gegevens door minimale of geen code in uw web-app te schrijven.

• Autorisatie in de toepassing afdwingen. Gebruik op rollen gebaseerd toegangsbeheer (RBAC) om minimale bevoegdheden toe te wijzen aan toepassingsrollen. Specifieke rollen definiëren voor verschillende gebruikersacties om overlapping te voorkomen en duidelijkheid te garanderen. Wijs gebruikers toe aan de juiste rollen en zorg ervoor dat ze alleen toegang hebben tot de benodigde resources en acties.

• Geef de voorkeur aan tijdelijke toegang tot opslag. Gebruik tijdelijke machtigingen om te beschermen tegen onbevoegde toegang en schendingen, zoals Shared Access Signatures (SASs). Gebruik SAS's voor gebruikersdelegatie om de beveiliging te maximaliseren bij het verlenen van tijdelijke toegang. Het is de enige SAS die gebruikmaakt van Microsoft Entra ID-referenties en waarvoor geen permanente opslagaccountsleutel is vereist.

• Autorisatie afdwingen in Azure. Gebruik Azure RBAC om minimale bevoegdheden toe te wijzen aan gebruikersidentiteiten. Azure RBAC bepaalt waartoe Identiteiten van Azure-resources toegang hebben, wat ze met deze resources kunnen doen en tot welke gebieden ze toegang hebben.

• Vermijd permanente verhoogde machtigingen. Gebruik Microsoft Entra Privileged Identity Management om Just-In-Time-toegang te verlenen voor bevoorrechte bewerkingen. Ontwikkelaars hebben bijvoorbeeld vaak toegang op beheerdersniveau nodig om databases te maken/verwijderen, tabelschema's te wijzigen en gebruikersmachtigingen te wijzigen. Met Just-In-Time-toegang ontvangen gebruikersidentiteiten tijdelijke machtigingen voor het uitvoeren van bevoorrechte taken.

Beheerde identiteiten implementeren

Beheerde identiteiten gebruiken voor alle Azure-services die beheerde identiteiten ondersteunen. Met een beheerde identiteit kunnen Azure-resources (workloadidentiteiten) worden geverifieerd bij en communiceren met andere Azure-services zonder referenties te beheren. Hybride en verouderde systemen kunnen on-premises verificatieoplossingen behouden om de migratie te vereenvoudigen, maar moeten zo snel mogelijk worden overgestapt op beheerde identiteiten. Volg deze aanbevelingen om beheerde identiteiten te implementeren:

• Kies het juiste type beheerde identiteit. Geef de voorkeur aan door de gebruiker toegewezen beheerde identiteiten wanneer u twee of meer Azure-resources hebt die dezelfde set machtigingen nodig hebben. Deze installatie is efficiënter dan het maken van door het systeem toegewezen beheerde identiteiten voor elk van deze resources en het toewijzen van dezelfde machtigingen aan al deze resources. Gebruik anders door het systeem toegewezen beheerde identiteiten.

• Minimale bevoegdheden configureren. Gebruik Azure RBAC om alleen de machtigingen te 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. Als Azure RBAC geen specifiek scenario omvat, moet u Azure RBAC aanvullen met toegangsbeleid op Azure-serviceniveau.

• Beveilig resterende geheimen. Sla eventuele resterende geheimen op in Azure Key Vault. Laad geheimen uit Key Vault bij het opstarten van de toepassing in plaats van tijdens elke HTTP-aanvraag. Toegang met hoge frequentie binnen HTTP-aanvragen kan de transactielimieten van Key Vault overschrijden. Sla toepassingsconfiguraties op in Azure-app Configuratie.

De referentie-implementatie maakt bijvoorbeeld gebruik van het Authentication argument in de SQL-database verbindingsreeks zodat App Service verbinding kan maken met de SQL-database met een beheerde identiteit: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default De web-API wordt gebruikt DefaultAzureCredential om verbinding te maken met Key Vault met behulp van een beheerde identiteit (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 in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Omgevingen met de juiste grootte

Gebruik de prestatielagen (SKU's) van Azure-services die voldoen aan de behoeften van elke omgeving zonder overtollige behoeften. Volg deze aanbevelingen om de grootte van uw omgevingen te wijzigen:

• Kosten schatten. Gebruik de Azure-prijscalculator om de kosten van elke omgeving te schatten.

• Kosten optimaliseren van productieomgevingen. Productieomgevingen hebben SKU's nodig die voldoen aan de SLA(Service Level Agreements), functies en schaal die nodig zijn voor productie. Bewaak continu het resourcegebruik en pas SKU's aan om te voldoen aan de werkelijke prestatiebehoeften.

• Kosten optimaliseren preproductieomgevingen. Preproductieomgevingen moeten gebruikmaken van goedkopere resources, overbodige services uitschakelen en kortingen toepassen, zoals Prijzen voor Azure Dev/Test. Zorg ervoor dat preproductieomgevingen voldoende vergelijkbaar zijn met productie om risico's te voorkomen. Dit evenwicht zorgt ervoor dat testen effectief blijft zonder onnodige kosten te maken.

• SKU's definiëren met infrastructuur als code (IaC). Implementeer IaC om dynamisch de juiste SKU's te selecteren en te implementeren op basis van de omgeving. Deze aanpak verbetert de consistentie en vereenvoudigt het beheer.

De referentie-implementatie gebruikt bijvoorbeeld Bicep-parameters om duurdere lagen (SKU's) te implementeren in de productieomgeving.

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

Automatisch schalen implementeren

Automatische schaalaanpassing zorgt ervoor dat een web-app flexibel, responsief en geschikt blijft voor het efficiënt verwerken van dynamische workloads. Volg deze aanbevelingen om automatisch schalen te implementeren:

• Uitschalen automatiseren. Gebruik automatische schaalaanpassing van Azure om horizontaal schalen in productieomgevingen te automatiseren. Configureer regels voor automatisch schalen om uit te schalen op basis van belangrijke prestatiegegevens, zodat uw toepassing verschillende belastingen kan verwerken.

• Schaaltriggers verfijnen. Begin met CPU-gebruik als de eerste schaaltrigger als u niet bekend bent met de schaalvereisten van uw toepassing. Verfijn uw schaaltriggers met andere metrische gegevens, zoals RAM, netwerkdoorvoer en schijf-I/O. Het doel is om het gedrag van uw webtoepassing te vinden voor betere prestaties.

• Geef een uitschaalbuffer op. Stel de drempelwaarden voor schaalaanpassing in om te activeren voordat u de maximale capaciteit bereikt. Configureer bijvoorbeeld schalen voor 85% CPU-gebruik in plaats van te wachten totdat het 100% bereikt. Deze proactieve aanpak helpt de prestaties te behouden en potentiële knelpunten te voorkomen.

Resource-implementatie automatiseren

Automatisering gebruiken om Azure-resources en -code in alle omgevingen te implementeren en bij te werken. Volg deze aanbevelingen:

• Gebruik infrastructuur als code. Implementeer infrastructuur als code via CI/CD-pijplijnen (continue integratie en continue levering). Azure heeft vooraf bicep-, ARM-(JSON) en Terraform-sjablonen gemaakt voor elke Azure-resource.

• Gebruik een pijplijn voor continue integratie/continue implementatie (CI/CD). Gebruik een CI/CD-pijplijn om code van broncodebeheer te implementeren in uw verschillende omgevingen, zoals testen, faseren en productie. Gebruik Azure Pipelines als u werkt met Azure DevOps of GitHub Actions voor GitHub-projecten.

• Moduletests integreren. Prioriteit geven aan de uitvoering en het doorgeven van alle eenheidstests in uw pijplijn voordat u een implementatie naar App Services uitvoert. Neem codekwaliteit en dekkingshulpprogramma's zoals SonarQube op om uitgebreide testdekking te bereiken.

• Een mockingframework aannemen. Voor het testen met externe eindpunten gebruikt u mocking-frameworks. Met deze frameworks kunt u gesimuleerde eindpunten maken. Ze elimineren de noodzaak om echte externe eindpunten te configureren en uniforme testomstandigheden in omgevingen te garanderen.

• Beveiligingsscans uitvoeren. Gebruik statische SAST (Application Security Testing) om beveiligingsfouten en coderingsfouten in uw broncode te vinden. Voer bovendien softwaresamenstellingsanalyse (SCA) uit om bibliotheken en onderdelen van derden te onderzoeken op beveiligingsrisico's. Hulpprogramma's voor deze analyses zijn direct geïntegreerd in Zowel GitHub als Azure DevOps.

Bewaking implementeren

Implementeer toepassings- en platformbewaking om de operationele uitmuntendheid en prestatie-efficiëntie van uw web-app te verbeteren. Volg deze aanbevelingen om bewaking te implementeren:

• Toepassingstelemetrie verzamelen. Gebruik automatische instrumentatie in Azure-toepassing Insights om toepassingstelemetrie te verzamelen, zoals aanvraagdoorvoer, gemiddelde aanvraagduur, fouten en afhankelijkheidsbewaking, zonder codewijzigingen.

  De referentie-implementatie maakt gebruik AddApplicationInsightsTelemetry van het NuGet-pakket Microsoft.ApplicationInsights.AspNetCore om telemetrieverzameling in te schakelen (zie de volgende code).

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

• Aangepaste metrische toepassingsgegevens maken. Gebruik instrumentatie op basis van code voor aangepaste toepassingstelemetrie. Voeg de Application Insights-SDK toe aan uw code en gebruik de Application Insights-API.

  De referentie-implementatie verzamelt telemetrie over gebeurtenissen met betrekking tot de winkelwagenactiviteit. 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() }
  });
  

• Bewaak het platform. Schakel diagnostische gegevens in voor alle ondersteunde services en verzend diagnostische gegevens naar dezelfde bestemming als de toepassingslogboeken voor correlatie. Azure-services maken automatisch platformlogboeken, maar slaan ze alleen op wanneer u diagnostische gegevens inschakelt. Schakel diagnostische instellingen in voor elke service die diagnostische gegevens ondersteunt.

De referentie-implementatie implementeren

De referentie-implementatie begeleidt ontwikkelaars bij een gesimuleerde migratie van een on-premises ASP.NET toepassing naar Azure, waarbij de benodigde wijzigingen tijdens de initiële acceptatiefase worden gemarkeerd. In dit voorbeeld wordt een toepassing voor concertticketing gebruikt voor het fictieve bedrijf Relecloud, dat tickets verkoopt via de on-premises webtoepassing. Relecloud stelt de volgende doelen voor de webtoepassing in:

• Goedkope, hoogwaardige codewijzigingen implementeren
• Een serviceniveaudoelstelling (SLO) van 99,9% bereiken
• DevOps-procedures gebruiken
• Voor kosten geoptimaliseerde omgevingen maken
• Betrouwbaarheid en beveiliging verbeteren

Relecloud heeft vastgesteld dat hun on-premises infrastructuur geen rendabele oplossing was om aan deze doelstellingen te voldoen. Ze hebben besloten dat het migreren van hun CAMS-webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken. De volgende architectuur vertegenwoordigt de eindstatus van de reliable web app-patroon-implementatie van Relecloud.

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