Reliable Web App-mönster för .NET

Den här artikeln innehåller vägledning för att implementera reliable web app-mönstret. Det här mönstret beskriver hur du ändrar (omplatforma) webbappar för molnmigrering. Den innehåller vägledning om förebyggande arkitektur, kod och konfiguration som är anpassad efter principerna i Azure Well-Architected Framework.

Varför är mönstret Reliable Web App för .NET?

Mönstret Reliable Web App är en uppsättning principer och implementeringstekniker som definierar hur du ska formatera om webbappar när du migrerar dem till molnet. Den fokuserar på de minimala koduppdateringar som du behöver göra för att lyckas i molnet. I följande vägledning används en referensimplementering som ett exempel hela vägen. Vägledningen följer replatformresan för det fiktiva företaget Relecloud för att ge affärskontext för din resa. Innan relecloud implementerade mönstret Reliable Web App för .NET hade han en monolitisk lokal webbapp för biljetthantering som använde ASP.NET ramverket.

Så här implementerar du mönstret Reliable Web App

Den här artikeln innehåller arkitektur, kod och konfigurationsvägledning för implementering av mönstret Reliable Web App. Använd följande länkar för att gå till den specifika vägledning du behöver:

• Affärskontext. Anpassa den här vägledningen till din affärskontext och lär dig hur du definierar omedelbara och långsiktiga mål som driver omplatformingsbeslut.
• Arkitekturvägledning. Lär dig hur du väljer rätt molntjänster och utformar en arkitektur som uppfyller dina affärskrav.
• Kodvägledning. Implementera tre designmönster för att förbättra webbappens tillförlitlighet och prestandaeffektivitet i molnet: mönster för återförsök, kretsbrytare och Cache-Aside.
• Konfigurationsvägledning. Konfigurera autentisering och auktorisering, hanterade identiteter, rättighetsbaserade miljöer, infrastruktur som kod och övervakning.

Affärskontext

Det första steget i att omplatforma en webbapp är att definiera dina affärsmål. Du bör ange omedelbara mål, till exempel servicenivåmål (SLO) och kostnadsoptimeringsmål, samt framtida mål för webbappen. Dessa mål påverkar ditt val av molntjänster och arkitekturen för ditt webbprogram i molnet. Definiera ett mål-SLO för din webbapp, till exempel 99,9 % drifttid. Beräkna det sammansatta serviceavtalet för alla tjänster som påverkar webbappens tillgänglighet.

Relecloud har till exempel en positiv försäljningsprognos och förväntar sig ökad efterfrågan på sin biljettwebbapp. För att möta denna efterfrågan definierade de målen för webbappen:

• Tillämpa kodändringar med låga kostnader och höga värden.
• Nå ett servicenivåmål på 99,9%.
• Anta DevOps-metoder.
• Skapa kostnadsoptimerade miljöer.
• Förbättra tillförlitligheten och säkerheten.

Releclouds lokala infrastruktur var inte en kostnadseffektiv lösning för att nå dessa mål. De bestämde sig för att migrera sina webbprogram till Azure var det mest kostnadseffektiva sättet att uppnå sina omedelbara och framtida mål.

Vägledning för arkitektur

Reliable Web App-mönstret har några viktiga arkitektoniska element. Du behöver DNS för att hantera slutpunktsmatchning, en brandvägg för webbprogram för att blockera skadlig HTTP-trafik och en lastbalanserare för att dirigera och skydda inkommande användarbegäranden. Programplattformen är värd för din webbappskod och anropar alla serverdelstjänster via privata slutpunkter i ett virtuellt nätverk. Ett programprestandaövervakningsverktyg samlar in mått och loggar som hjälper dig att förstå din webbapp.

Figur 1. Viktiga arkitektoniska element i Reliable Web App-mönstret.

Utforma arkitekturen

Utforma infrastrukturen för att stödja dina återställningsmått, till exempel ditt mål för återställningstid (RTO) och mål för återställningspunkt (RPO). RTO påverkar tillgängligheten och måste ha stöd för ditt serviceavtal. Fastställ ett RPO och konfigurera dataredundans för att uppfylla RPO.

