Redigera

Dela via

Tillförlitligt webbappsmönster för .NET – Tillämpa mönstret

Azure App Service
Azure Front Door
Azure Cache for Redis
.NET

Den här artikeln visar hur du använder mönstret Reliable Web App. Mönstret Reliable Web App är en uppsättning principer och implementeringstekniker som definierar hur du ska ändra webbappar (omplatform) 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ör att underlätta tillämpningen av den här vägledningen finns det en referensimplementering av det Reliable Web App-mönster som du kan distribuera.

Diagram som visar arkitekturen för referensimplementeringen.Arkitektur för referensimplementeringen. Ladda ned en Visio-fil med den här arkitekturen.

I följande vägledning används referensimplementeringen som ett exempel hela vägen. Om du vill tillämpa mönstret Reliable Web App följer du dessa rekommendationer som är anpassade till grundpelarna i det väldefinierade ramverket:

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i checklistan designgranskning för tillförlitlighet. Mönstret Reliable Web App introducerar två viktiga designmönster på kodnivå för att förbättra tillförlitligheten: återförsöksmönstret och kretsbrytarmönstret.

Använd återförsöksmönstret

Återförsöksmönstret åtgärdar tillfälliga tjänststörningar, kallade tillfälliga fel, som vanligtvis löses inom några sekunder. Dessa fel beror ofta på tjänstbegränsning, dynamisk belastningsdistribution och nätverksproblem i molnmiljöer. Implementering av återförsöksmönstret innebär att misslyckade begäranden skickas igen, vilket tillåter konfigurerbara fördröjningar och försök innan fel medges.

Program som använder återförsöksmönstret bör integrera Azures klientprogramutvecklingspaket (SDK:er) och tjänstspecifika återförsöksmekanismer för ökad effektivitet. Program som saknar det här mönstret bör använda det med hjälp av följande vägledning.

Prova Azure-tjänsten och klient-SDK:erna först

De flesta Azure-tjänster och klient-SDK:er har en inbyggd mekanism för återförsök. Du bör använda den inbyggda mekanismen för återförsök för Azure-tjänster för att påskynda implementeringen.

Exempel: Referensimplementeringen använder 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 Polly-biblioteket när klientbiblioteket inte stöder återförsök

Du kan behöva göra anrop till ett beroende som inte är en Azure-tjänst eller som inte stöder återförsöksmönstret internt. I så fall bör du använda Polly-biblioteket för att implementera mönstret Försök igen. Polly är ett .NET-återhämtnings- och tillfälligt felhanteringsbibliotek. Med den kan du använda api:er för fluent för att beskriva beteendet på en central plats för programmet.

Exempel: Referensimplementeringen använder Polly för att konfigurera ASP.NET Core-beroendeinmatning. Polly tillämpar återförsöksmönstret varje gång koden skapar ett objekt som anropar IConcertSearchService objektet. I Polly-ramverket kallas det beteendet för en princip. Koden extraherar den GetRetryPolicy här principen i -metoden och GetRetryPolicy metoden tillämpar mönstret Försök igen varje gång klientwebbappen anropar webb-API:ets konsertsöktjänster (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);
}

Principhanteraren för instansen RelecloudApiConcertSearchService tillämpar återförsöksmönstret på alla begäranden till API:et. Den använder logiken HandleTransientHttpError för att identifiera HTTP-begäranden som den kan försöka igen på ett säkert sätt och sedan försöka begära igen baserat på konfigurationen. Den innehåller en del slumpmässighet för att jämna ut potentiella bursts i trafiken till API:et om ett fel inträffar.

Använda strömbrytarmönstret

Om du parkopplar mönster för återförsök och kretsbrytare utökas ett programs funktion för att hantera tjänststörningar som inte är relaterade till tillfälliga fel. Kretsbrytarmönstret hindrar ett program från att kontinuerligt försöka komma åt en tjänst som inte svarar. Kretsbrytarmönstret släpper programmet och undviker att slösa cpu-cykler så att programmet behåller sin prestandaintegritet för slutanvändarna.

Exempel: Referensimplementeringen lägger till kretsbrytarmönstret i GetCircuitBreakerPolicy metoden (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));
}

I koden tillämpar principhanteraren för instansen RelecloudApiConcertSearchService 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.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet. Mönstret Reliable Web App använder hanterade identiteter för att implementera identitetscentrerad säkerhet. Privata slutpunkter, brandvägg för webbprogram och begränsad åtkomst till webbappen ger en säker ingress.

