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

Den här artikeln innehåller vägledning om hur du implementerar reliable web app-mönstret. Det här mönstret beskriver hur du ändrar (omplatforma) webbappar för molnmigrering. Den erbjuder normativ arkitektur, kod och konfigurationsvägledning i linje med principerna i det välarkitekterade ramverket.

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 till molnet. Den fokuserar på de minimala koduppdateringar som du behöver göra för att lyckas i molnet. Följande vägledning använder referensimplementeringen som ett exempel hela tiden och följer replatformresan för det fiktiva företaget Relecloud för att tillhandahålla affärskontext för din resa. Innan relecloud implementerade mönstret Reliable Web App för .NET hade han en monolitisk, lokal biljettwebbapp som använde det ASP.NET ramverket.

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

Den här artikeln innehåller vägledning för arkitektur, kod och konfiguration för att implementera mönstret Reliable Web App. Använd följande länkar för att navigera 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 på omplatformningsbeslut.
• 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: Försök igen, Kretsbrytare och Cache-Aside-mönster
• 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 och kostnadsoptimeringsmål, samt framtida mål för ditt webbprogram. 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 (SLO) 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. Därför bestämde de 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 skydda och dirigera 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 för 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 mål för återställningstid (RTO) och mål för återställningspunkter (RPO). RTO påverkar tillgängligheten och måste ha stöd för ditt serviceavtal. Fastställ ett mål för återställningspunkt (RPO) och konfigurera dataredundans för att uppfylla RPO.