• Välj infrastrukturtillförlitlighet. Ta reda på hur många tillgänglighetszoner och regioner du behöver för att uppfylla dina tillgänglighetskrav. Lägg till tillgänglighetszoner och regioner tills det sammansatta serviceavtalet uppfyller ditt serviceavtal. Mönstret Reliable Web App stöder flera regioner för en aktiv-aktiv eller aktiv-passiv konfiguration. Referensimplementeringen använder till exempel en aktiv-passiv konfiguration för att uppfylla ett servicemål på 99,9 %.

  För en webbapp för flera regioner konfigurerar du lastbalanseraren så att den dirigerar trafik till den andra regionen för att stödja antingen en aktiv-aktiv eller aktiv-passiv konfiguration, beroende på företagets behov. De två regionerna kräver samma tjänster, förutom att en region har ett virtuellt navnätverk som ansluter regionerna. Anta en nätverkstopologi för nav och eker för att centralisera och dela resurser, till exempel en nätverksbrandvägg. Om du har virtuella datorer lägger du till en skyddsvärd i det virtuella hubbnätverket för att hantera dem med förbättrad säkerhet. (Se bild 2.)

  

  Figur 2. Mönstret Reliable Web App med en andra region och en topologi med nav och eker.

• Välj en nätverkstopologi. Välj rätt nätverkstopologi för dina webb- och nätverkskrav. Om du planerar att använda flera virtuella nätverk använder du en nätverkstopologi för nav och eker. Det ger kostnads-, hanterings- och säkerhetsfördelar samt hybridanslutningsalternativ till lokala och virtuella nätverk.

Välj rätt Azure-tjänster

När du flyttar en webbapp till molnet bör du välja Azure-tjänster som uppfyller dina affärskrav och som överensstämmer med de aktuella funktionerna i den lokala webbappen. Den här justeringen hjälper till att minimera omplatformningsarbetet. Använd till exempel tjänster som gör att du kan behålla samma databasmotor och stödja befintliga mellanprogram och ramverk. Följande avsnitt innehåller vägledning för att välja rätt Azure-tjänster för din webbapp.

Innan den till exempel flyttades till molnet var Releclouds biljettwebbapp en lokal monolitisk ASP.NET app. Den kördes på två virtuella datorer och använde en SQL Server-databas. Webbappen har drabbats av vanliga problem med skalbarhet och funktionsdistribution. Den här utgångspunkten, deras affärsmål och SLO drev deras tjänstval.

• Programplattform: Använd Azure App Service som programplattform. Relecloud valde App Service som programplattform av följande skäl:

  • Serviceavtal (SLA) på hög servicenivå. Det har ett högt serviceavtal som uppfyller produktionsmiljöns SLO på 99,9%.
  • Minskade hanteringskostnader. Det är en fullständigt hanterad lösning som hanterar skalning, hälsokontroller och belastningsutjämning.
  • .NET-stöd. Den stöder den version av .NET som programmet är skrivet i.
  • Containeriseringsfunktion. Webbappen kan konvergera i molnet utan att containeriseras, men programplattformen stöder också containerisering utan att ändra Azure-tjänster.
  • Automatisk skalning. Webbappen kan automatiskt skala in och ut baserat på användartrafik och konfigurationsinställningar. Plattformen stöder också upp- eller nedskalning för att hantera olika värdkrav.

• Identitetshantering: Använd Microsoft Entra-ID som identitets- och åtkomsthanteringslösning. Relecloud valde Microsoft Entra-ID av följande skäl:

  • Autentisering och auktorisering. Programmet måste autentisera och auktorisera callcenter-anställda.
  • Skalbar. Microsoft Entra ID skalar för att stödja större scenarier.
  • Användaridentitetskontroll. Callcenter-anställda kan använda sina befintliga företagsidentiteter.
  • Stöd för auktoriseringsprotokoll. Microsoft Entra ID stöder OAuth 2.0 för hanterade identiteter.

• Databas: Använd en tjänst som gör att du kan behålla samma databasmotor. Använd beslutsträdet för datalager för att vägleda ditt val. Releclouds webbapp använde SQL Server lokalt. De ville använda det befintliga databasschemat, lagrade procedurer och funktioner. Flera SQL-produkter är tillgängliga i Azure, men Relecloud valde Azure SQL Database av följande skäl:

  • Tillförlitlighet. Nivån generell användning ger ett högt serviceavtal och redundans i flera regioner. Det kan ge stöd för hög användarbelastning.
  • Minskade hanteringskostnader. SQL Database tillhandahåller en hanterad SQL-databasinstans.
  • Migreringsstöd. Den stöder databasmigrering från lokal SQL Server.
  • Konsekvens med lokala konfigurationer. Den stöder befintliga lagrade procedurer, funktioner och vyer.
  • Resiliency. Den stöder säkerhetskopieringar och återställning till tidpunkt.
  • Expertis och minimalt omarbete. SQL Database gör det möjligt för Relecloud att dra nytta av befintlig expertis och kräver minimalt arbete att införa.