Framtvinga minsta behörighet

För att säkerställa säkerhet och effektivitet beviljar du endast användare (användaridentiteter) och Azure-tjänster (arbetsbelastningsidentiteter) de behörigheter de behöver.

Tilldela behörigheter till användaridentiteter

Utvärdera programmets behov av att definiera en uppsättning roller som täcker alla användaråtgärder utan överlappning. Mappa varje användare till den lämpligaste rollen. Se till att de endast får åtkomst till vad som är nödvändigt för deras uppgifter.

Tilldela behörigheter till arbetsbelastningsidentiteter

Bevilja endast 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.

  • Föredrar rollbaserad åtkomstkontroll (RBAC). Börja alltid med Azure RBAC för att tilldela behörigheter. Den ger exakt kontroll, vilket säkerställer att åtkomsten är både granskningsbar och detaljerad. Använd Azure RBAC för att endast bevilja de behörigheter som krävs för att tjänsten ska kunna utföra sina avsedda funktioner.

  • Komplettera med åtkomstkontroller på Azure-tjänstnivå. Om Azure RBAC inte täcker ett specifikt scenario kan du komplettera med åtkomstprinciper på Azure-tjänstnivå.

Konfigurera användarautentisering och auktorisering

Autentisering och auktorisering är viktiga aspekter av webbprogramsäkerhet. Autentisering är en process för att verifiera en användares identitet. Auktorisering anger vilka åtgärder en användare får utföra i programmet. Målet är att implementera autentisering och auktorisering utan att försvaga din säkerhetsstatus. För att uppnå det här målet måste du använda funktionerna i Azure-programplattformen (Azure App Service) och identitetsprovidern (Microsoft Entra-ID).

Konfigurera användarautentisering

Skydda din webbapp genom att aktivera användarautentisering via plattformens funktioner. Azure App Service stöder autentisering med identitetsprovidrar som Microsoft Entra-ID, vilket avlastar autentiseringsarbetsbelastningen från din kod.

Konfigurera tjänstautentisering och auktorisering

Konfigurera tjänstautentisering och auktorisering så att tjänsterna i din miljö har behörighet att utföra nödvändiga funktioner. Använd hanterade identiteter i Microsoft Entra-ID för att automatisera skapandet och hanteringen av tjänstidentiteter, vilket eliminerar manuell hantering av autentiseringsuppgifter. Med en hanterad identitet kan din webbapp få säker åtkomst till Azure-tjänster, till exempel Azure Key Vault och databaser. Det underlättar även CI/CD-pipelineintegreringar för distributioner till Azure App Service. Men i scenarier som hybriddistributioner eller med äldre system fortsätter du att använda dina lokala autentiseringslösningar för att förenkla migreringen. Övergå till hanterade identiteter när systemet är redo för en modern identitetshanteringsmetod. Mer information finns i Övervaka hanterade identiteter.

Använd DefaultAzureCredential för att konfigurera kod

Använd DefaultAzureCredential för att ange autentiseringsuppgifter för lokal utveckling och hanterade identiteter i molnet. DefaultAzureCredential genererar ett TokenCredential för anskaffning av OAuth-token. Den hanterar de flesta Azure SDK-scenarier och Microsoft-klientbibliotek. Den identifierar programmets miljö för att använda rätt identitet och begär åtkomsttoken efter behov. DefaultAzureCredential effektiviserar autentisering för Azure-distribuerade program Mer information finns i StandardAzureCredential.