• Välj infrastrukturtillförlitlighet. Avgör hur många tillgänglighetszoner och regioner du behöver för att uppfylla dina tillgänglighetsbehov. 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å ditt affärsbehov. 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 på ett säkert sätt (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 ha flera virtuella nätverk använder du en nätverkstopologi för nav och ekrar. Det ger kostnads-, hanterings- och säkerhetsfördelar med 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. 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 du till exempel flyttar till molnet var Releclouds biljettwebbapp en lokal, monolitisk ASP.NET app. Den kördes på två virtuella datorer och hade en Microsoft SQL Server-databas. Webbappen har drabbats av vanliga utmaningar när det gäller 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 Azure App Service som programplattform av följande skäl:

  • Serviceavtal (SLA): Det har ett högt serviceavtal som uppfyller serviceavtalet för produktionsmiljön på 99,9 %.
  • Minskade hanteringskostnader: Det är en helt 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.
  • Kapacitet för containerisering: Webbappen kan konvergera i molnet utan att containeriseras, men programplattformen stöder även containerisering utan att ändra Azure-tjänster.
  • Autoskalning: 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: Den skalas 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: Det 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 datalagret. Releclouds webbapp använde SQL Server lokalt. De ville därför 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: Den tillhandahåller en hanterad SQL-databasinstans.
  • Stöd för migrering: Den stöder databasmigrering från lokal SQL Server.
  • Konsekvens med lokala konfigurationer: Den stöder befintliga lagrade procedurer, funktioner och vyer.
  • Återhämtning: Den stöder säkerhetskopieringar och återställning till tidpunkt.
  • Expertis och minimal omarbetning: SQL Database drar nytta av den interna expertisen och kräver minimalt arbete att använda.

• Övervakning av programprestanda: Använd Application Insights för att analysera telemetri i 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 cache i webbappens arkitektur. Azure Cache for Redis är Azures primära cachelösning. Det är ett hanterat minnesinternt datalager baserat på Redis-programvaran. Releclouds webbappsbelastning är kraftigt skev mot att visa konserter och platsinformation, och den lade 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åg latensläsning för data som ofta används och som ändras långsamt.
  • Mångsidig support: Det är en enhetlig cacheplats för alla instanser av webbappen att 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-stickiga sessioner.

• Lastbalanserare: Webbprogram som använder PaaS-lösningar bör använda Azure Front Door, Azure Application Gateway eller båda baserat 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. Relecloud behövde en webbapp för flera regioner för att uppfylla SLO på 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å närmaste Azure-närvaropunkt 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 behö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 Front Door och säkerhetsmönster. Du kan konfigurera aviseringar som integreras med Azure Monitor. Programmet kan logga varje begäran och misslyckade hälsoavsökningar.
  • DDoS-skydd: Det har inbyggt layer 3-4 DDoS-skydd.
  • Nätverk för innehållsleverans: Relecloud får i uppdrag 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ände 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 lokal: 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 distribuera om appen.
  • Stöder Git-pipeline: Sanningskällan för konfigurationsdata som behövs för att vara en Git-lagringsplats. Pipelinen som behövs för att uppdatera data i det centrala konfigurationsarkivet.
  • Stöder hanterade identiteter: 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 det är en bättre säkerhetspraxis 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: Det underlättar granskningsåtkomst och genererar aviseringar när lagrade hemligheter ändras.
  • Integrering: Den tillhandahåller intern integrering med Azure-konfigurationsarkivet (App Configuration) och webbvärdplattformen (App Service).

• Lagringslösning: Granska Azure Storage-alternativen för att välja rätt lagringslösning baserat på dina krav. 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:

  • Säker åtkomst: Webbappen kan eliminera slutpunkter för åtkomst till lagring som exponeras för offentligt Internet med anonym åtkomst.
  • Kryptering: Den krypterar vilande data och under överföring.
  • Återhämtning: Den 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.

• Slutpunktssäkerhet: Använd Azure Private Link för att få åtkomst till lösningar för 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: Det ger programmet privat åtkomst till tjänster på Azure-plattformen och minskar nätverksavtrycket för datalager för att skydda mot dataläckage.
  • Minimalt arbete: De privata slutpunkterna stöder webbappplattformen och databasplattformen som webbappen använder. Båda plattformarna speglar befintliga lokala konfigurationer för minimal ändring.

• 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 på ett säkert sätt utan att exponera RDP/SSH-portar. Relecloud antog en nätverkstopologi för nav och ekrar 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 säkra distributioner från en jump-värd i DevOps-undernätet.

Kodvägledning

Om du vill flytta en webbapp till molnet måste du uppdatera webbappskoden med mönster för återförsök, mönster för kretsbrytarmönster och cache-aside-designmönster.

Figur 3. Designmönstrens roll.

Varje designmönster ger arbetsbelastningsdesignfördelar som överensstämmer med en av fler grundpelare i det väldefinierade ramverket. 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 hindrar ett program från att försöka utföra åtgärder som inte är tillfälliga. Implementera det här mönstret i alla utgående anrop till andra Azure-tjänster.

3. Cache-Aside-mönster: Cache-Aside-mönstret lägger till och hämtar från en cache oftare ä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 mönstret Försök igen kan du skicka misslyckade begäranden igen. Du kan också konfigurera fördröjningar i begäran och antalet försök innan felet släpps in.

• Använd inbyggda återförsöksmekanismer Använd den inbyggda återförsöksmekanism som de flesta Azure-tjänster har för att påskynda implementeringen. Referensimplementeringen använder till exempel anslutningsåterhämtningen i Entity Framework Core för att tillämpa återförsöksmönstret i begäranden på Azure SQL Database (se följande kod).

  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, till exempel Polly eller Microsoft.Extensions.Http.Resilience. Dessa bibliotek erbjuder 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 konstruerar ett objekt som anropar IConcertSearchService objektet (se följande kod).

  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 undviker att slösa cpu-cykler så att programmet behåller sin prestandaintegritet för slutanvändare.

Referensimplementeringen tillämpar till exempel kretsbrytarmönstret på alla begäranden till API:et. Den använder logiken HandleTransientHttpError 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 (se följande kod).

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 en 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 Distributed Redis Cache eftersom det förbättrar prestandan genom att minska databasfrågorna och det möjliggör icke-konsekventa sessioner så att lastbalanseraren kan distribuera trafik jämnt. Referensimplementeringen använder till exempel distribuerad Redis-cache. Metoden AddAzureCacheForRedis konfigurerar programmet att använda Azure Cache for Redis (se följande kod).

  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örstärka dess effektivitet. Använd Azure Monitor för att spåra databasens processor, minne och lagring. De här måtten hjälper dig att avgöra om du kan använda en mindre databas-SKU efter att cache-aside-mönstret har tillämpats. 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 (se följande kod).

  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. Fastställa den optimala uppdateringshastigheten baserat på datavolatilitet och användarbehov. Den här metoden säkerställer att programmet använder mönstret Cache-Aside för att ge både snabb åtkomst och aktuell information. Referensimplementeringen cachelagrar till exempel endast data i en timme och använder CreateConcertAsync metoden för att rensa cachenyckeln när data ändras (se följande kod).

  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 UpdateConcertAsync till exempel metoden för att hålla data i cacheminnet konsekventa (se följande kod).

  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 appregistrering. Microsoft Entra-ID kräver en programregistrering i den primära klientorganisationen. Programregistreringen säkerställer att de 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 tillhandahåller till exempel inbyggt autentiseringsstöd, så att du kan logga in användare och komma åt data genom att skriva minimal eller ingen kod i webbappen.

• Framtvinga auktorisering i programmet. Använd rollbaserade åtkomstkontroller (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, till exempel signaturer för delad åtkomst (SAS). 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 avgör vilka Azure-resursidentiteter som kan kommas åt, vad de kan göra med dessa resurser och vilka områden 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. Med just-in-time-åtkomst får användaridentiteter tillfälliga behörigheter för att utföra privilegierade uppgifter.

Implementera hanterade identiteter

Använd hanterade identiteter för alla Azure-tjänster som stöder hanterade identiteter. Med en hanterad identitet kan Azure-resurser (arbetsbelastningsidentiteter) autentisera till och interagera med andra Azure-tjänster utan att hantera autentiseringsuppgifter. Hybridsystem och äldre system kan behålla lokala autentiseringslösningar för att förenkla migreringen men bör övergå 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 konfigurationen ä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 de behörigheter som är viktiga för åtgärderna, 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å.

• Skydda å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 Authentication till exempel argumentet i SQL-databasen anslutningssträng så att App Service kan ansluta till SQL-databasen med 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 (se följande kod).

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

Rätt storleksmiljöer

Använd prestandanivåerna (SKU:er) för Azure-tjänster som uppfyller behoven i varje miljö utan överskott. Följ dessa rekommendationer om du vill ändra storlek på dina miljöer:

• 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, inaktivera onödiga tjänster och tillämpa rabatter som Priser för Azure Dev/Test. Se till att förproduktionsmiljöerna är tillräckligt lika produktionsmiljön för att undvika risker. Den här balansen säkerställer att testningen fortsätter att vara effektiv utan onödiga kostnader.

• Definiera SKU:er med hjälp av infrastruktur som kod (IaC). 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 säkerställer 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. Börja med cpu-användning som den första skalningsutlösaren om du inte känner till programmets skalningskrav. Förfina dina skalningsutlösare så att de innehåller andra mått, till exempel RAM-minne, nätverksdataflöde och disk-I/O. Målet är att matcha webbappens beteende för bättre prestanda.

• Ange en utskalningsbuffert. Ange skalningströsklarna som utlösare innan du når maximal kapacitet. 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 via CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Azure har färdiga 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 eller 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. Om du vill testa 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 enkelt integrerade 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 programtelemetri, till exempel dataflöde för begäranden, genomsnittlig varaktighet för begäran, fel och beroendeövervakning, utan kodändringar.

  Referensimplementeringen använder från NuGet-paketet Microsoft.ApplicationInsights.AspNetCore för att aktivera telemetrisamling (se följande kod).AddApplicationInsightsTelemetry

  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 (se följande kod).

  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 och 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 nödvändiga ändringar 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 servicenivåmå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 CAMS-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 3. Arkitektur för referensimplementeringen. Ladda ned en Visio-fil med den här arkitekturen.