• Övervakning av programprestanda: Använd Application Insights för att analysera telemetri för ditt program. Relecloud valde att använda Application Insights av följande skäl:

  • Integrering med Azure Monitor. Det ger den bästa integreringen med Azure Monitor.
  • Avvikelseidentifiering. Den identifierar automatiskt prestandaavvikelser.
  • Felsökning. Det hjälper dig att diagnostisera problem i appen som körs.
  • Övervakning. Den samlar in information om hur användare använder appen och gör att du enkelt kan spåra anpassade händelser.
  • Synlighetsgap. Den lokala lösningen hade ingen lösning för övervakning av programprestanda. Application Insights ger enkel integrering med programplattformen och koden.

• Cache: Välj om du vill lägga till en cache i webbappens arkitektur. Azure Cache for Redis är den primära Azure Cache-lösningen. Det är ett hanterat minnesinternt datalager som baseras på Redis-programvara. Releclouds webbappsbelastning är kraftigt skev mot att visa konserter och platsinformation. Relecloud har lagt till Azure Cache for Redis av följande skäl:

  • Minskade hanteringskostnader. Det är en fullständigt hanterad tjänst.
  • Hastighet och volym. Den har dataflöde med hög dataflöde och läsningar med låg svarstid för data som används ofta och är långsamt föränderliga.
  • Varierande support. Det är en enhetlig cacheplats som alla instanser av webbappen kan använda.
  • Externt datalager. De lokala programservrarna utförde vm-lokal cachelagring. Den här konfigurationen avlastade inte mycket frekventa data och det gick inte att ogiltigförklara data.
  • Nonsticky-sessioner. Externalisering av sessionstillstånd stöder icke-sticka sessioner.

• Lastbalanserare: webbprogram som använder PaaS-lösningar bör använda Azure Front Door, Azure Application Gateway eller båda, beroende på webbappens arkitektur och krav. Använd beslutsträdet för lastbalanseraren för att välja rätt lastbalanserare. Relecloud behövde en layer-7-lastbalanserare som kunde dirigera trafik över flera regioner. Företaget behövde en webbapp för flera regioner för att uppfylla SLO:et för 99,9%. Relecloud valde Azure Front Door av följande skäl:

  • Global belastningsutjämning. Det är en layer-7-lastbalanserare som kan dirigera trafik över flera regioner.
  • Brandvägg för webbprogram. Den integreras internt med Azure Web Application Firewall.
  • Flexibilitet för routning. Det gör att programteamet kan konfigurera inkommande behov för att stödja framtida ändringar i programmet.
  • Trafikacceleration. Den använder anycast för att nå den närmaste Azure-platsen och hitta den snabbaste vägen till webbappen.
  • Anpassade domäner. Den stöder anpassade domännamn med flexibel domänverifiering.
  • Hälsoavsökningar. Programmet kräver intelligent hälsoavsökningsövervakning. Azure Front Door använder svar från avsökningen för att fastställa det bästa ursprunget för routning av klientbegäranden.
  • Stöd för övervakning. Den stöder inbyggda rapporter med en allt-i-ett-instrumentpanel för både Azure Front Door och säkerhetsmönster. Du kan konfigurera aviseringar som integreras med Azure Monitor. Med Azure Front Door kan programmet logga varje begäran och misslyckade hälsoavsökningar.
  • DDoS-skydd. Den har inbyggt layer 3-4 DDoS-skydd.
  • Nätverk för innehållsleverans. Det placerar Relecloud för att använda ett nätverk för innehållsleverans. Nätverket för innehållsleverans ger platsacceleration.

• Brandvägg för webbprogram: Använd Azure Web Application Firewall för att ge centraliserat skydd mot vanliga webbexploateringar och sårbarheter. Relecloud använder Azure Web Application Firewall av följande skäl:

  • Globalt skydd. Det ger förbättrat globalt webbappskydd utan att offra prestanda.
  • Botnet-skydd. Teamet kan övervaka och konfigurera inställningar för att hantera säkerhetsproblem som rör botnät.
  • Paritet med lokalt. Den lokala lösningen kördes bakom en brandvägg för webbprogram som hanteras av IT.
  • Användarvänlighet. Brandväggen för webbaserade program integreras med Azure Front Door.