Exempel: Referensimplementeringen använder DefaultAzureCredential klassen under starten för att aktivera användning av hanterad identitet mellan webb-API:et och Key Vault (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 Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Använda infrastruktur som kod för att skapa hanterade identiteter

Du bör använda Bicep-mallar för att skapa och konfigurera Azure-infrastrukturen för att stödja hanterade identiteter. Hanterade identiteter använder inte hemligheter eller lösenord, så du behöver inte Key Vault eller en strategi för hemlig rotation för att säkerställa integriteten. Du kan lagra niska veze i App Configuration Service.

Exempel: Referensimplementeringen använder Bicep-mallar för att (1) skapa den hanterade identiteten, (2) associera identiteten med webbappen och (3) ge identiteten behörighet att komma åt SQL-databasen. Argumentet Authentication i niska veze instruerar Microsoft-klientbiblioteket att ansluta med en hanterad identitet (se följande kod).

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

Mer information finns i Ansluta till SQL-databas från .NET App Service.

Använda ett centralt hemlighetsarkiv för att hantera hemligheter

När du flyttar ditt program till molnet använder du Azure Key Vault för att lagra alla sådana hemligheter på ett säkert sätt. Den här centraliserade lagringsplatsen erbjuder säker lagring, nyckelrotation, åtkomstgranskning och övervakning för tjänster som inte stöder hanterade identiteter. För programkonfigurationer rekommenderas Azure App Configuration .

Exempel: Referensimplementeringen lagrar följande hemligheter i Key Vault: (1) Användarnamn och lösenord för PostgreSQL-databasen, (2) Redis Cache-lösenord och (3) klienthemligheten för Microsoft Entra-ID som är associerat med Microsoft Authentication Library (MSAL).

Placera inte Key Vault i HTTP-begärandeflödet

Läs in hemligheter från Key Vault vid programstart i stället för under varje HTTP-begäran. Key Vault är avsett för säker lagring och hämtning av känsliga data under distributionen. Högfrekvent åtkomst i HTTP-begäranden kan överskrida Key Vaults dataflödesfunktioner, vilket leder till begärandebegränsningar och HTTP-statuskod 429-fel. Mer information finns i Transaktionsgränser för Key Vault.

Använda en metod för att komma åt hemligheter i Key Vault

När du konfigurerar en webbapp för åtkomst till hemligheter i Key Vault har du två primära alternativ:

  • App Service App-inställning: Använd en appinställning i App Service för att mata in hemligheten direkt som en miljövariabel.

  • Direkthemlighetsreferens: Referera direkt till hemligheten i programkoden. Lägg till en specifik referens i appens egenskapsfil, till exempel application.properties för Java-program, så att appen kan kommunicera med Key Vault.

Det är viktigt att välja en av dessa metoder och hålla fast vid den för enkelhetens skull och för att undvika onödig komplexitet.

Föredrar tillfälliga åtkomstmetoder

Använd tillfälliga behörigheter för att skydda mot obehörig åtkomst och intrång. Använd signaturer för delad åtkomst (SAS) för tillfällig åtkomst. 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 Microsoft Entra-autentiseringsuppgifter och som inte kräver någon lagringskontonyckel.

Använda privata slutpunkter

Använd privata slutpunkter i alla produktionsmiljöer för alla Azure-tjänster som stöds. Privata slutpunkter tillhandahåller privata anslutningar mellan resurser i ett virtuellt Azure-nätverk och Azure-tjänster. Som standard går kommunikationen till de flesta Azure-tjänster över det offentliga Internet. Privata slutpunkter kräver inga kodändringar, appkonfigurationer eller niska veze. Mer information finns i Skapa en privat slutpunkt och metodtips för slutpunktssäkerhet.

Exempel: Azure App Configuration, Azure SQL Database, Azure Cache for Redis, Azure Storage, Azure App Service och Key Vault använder en privat slutpunkt.

Använda brandväggen för webbprogram och begränsa inkommande Internettrafik

All inkommande Internettrafik till webbappen måste passera genom en brandvägg för webbprogram för att skydda mot vanliga webbexploateringar. Tvinga all inkommande Internettrafik att passera genom den offentliga lastbalanseraren, om du har en, och brandväggen för webbprogrammet.

Exempel: Referensimplementeringen tvingar all inkommande Internettrafik via Front Door och Azure Web Application Firewall. Bevara det ursprungliga HTTP-värdnamnet i produktion.

Konfigurera databassäkerhet

Åtkomst på administratörsnivå till databasen ger behörighet att utföra privilegierade åtgärder. Privilegierade åtgärder omfattar att skapa och ta bort databaser, ändra tabellscheman eller ändra användarbehörigheter. Utvecklare behöver ofta åtkomst på administratörsnivå för att underhålla databasen eller felsöka problem.

  • Undvik permanent utökade behörigheter. Du bör endast ge utvecklarna just-in-time-åtkomst för att utföra privilegierade åtgärder. Med just-in-time-åtkomst får användare tillfälliga behörigheter för att utföra privilegierade uppgifter

  • Ge inte programmet utökade behörigheter. Du bör inte bevilja åtkomst på administratörsnivå till programidentiteten. Du bör konfigurera minst privilegierad åtkomst för programmet till databasen. Det begränsar explosionsradien för buggar och säkerhetsöverträdelser.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och hanteringskostnader. Mer information finns i checklistan Designgranskning för kostnadsoptimering. Mönstret Reliable Web App implementerar rightsizing-tekniker, automatisk skalning och effektiv resursanvändning för en mer kostnadsoptimerad webbapp.

Rightsize-resurser för varje miljö

Förstå de olika prestandanivåerna för Azure-tjänster och använd endast lämplig SKU för varje miljös behov. Produktionsmiljöer behöver SKU:er som uppfyller serviceavtalen (SLA), funktioner och skalning som behövs för produktion. Icke-produktionsmiljöer behöver vanligtvis inte samma funktioner. För extra besparingar kan du överväga prisalternativ för Azure Dev/Test, Azure-reservationer och Azure-sparplaner för beräkning.

Exempel: Referensimplementeringen använder Bicep-parametrar för att utlösa resursdistributionskonfigurationer. En av dessa parametrar anger de resursnivåer (SKU:er) som ska distribueras. Webbappen använder de mer högpresterande och dyra SKU:erna för produktionsmiljöerna och billigare SKU:er för icke-produktionsmiljön (se följande kod).

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

Använda automatisk skalning

Autoskalning automatiserar horisontell skalning för produktionsmiljöer. Autoskalning baserat på prestandamått. Prestandautlösare för CPU-användning är en bra utgångspunkt om du inte förstår skalningskriterierna för ditt program. Du måste konfigurera och anpassa skalningsutlösare (CPU, RAM, nätverk och disk) för att motsvara beteendet för ditt webbprogram. Skala inte lodrätt för att möta frekventa förändringar i efterfrågan. Det är mindre kostnadseffektivt. Mer information finns i Skala i Azure App Service och Autoskala i Microsoft Azure.

Exempel: Referensimplementeringen använder följande konfiguration i Bicep-mallen. Den skapar en autoskalningsregel för Azure App Service. Regeln skalar upp till 10 instanser och är som standard en instans. Den använder CPU-användning som utlösare för att skala in och ut. Webbappens värdplattform skalas ut med 85 % CPU-användning och skalas in med 60 %. Utskalningsinställningen på 85 % i stället för en procentandel närmare 100 % ger en buffert som skyddar mot ackumulerad användartrafik som orsakas av klibbiga sessioner. Det skyddar också mot höga trafiktoppar genom att skala tidigt för att undvika maximal CPU-användning. Dessa autoskalningsregler är inte universella (se följande kod).

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

Använda resurser effektivt

  • Använd delade tjänster. Att centralisera och dela vissa resurser ger kostnadsoptimering och lägre hanteringskostnader. Placera delade nätverksresurser i det virtuella hubbnätverket.

    Exempel: Referensimplementeringen placerar Azure Firewall, Azure Bastion och Key Vault i det virtuella hubbnätverket.

  • Ta bort oanvända miljöer. Ta bort icke-produktionsmiljöer efter timmar eller under helgdagar för att optimera kostnaden. Du kan använda infrastruktur som kod för att ta bort Azure-resurser och hela miljöer. Ta bort deklarationen för den resurs som du vill ta bort från Bicep-mallen. Använd konsekvensåtgärden för att förhandsgranska ändringarna innan de börjar gälla. Säkerhetskopiera data som du behöver senare. Förstå beroendena för den resurs som du tar bort. Om det finns beroenden kan du också behöva uppdatera eller ta bort dessa resurser. Mer information finns i Bicep-distributionens konsekvensåtgärd.

  • Samlokalisera funktioner. Där det finns outnyttjad kapacitet kan du samplacera programresurser och funktioner på en enda Azure-resurs. Till exempel kan flera webbappar använda en enskild server (App Service-plan) eller så kan en enda cache ha stöd för flera datatyper.

    Exempel: Referensimplementeringen använder en enda Azure Cache for Redis-instans för sessionshantering i både klientdelen (lagra kundvagn och MSAL-token) och serverdelsappar (med kommande konsertdata). Den väljer den minsta Redis-SKU:n och erbjuder mer kapacitet än nödvändigt och används effektivt genom att använda flera datatyper för att kontrollera kostnaderna.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklista för designgranskning för driftskvalitet. Mönstret Reliable Web App implementerar infrastruktur som kod för infrastrukturdistributioner och övervakning för observerbarhet.

Automatisera distribution

Använd en CI/CD-pipeline för att distribuera ändringar från källkontroll till produktion. Om du använder Azure DevOps bör du använda Azure Pipelines. Om du använder GitHub använder du GitHub-åtgärder. Azure har stöd för ARM-mallar (JSON), Bicep och Terraform och har mallar för varje Azure-resurs För mer information, se Bicep, Azure Resource Manager och Terraform-mallar och repeterbar infrastruktur.

Exempel: Referensimplementeringen använder Azure Dev CLI och infrastruktur som kod (Bicep-mallar) för att skapa Azure-resurser, konfigurera konfiguration och distribuera nödvändiga resurser.

Konfigurera övervakning

Om du vill övervaka din webbapp samlar du in och analyserar mått och loggar från din programkod, infrastruktur (körning) och plattformen (Azure-resurser). Lägg till en diagnostikinställning för varje Azure-resurs i din arkitektur. Varje Azure-tjänst har en annan uppsättning loggar och mått som du kan samla in. Mer information finns i Övervaka plattformen och Övervaka App Service.

Övervaka baslinjemått

Använd Azure Application Insights för att spåra baslinjemått, till exempel dataflöde för begäranden, genomsnittlig varaktighet för begäran, fel och beroendeövervakning. Använd AddApplicationInsightsTelemetry från NuGet-paketet Microsoft.ApplicationInsights.AspNetCore för att aktivera telemetrisamling. Mer information finns i Aktivera Application Insights-telemetri och beroendeinmatning i .NET.

Exempel: Referensimplementeringen använder kod för att konfigurera baslinjemått i Application Insights (se följande kod).

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

Skapa anpassad telemetri efter behov

Använd Application Insights för att samla in anpassad telemetri för att bättre förstå dina webbappsanvändare. Skapa en instans av TelemetryClient klassen och använd TelemetryClient metoderna för att skapa rätt mått. Omvandla frågan till en Azure-instrumentpanelswidget.

Exempel: Referensimplementeringen lägger till mått som hjälper åtgärdsteamet att identifiera att webbappen slutför transaktionerna. Den verifierar att webbappen är online genom att övervaka om kunder kan göra beställningar, inte genom att mäta antalet begäranden eller CPU-användning. Referensimplementeringen använder TelemetryClient via beroendeinmatning och TrackEvent metoden för att samla in telemetri om händelser relaterade till kundvagnsaktivitet. Telemetrin spårar de biljetter som användare lägger till, tar bort och köper (se följande kod).

  • AddToCart räknar hur många gånger användarna lägger till en viss biljett (ConcertID) i kundvagnen.
  • RemoveFromCart registrerar biljetter som användarna tar bort från kundvagnen.
  • CheckoutCart registrerar en händelse varje gång en användare köper en biljett.

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

Mer information finns i:

Samla in loggbaserade mått

Spåra loggbaserade mått för att få mer insyn i viktiga programhälsa och mått. Du kan använda KQL-frågor (Kusto Query Language) i Application Insights för att hitta och organisera data. Mer information finns i Loggbaserade mått i Azure Application Insights och Loggbaserade och föraggregerade mått i Application Insights.

Aktivera plattformsdiagnostik

Med en diagnostikinställning i Azure kan du ange de plattformsloggar och mått som du vill samla in och var de ska lagras. Plattformsloggar är inbyggda loggar som tillhandahåller diagnostik- och granskningsinformation. Du kan aktivera plattformsdiagnostik för de flesta Azure-tjänster, men varje tjänst definierar sina egna loggkategorier. Olika Azure-tjänster har loggkategorier att välja.

  • Aktivera diagnostik för alla tjänster som stöds. Azure-tjänster skapar plattformsloggar automatiskt, men tjänsten lagrar dem inte automatiskt. Du måste aktivera diagnostikinställningen för varje tjänst och du bör aktivera den för varje Azure-tjänst som stöder diagnostik.

  • Skicka diagnostik till samma mål som programloggarna. När du aktiverar diagnostik väljer du de loggar som du vill samla in och var de ska skickas. Du bör skicka plattformsloggarna till samma mål som programloggarna så att du kan korrelera de två datauppsättningarna.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i checklistan designgranskning för prestandaeffektivitet. Mönstret Reliable Web App använder mönstret Cache-Aside för att minimera svarstiden för data med hög begäran.

Använd mönstret Cache-Aside

Cache-Aside-mönstret är en cachelagringsstrategi som förbättrar 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. När webbappen tar emot en databegäran söker den först igenom cachen. Om data saknas hämtar de dem från databasen, svarar på begäran och uppdaterar cacheminnet därefter. Den här metoden förkortar svarstiderna och förbättrar dataflödet och minskar behovet av mer skalning. Det ökar också tjänstens tillgänglighet genom att minska belastningen på det primära dataarkivet och minimera avbrottsriskerna.

Exempel: Referensimplementeringen förbättrar programeffektiviteten genom att cachelagra kritiska data, till exempel information för kommande konserter som är avgörande för biljettförsäljning. Den använder ASP.NET Cores distribuerade minnescachen för minnesintern lagring av objekt. Programmet använder automatiskt Azure Cache for Redis när det hittar en specifik niska veze. Den stöder även lokala utvecklingsmiljöer utan Redis för att förenkla konfigurationen och minska kostnaderna och komplexiteten. 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();
    }
}