• Konfigurationslagring: Välj om du vill lägga till appkonfigurationslagring i webbappen. Azure App Configuration är en tjänst för central hantering av programinställningar och funktionsflaggor. Läs metodtipsen för appkonfiguration för att avgöra om den här tjänsten passar din app. Relecloud ville ersätta filbaserad konfiguration med ett centralt konfigurationslager som integreras med programplattformen och koden. De har lagt till App Configuration i arkitekturen av följande skäl:

  • Flexibilitet. Den stöder funktionsflaggor. Med funktionsflaggor kan användare välja att använda funktioner för tidig förhandsversion i en produktionsmiljö utan att kräva omdistribution av appar.
  • Stöd för Git-pipeline. Sanningskällan för konfigurationsdata behövde vara en Git-lagringsplats. Pipelinen som behövs för att uppdatera data i det centrala konfigurationsarkivet.
  • Stöd för hanterad identitet. Den stöder hanterade identiteter för att förenkla och skydda anslutningen till konfigurationsarkivet.

• Secrets Manager: Använd Azure Key Vault om du har hemligheter att hantera i Azure. Du kan införliva Key Vault i .NET-appar med hjälp av ConfigurationBuilder-objektet. Releclouds lokala webbapp lagrade hemligheter i kodkonfigurationsfiler, men en bättre säkerhetspraxis är att lagra hemligheter på en plats som stöder RBAC och granskningskontroller. Även om hanterade identiteter är den bästa lösningen för att ansluta till Azure-resurser, hade Relecloud programhemligheter som de behövde hantera. Relecloud använde Key Vault av följande skäl:

  • Kryptering. Den stöder kryptering i vila och under överföring.
  • Stöd för hanterad identitet. Programtjänsterna kan använda hanterade identiteter för att komma åt det hemliga arkivet.
  • Övervakning och loggning. Key Vault underlättar granskningsåtkomst och genererar aviseringar när lagrade hemligheter ändras.
  • Integration. Key Vault tillhandahåller intern integrering med Azure-konfigurationsarkivet (App Configuration) och webbvärdplattformen (App Service).

• Storage-lösning: Se Azure-lagringsalternativ för att välja rätt lagringslösning baserat på dina behov. Releclouds lokala webbapp hade disklagring monterad på varje webbserver, men teamet ville använda en extern datalagringslösning. Relecloud valde Azure Blob Storage av följande skäl:

  • Förbättrad säkerhetsåtkomst. Webbappen kan eliminera slutpunkter för åtkomst till lagring som exponeras för det offentliga Internet med anonym åtkomst.
  • Kryptering. Blob Storage krypterar vilande data och under överföring.
  • Resiliency. Blob Storage stöder zonredundant lagring (ZRS). Zonredundant lagring replikerar data synkront över tre Azure-tillgänglighetszoner i den primära regionen. Varje tillgänglighetszon finns på en separat fysisk plats som har oberoende ström, kylning och nätverk. Den här konfigurationen bör göra biljettbilderna motståndskraftiga mot förlust.

• Endpoint Security: Använd Azure Private Link- för att komma åt PaaS-lösningar (plattform som en tjänst) via en privat slutpunkt i ditt virtuella nätverk. Trafik mellan ditt virtuella nätverk och tjänsten färdas över Microsofts stamnätverk. Relecloud valde Private Link av följande skäl:

  • Förbättrad säkerhetskommunikation. Private Link gör att programmet kan komma åt tjänster privat på Azure-plattformen och minskar nätverksavtrycket för datalager för att skydda mot dataläckage.
  • Minimal ansträngning. De privata slutpunkterna stöder webbappplattformen och databasplattformen som webbappen använder. Båda plattformarna speglar befintliga lokala konfigurationer, så minimala ändringar krävs.

• Nätverkssäkerhet. Använd Azure Firewall för att styra inkommande och utgående trafik på nätverksnivå. Använd Azure Bastion- för att ansluta till virtuella datorer med förbättrad säkerhet, utan att exponera RDP/SSH-portar. Relecloud antog en nätverkstopologi för nav och eker och ville placera delade nätverkssäkerhetstjänster i hubben. Azure Firewall förbättrar säkerheten genom att inspektera all utgående trafik från ekrarna för att öka nätverkssäkerheten. Relecloud behövde Azure Bastion för utökade säkerhetsdistributioner från en jump-värd i DevOps-undernätet.