Mer information finns i Distribuerad cachelagring i metoden ASP.NET Core och AddDistributedMemoryCache.

Cachelagrade data med stort behov

Prioritera cachelagring för de data som används oftast. Identifiera viktiga datapunkter som skapar användarengagemang och systemprestanda. Implementera cachelagringsstrategier specifikt för dessa områden för att optimera effektiviteten i Cache-Aside-mönstret, vilket avsevärt minskar svarstiden och databasbelastningen. 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.

Exempel: Referensimplementeringen cachelagrar data som stöder kommande konserter. Sidan Kommande konserter skapar flest frågor till SQL Database och ger konsekventa utdata för varje besök. Cache-Aside-mönstret cachelagrar data efter den första begäran för den här sidan för att minska belastningen på databasen. Följande kod använder GetUpcomingConcertsAsync metoden för att hämta data till Redis-cachen från SQL Database. Metoden fyller cachen med de senaste konserterna. Metoden filtrerar efter tid, sorterar data och returnerar data till kontrollanten för att visa resultatet (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.

Exempel: Referensimplementeringen cachelagrar endast data i en timme. Den har en process för att rensa cachenyckeln när data ändras. Metoden CreateConcertAsync rensar cachenyckeln (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);
}

Säkerställa datakonsekvens

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.

Exempel: Referensimplementeringen använder UpdateConcertAsync 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();
}

Testa databasprestanda

Databasprestanda kan påverka prestanda och skalbarhet för ett program. Det är viktigt att testa databasens prestanda för att säkerställa att den är optimerad. Några viktiga överväganden är att välja rätt molnregion, anslutningspooler, cache-aside-mönster och optimera frågor.

  • Testa nätverkshopp. Att flytta ett program till molnet kan ge databasen extra nätverkshopp och svarstider. Du bör testa för extra hopp som den nya molnmiljön introducerar.

  • Upprätta en baslinje för prestanda. Du bör använda lokala prestandamått som den första baslinjen för att jämföra programprestanda i molnet.

Nästa steg

Distribuera referensimplementeringen genom att följa anvisningarna på GitHub-lagringsplatsen. Använd följande resurser för att lära dig mer om .NET-program, webbappar, bästa praxis för molnet och migrering.

Uppgradera .NET Framework-program

Referensimplementeringen distribueras till en App Service som kör Windows, men den kan köras på Linux. Med App Service Windows-plattformen kan du flytta .NET Framework-webbappar till Azure utan att uppgradera till nyare ramverksversioner. Information om Linux App Service-planer eller nya funktioner och prestandaförbättringar som lagts till i de senaste versionerna av .NET finns i följande vägledning.

Introduktion till webbappar i Azure

En praktisk introduktion till .NET-webbprogram i Azure finns i den här vägledningen för att distribuera ett grundläggande .NET-webbprogram.

Metodtips för molnet

Vägledning för Azure-implementering och arkitektur finns i:

  • Cloud Adoption Framework. Kan hjälpa din organisation att förbereda och köra en strategi för att skapa lösningar i Azure.
  • Välkonstruerat ramverk. En uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning.

För program som kräver ett högre SLO än reliable web app-mönstret, se verksamhetskritiska arbetsbelastningar.

Vägledning för migrering

Följande verktyg och resurser kan hjälpa dig att migrera lokala resurser till Azure.