Kodvägledning

Om du vill flytta en webbapp till molnet måste du uppdatera webbappens kod med återförsöksmönstret, kretsbrytarmönstret och Cache-Aside mönstret.

Figur 3. Roller för designmönstren.

Varje designmönster ger arbetsbelastningsdesignfördelar som överensstämmer med en eller flera grundpelare i Well-Architected Framework. Här är en översikt över de mönster som du bör implementera:

1. Återförsöksmönster. Återförsöksmönstret hanterar tillfälliga fel genom att försöka utföra åtgärder som kan misslyckas tillfälligt. Implementera det här mönstret för alla utgående anrop till andra Azure-tjänster.

2. Kretsbrytarmönster. Kretsbrytarmönstret förhindrar att ett program försöker utföra åtgärder som inte är tillfälliga igen. Implementera det här mönstret i alla utgående anrop till andra Azure-tjänster.

3. Cache-Aside mönster. Mönstret Cache-Aside läser in data på begäran till en cache från ett datalager. Implementera det här mönstret på begäranden till databasen.

Implementera återförsöksmönstret

Lägg till mönstret Försök igen i programkoden för att åtgärda tillfälliga tjänststörningar. Dessa störningar kallas för tillfälliga fel. Tillfälliga fel löser sig vanligtvis inom några sekunder. Med återförsöksmönstret kan du skicka misslyckade begäranden igen. Det gör också att du kan konfigurera fördröjningen mellan återförsök och antalet försök att göra innan du medger fel.

• Använd inbyggda mekanismer för återförsök. Använd den inbyggda mekanismen för återförsök som de flesta Azure-tjänster tillhandahåller för att påskynda implementeringen. Referensimplementeringen använder till exempel anslutningsåterhämtning i Entity Framework Core för att tillämpa återförsöksmönstret i begäranden på SQL Database:

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

• Använd programmeringsbibliotek för återförsök. För HTTP-kommunikation integrerar du ett standardbibliotek för motståndskraft som Polly eller Microsoft.Extensions.Http.Resilience. De här biblioteken tillhandahåller omfattande mekanismer för återförsök som är avgörande för att hantera kommunikation med externa webbtjänster. Referensimplementeringen använder till exempel Polly för att framtvinga återförsöksmönstret varje gång koden skapar ett objekt som anropar IConcertSearchService-objektet:

  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);
  }
  

Implementera kretsbrytarmönstret

Använd kretsbrytarmönstret för att hantera tjänststörningar som inte är tillfälliga fel. Kretsbrytarmönstret hindrar ett program från att kontinuerligt försöka komma åt en tjänst som inte svarar. Det släpper programmet och hjälper till att förhindra att processorcykler slösas bort så att programmet behåller sin prestandaintegritet för slutanvändarna.

Referensimplementeringen tillämpar till exempel kretsbrytarmönstret på alla begäranden till API:et. Den använder den HandleTransientHttpError logiken för att identifiera HTTP-begäranden som kan försöka igen på ett säkert sätt, men begränsar antalet aggregerade fel under en angiven tidsperiod:

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

Implementera mönstret Cache-Aside

Lägg till mönstret Cache-Aside i webbappen för att förbättra minnesintern datahantering. Mönstret tilldelar programmet ansvaret för att hantera databegäranden och säkerställa konsekvens mellan cacheminnet och beständig lagring, till exempel en databas. Det förkortar svarstiderna, förbättrar dataflödet och minskar behovet av mer skalning. Det minskar också belastningen på det primära dataarkivet, vilket förbättrar tillförlitligheten och kostnadsoptimeringen. Följ dessa rekommendationer för att implementera cache-Aside-mönstret:

• Konfigurera programmet så att det använder en cache. Produktionsappar bör använda en distribuerad Redis-cache. Den här cachen förbättrar prestandan genom att minska databasfrågorna. Det möjliggör även icke-stickssessioner så att lastbalanseraren kan distribuera trafik jämnt. Referensimplementeringen använder en distribuerad Redis-cache. Metoden AddAzureCacheForRedis konfigurerar programmet att använda Azure Cache for Redis:

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

• Cachelagrade data med stort behov. Använd Cache-Aside-mönstret på data med stort behov för att förbättra dess effektivitet. Använd Azure Monitor för att spåra databasens processor, minne och lagring. Dessa mått hjälper dig att avgöra om du kan använda en mindre databas-SKU när du har tillämpat Cache-Aside-mönstret. Referensimplementeringen cachelagrar till exempel data med stort behov som stöder sidan Kommande konserter. Metoden GetUpcomingConcertsAsync hämtar data till Redis-cachen från SQL Database och fyller cacheminnet med de senaste konsertdata:

  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>();
  }
  

• Håll cachedata fräscha. Schemalägg regelbundna cacheuppdateringar för att synkronisera med de senaste databasändringarna. Använd datavolatilitet och användaren måste fastställa den optimala uppdateringsfrekvensen. Den här metoden säkerställer att programmet använder Cache-Aside-mönstret för att ge både snabb åtkomst och aktuell information. Referensimplementeringen cachelagrar till exempel endast data i en timme och använder metoden CreateConcertAsync för att rensa cachenyckeln när data ändras:

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

• Se till att data är konsekventa. Implementera mekanismer för att uppdatera cachen omedelbart efter en databasskrivningsåtgärd. Använd händelsedrivna uppdateringar eller dedikerade datahanteringsklasser för att säkerställa cachesammanhållning. Konsekvent synkronisering av cacheminnet med databasändringar är centralt för cache-Aside-mönstret. Referensimplementeringen använder metoden UpdateConcertAsync för att hålla data i cacheminnet konsekventa:

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

Konfigurationsvägledning

Följande avsnitt innehåller vägledning om hur du implementerar konfigurationsuppdateringarna. Varje avsnitt överensstämmer med en eller flera pelare i det välarkitekterade ramverket.

Konfigurera användarautentisering och auktorisering

När du migrerar webbprogram till Azure konfigurerar du mekanismer för användarautentisering och auktorisering. Följ dessa rekommendationer:

• Använd en identitetsplattform. Använd Microsoft Identity-plattformen för att konfigurera autentisering av webbappar. Den här plattformen stöder program som använder en enda Microsoft Entra-katalog, flera Microsoft Entra-kataloger från olika organisationer samt Microsoft-identiteter eller sociala konton.

• Skapa en programregistrering. Microsoft Entra-ID kräver en programregistrering i den primära klientorganisationen. Programregistreringen hjälper till att säkerställa att användare som får åtkomst till webbappen har identiteter i den primära klientorganisationen.

• Använd plattformsfunktioner. Minimera behovet av anpassad autentiseringskod med hjälp av plattformsfunktioner för att autentisera användare och komma åt data. App Service- ger till exempel inbyggt autentiseringsstöd, så att du kan logga in användare och komma åt data när du skriver minimal eller ingen kod i webbappen.

• Framtvinga auktorisering i programmet. Använd RBAC för att tilldela minst behörighet till programroller. Definiera specifika roller för olika användaråtgärder för att undvika överlappning och säkerställa tydlighet. Mappa användare till lämpliga roller och se till att de bara har åtkomst till nödvändiga resurser och åtgärder.

• Föredrar tillfällig åtkomst till lagring. Använd tillfälliga behörigheter för att skydda mot obehörig åtkomst och intrång. Du kan till exempel använda signaturer för delad åtkomst (SAS) för att begränsa åtkomsten till en viss tidsperiod. Använd SAS för användardelegering för att maximera säkerheten när du beviljar tillfällig åtkomst. Det är den enda SAS som använder autentiseringsuppgifter för Microsoft Entra-ID och som inte kräver en permanent lagringskontonyckel.

• Framtvinga auktorisering i Azure. Använd Azure RBAC för att tilldela minsta möjliga behörighet till användaridentiteter. Azure RBAC definierar de Azure-resurser som identiteter kan komma åt, vad de kan göra med dessa resurser och de områden som de har åtkomst till.

• Undvik permanent utökade behörigheter. Använd Microsoft Entra Privileged Identity Management för att bevilja just-in-time-åtkomst för privilegierade åtgärder. Utvecklare behöver till exempel ofta åtkomst på administratörsnivå för att skapa/ta bort databaser, ändra tabellscheman och ändra användarbehörigheter. När du använder just-in-time-åtkomst får användaridentiteter tillfälliga behörigheter för att utföra privilegierade uppgifter.

Använda hanterade identiteter

Använd hanterade identiteter för alla Azure-tjänster som stöder dem. Med en hanterad identitet kan Azure-resurser (arbetsbelastningsidentiteter) autentisera till och interagera med andra Azure-tjänster utan att du behöver hantera autentiseringsuppgifter. För att förenkla migreringen kan du fortsätta att använda lokala autentiseringslösningar för hybridsystem och äldre system, men du bör överföra dem till hanterade identiteter så snart som möjligt. Följ dessa rekommendationer för att implementera hanterade identiteter:

• Välj rätt typ av hanterad identitet. Föredrar användartilldelade hanterade identiteter när du har två eller flera Azure-resurser som behöver samma uppsättning behörigheter. Den här metoden är effektivare än att skapa systemtilldelade hanterade identiteter för var och en av dessa resurser och tilldela samma behörigheter till dem alla. Annars använder du systemtilldelade hanterade identiteter.

• Konfigurera minsta behörighet. Använd Azure RBAC- för att endast bevilja behörigheter som är viktiga för åtgärder, till exempel CRUD-åtgärder i databaser eller åtkomst till hemligheter. Identitetsbehörigheter för arbetsbelastningar är beständiga, så du kan inte ge just-in-time- eller kortsiktiga behörigheter till arbetsbelastningsidentiteter. Om Azure RBAC inte täcker ett specifikt scenario kompletterar du Azure RBAC med åtkomstprinciper på Azure-tjänstnivå.

• Ange säkerhet för återstående hemligheter. Lagra eventuella återstående hemligheter i Azure Key Vault. Läs in hemligheter från Key Vault vid programstart i stället för under varje HTTP-begäran. Högfrekvent åtkomst i HTTP-begäranden kan överskrida key vault-transaktionsgränserna. Lagra programkonfigurationer i Azure App Configuration.

Referensimplementeringen använder argumentet Authentication i SQL Database-anslutningssträngen så att App Service kan ansluta till SQL-databasen med hjälp av en hanterad identitet: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Den använder DefaultAzureCredential för att tillåta att webb-API:et ansluter till Key Vault med hjälp av en hanterad identitet:

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

Rightsize-miljöer

Använd prestandanivåer (SKU:er) för Azure-tjänster som uppfyller behoven i varje miljö utan att överskrida dem. Följ dessa rekommendationer för att ge dina miljöer rättigheter:

• Beräkna kostnader. Använd Priskalkylatorn för Azure för att beräkna kostnaden för varje miljö.

• Kostnadsoptimera produktionsmiljöer. Produktionsmiljöer behöver SKU:er som uppfyller serviceavtalen (SLA), funktioner och skalning som behövs för produktion. Övervaka resursanvändningen kontinuerligt och justera SKU:er så att de överensstämmer med de faktiska prestandabehoven.

• Kostnadsoptimera förproduktionsmiljöer.förproduktionsmiljöer bör använda resurser med lägre kostnad och dra nytta av rabatter som Prissättning för Azure Dev/Test. I dessa miljöer bör du inaktivera tjänster som inte behövs. Se samtidigt till att förproduktionsmiljöer är tillräckligt lika produktionsmiljöer miljöer för att undvika risker. Att upprätthålla den här balansen säkerställer att testningen förblir effektiv utan onödiga kostnader.

• Använd infrastruktur som kod (IaC) för att definiera SKU:er. Implementera IaC för att dynamiskt välja och distribuera rätt SKU:er baserat på miljön. Den här metoden förbättrar konsekvensen och förenklar hanteringen.

Referensimplementeringen använder till exempel Bicep-parametrar för att distribuera dyrare nivåer (SKU:er) till produktionsmiljön:

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

Implementera autoskalning

Autoskalning hjälper till att säkerställa att en webbapp förblir elastisk, dynamisk och kan hantera dynamiska arbetsbelastningar effektivt. Följ dessa rekommendationer för att implementera automatisk skalning:

• Automatisera utskalning. Använd Automatisk skalning i Azure för att automatisera horisontell skalning i produktionsmiljöer. Konfigurera regler för automatisk skalning för att skala ut baserat på viktiga prestandamått så att ditt program kan hantera varierande belastningar.

• Förfina skalningsutlösare. Använd CPU-användning som din första skalningsutlösare om du inte känner till programmets skalningskrav. Förfina dina skalningsutlösare så att de innehåller andra mått som RAM, nätverksdataflöde och disk-I/O. Målet är att matcha webbappens beteende för bättre prestanda.

• Ange en utskalningsbuffert. Ställ in skalningströsklarna så att de utlöses innan maximal kapacitet uppnås. Konfigurera till exempel skalning till 85 % processoranvändning i stället för att vänta tills den når 100 %. Den här proaktiva metoden hjälper till att upprätthålla prestanda och undvika potentiella flaskhalsar.

Automatisera resursdistribution

Använd automatisering för att distribuera och uppdatera Azure-resurser och kod i alla miljöer. Följ dessa rekommendationer:

• Använd infrastruktur som kod. Distribuera infrastruktur som kod med hjälp av CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Azure tillhandahåller fördefinierade Bicep-, ARM- (JSON- och Terraform-mallar) för varje Azure-resurs.

• Använd en CI/CD-pipeline (continuous integration/continuous deployment). Använd en CI/CD-pipeline för att distribuera kod från källkontroll till olika miljöer, till exempel test, mellanlagring och produktion. Använd Azure Pipelines om du arbetar med Azure DevOps. Använd GitHub Actions för GitHub-projekt.

• Integrera enhetstestning. Prioritera körning och överföring av alla enhetstester i pipelinen innan du distribuerar till App Services. Införliva kodkvalitets- och täckningsverktyg som SonarQube för att uppnå omfattande testtäckning.

• Anta modelleringsramverk. För testning som omfattar externa slutpunkter använder du modelleringsramverk. Med dessa ramverk kan du skapa simulerade slutpunkter. De eliminerar behovet av att konfigurera verkliga externa slutpunkter och säkerställa enhetliga testvillkor i olika miljöer.

• Utföra säkerhetsgenomsökningar. Använd säkerhetstestning för statiska program (SAST) för att hitta säkerhetsfel och kodfel i källkoden. Utför dessutom analys av programvarusammansättning (SCA) för att undersöka bibliotek och komponenter från tredje part för säkerhetsrisker. Verktyg för dessa analyser är enkla att integrera i både GitHub och Azure DevOps.

Implementera övervakning

Implementera program- och plattformsövervakning för att förbättra webbappens driftseffektivitet och prestandaeffektivitet. Följ dessa rekommendationer för att implementera övervakning:

• Samla in programtelemetri. Använd autoinstrumentation i Azure Application Insights för att samla in program telemetri, till exempel dataflöde för begäranden, genomsnittlig varaktighet för begäran, fel och beroendeövervakning. Du behöver inte göra några kodändringar för att använda den här telemetrin.

  Referensimplementeringen använder AddApplicationInsightsTelemetry från NuGet-paketet Microsoft.ApplicationInsights.AspNetCore för att aktivera telemetrisamling:

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

• Skapa anpassade programmått. Använd kodbaserad instrumentation för anpassad programtelemetri. Lägg till Application Insights SDK i koden och använd Application Insights-API:et.

  Referensimplementeringen samlar in telemetri om händelser relaterade till kundvagnsaktivitet. this.telemetryClient.TrackEvent räknar de biljetter som lagts till i kundvagnen. Den tillhandahåller händelsenamnet (AddToCart) och anger en ordlista som har concertId och count:

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

• Övervaka plattformen. Aktivera diagnostik för alla tjänster som stöds. Skicka diagnostik till samma mål som programloggarna för korrelation. Azure-tjänster skapar plattformsloggar automatiskt men lagrar dem bara när du aktiverar diagnostik. Aktivera diagnostikinställningar för varje tjänst som stöder diagnostik.

Distribuera referensimplementeringen

Referensimplementeringen vägleder utvecklare genom en simulerad migrering från ett lokalt ASP.NET-program till Azure och belyser de ändringar som krävs under den inledande implementeringsfasen. I det här exemplet används ett konsertbiljettprogram för det fiktiva företaget Relecloud, som säljer biljetter via sin lokala webbapp. Relecloud anger följande mål för webbappen:

• Implementera kodändringar med låga kostnader och höga värden.
• Uppnå ett servicemål på 99,9%.
• Anta DevOps-metoder.
• Skapa kostnadsoptimerade miljöer.
• Förbättra tillförlitligheten och säkerheten.

Relecloud fastställde att deras lokala infrastruktur inte var en kostnadseffektiv lösning för att uppfylla dessa mål. De bestämde sig för att migrera sina webbprogram till Azure var det mest kostnadseffektiva sättet att uppnå sina omedelbara och framtida mål. Följande arkitektur representerar sluttillståndet för Releclouds reliable web app-mönsterimplementering.

bild 4. Arkitektur för referensimplementeringen. Ladda ned en Visio-fil av den här arkitekturen.