Spolehlivý vzor webové aplikace pro .NET – Použití vzoru

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

V tomto článku se dozvíte, jak použít model Reliable Web App. Model Reliable Web App je sada principů a technik implementace, které definují, jak byste při migraci do cloudu měli upravovat webové aplikace (replatformovat). Zaměřuje se na minimální aktualizace kódu, které je potřeba udělat, aby byly úspěšné v cloudu.

Pro usnadnění použití těchto pokynů existuje referenční implementace modelu Reliable Web App, který můžete nasadit.

Architektura referenční implementace Stáhněte si soubor Visia této architektury.

Následující doprovodné materiály používají referenční implementaci jako příklad v celém příkladu. Pokud chcete použít model Spolehlivé webové aplikace, postupujte podle těchto doporučení, která odpovídají pilířům dobře navržená architektura:

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost. Model Reliable Web App zavádí na úrovni kódu dva klíčové vzory návrhu, které zvyšují spolehlivost: vzor opakování a model Jistič.

Použití vzoru Opakování

Vzor opakování řeší dočasné přerušení služeb, označované jako přechodné chyby, které se obvykle řeší během několika sekund. Tyto chyby často vyplývají z omezování služeb, dynamické distribuce zatížení a problémů se sítí v cloudových prostředích. Implementace modelu opakování zahrnuje opětovné odeslání neúspěšných požadavků, což umožňuje konfigurovatelné zpoždění a pokusy před zřetězením selhání.

Aplikace, které používají model opakování, by měly integrovat sady SDK (Client Software Development Kit) Azure a mechanismy opakování specifické pro služby, aby se zlepšila efektivita. Aplikace, které tento model nemají, by ho měly přijmout s využitím následujících doprovodných materiálů.

Nejprve vyzkoušejte službu Azure a klientské sady SDK.

Většina služeb Azure a klientských sad SDK má integrovaný mechanismus opakování. K urychlení implementace byste měli použít integrovaný mechanismus opakování pro služby Azure.

Příklad: Referenční implementace používá odolnost připojení v Entity Framework Core k použití vzoru opakování v požadavcích na Azure SQL Database (viz následující kód).

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

Pokud klientská knihovna nepodporuje opakování, použijte knihovnu Polly.

Možná budete muset volat závislost, která není službou Azure nebo nepodporuje model opakování nativně. V takovém případě byste k implementaci vzoru opakování měli použít knihovnu Polly. Polly je odolnost rozhraní .NET a knihovna pro zpracování přechodných chyb. S ním můžete pomocí rozhraní API fluent popsat chování v centrálním umístění aplikace.

Příklad: Referenční implementace používá Polly k nastavení injektáže závislostí ASP.NET Core. Polly vynucuje vzor opakování pokaždé, když kód vytvoří objekt, který volá IConcertSearchService objekt. V rámci Polly se toto chování označuje jako zásady. Kód extrahuje tuto zásadu GetRetryPolicy v metodě a GetRetryPolicy metoda použije vzor Opakování pokaždé, když front-end webová aplikace volá služby vyhledávání koncertů webového rozhraní API (viz následující kód).

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

Obslužná rutina zásad pro RelecloudApiConcertSearchService instanci použije vzor Opakování u všech požadavků na rozhraní API. Používá logiku HandleTransientHttpError k detekci požadavků HTTP, které může bezpečně opakovat a pak opakovat požadavek na základě konfigurace. Zahrnuje určitou náhodnost pro vyhlazení potenciálních nárůstů provozu do rozhraní API, pokud dojde k chybě.

Použití modelu Jistič

Spárování vzorů opakování a jističe rozšiřuje schopnost aplikace zpracovávat přerušení služeb, které nesouvisí s přechodnými chybami. Model Jistič brání aplikaci v nepřetržitém pokusu o přístup k nereagující službě. Model Jistič uvolní aplikaci a zabraňuje plýtvání cykly procesoru, aby aplikace zachovala integritu výkonu pro koncové uživatele.

Příklad: Referenční implementace přidá do GetCircuitBreakerPolicy metody model Jistič (viz následující kód).

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

V kódu obslužná rutina zásad pro RelecloudApiConcertSearchService instanci aplikuje model Jistič na všechny požadavky na rozhraní API. Používá logiku HandleTransientHttpError k detekci požadavků HTTP, které může bezpečně opakovat, ale omezuje počet agregovaných chyb v zadaném časovém období.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení. Model Reliable Web App používá spravované identity k implementaci zabezpečení zaměřeného na identitu. Privátní koncové body, firewall webových aplikací a omezený přístup k webové aplikaci poskytují zabezpečený příchozí přenos dat.

Vynucení nejnižších oprávnění

Pokud chcete zajistit zabezpečení a efektivitu, udělte uživatelům (identitám uživatelů) a službám Azure (identitám úloh) oprávnění, která potřebují.

Přiřazení oprávnění identitám uživatelů

Vyhodnoťte, že aplikace potřebuje definovat sadu rolí, které pokrývají všechny akce uživatelů bez překrývání. Namapujte každého uživatele na nejvhodnější roli. Zajistěte, aby získali přístup pouze k tomu, co je nezbytné pro své povinnosti.

Přiřazení oprávnění identitám úloh

Udělte pouze oprávnění, která jsou důležitá pro operace, jako jsou akce CRUD v databázích nebo přístup k tajným kódům. Oprávnění identit úloh jsou trvalá, takže identitám úloh nemůžete poskytnout oprávnění za běhu ani krátkodobé oprávnění.

Upřednostněte řízení přístupu na základě role (RBAC). Vždy začněte s Azure RBAC a přiřaďte oprávnění. Nabízí přesnou kontrolu a zajišťuje, aby byl přístup auditovatelný i podrobný. Pomocí Azure RBAC udělte pouze oprávnění potřebná ke službě k provádění zamýšlených funkcí.
Dodatek k řízení přístupu na úrovni služby Azure Pokud Azure RBAC nepokrývá konkrétní scénář, doplňte zásady přístupu na úrovni služeb Azure.

Konfigurace ověřování a autorizace uživatelů

Ověřování a autorizace jsou důležité aspekty zabezpečení webových aplikací. Ověřování je proces ověření identity uživatele. Autorizace určuje akce, které může uživatel provádět v rámci aplikace. Cílem je implementovat ověřování a autorizaci bez oslabování stavu zabezpečení. K splnění tohoto cíle musíte použít funkce aplikační platformy Azure (Aplikace Azure Service) a zprostředkovatele identity (Microsoft Entra ID).

Konfigurace ověřování uživatelů

Zabezpečte webovou aplikaci povolením ověřování uživatelů prostřednictvím funkcí vaší platformy. Aplikace Azure Služba podporuje ověřování pomocí zprostředkovatelů identity, jako je ID Microsoft Entra, a tím přesměrovává úlohu ověřování z vašeho kódu.

Konfigurace ověřování a autorizace služby

Nakonfigurujte ověřování a autorizaci služby, aby služby ve vašem prostředí měly oprávnění k provádění nezbytných funkcí. Použití spravovaných identit v Microsoft Entra ID k automatizaci vytváření a správy identit služeb, odstranění ruční správy přihlašovacích údajů. Spravovaná identita umožňuje webové aplikaci bezpečně přistupovat ke službám Azure, jako je Azure Key Vault a databáze. Také usnadňuje integraci kanálů CI/CD pro nasazení do služby Aplikace Azure Service. Ve scénářích, jako jsou hybridní nasazení nebo starší systémy, ale k zjednodušení migrace pokračujte v používání místních řešení ověřování. Přechod na spravované identity, když je váš systém připravený na moderní přístup správy identit. Další informace najdete v tématu Monitorování spravovaných identit.

Nastavení kódu pomocí DefaultAzureCredential

Slouží DefaultAzureCredential k zadání přihlašovacích údajů pro místní vývoj a spravované identity v cloudu. DefaultAzureCredential vygeneruje pro získání tokenu TokenCredential OAuth. Zpracovává většinu scénářů sady Azure SDK a klientských knihoven Microsoftu. Zjistí prostředí aplikace, aby používalo správnou identitu a podle potřeby požaduje přístupové tokeny. DefaultAzureCredential zjednodušuje ověřování pro aplikace nasazené v Azure. Další informace najdete v tématu DefaultAzureCredential.

Příklad: Referenční implementace používá DefaultAzureCredential třídu během spuštění k povolení použití spravované identity mezi webovým rozhraním API a službou Key Vault (viz následující kód).

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

Použití infrastruktury jako kódu k vytváření spravovaných identit

K vytvoření a konfiguraci infrastruktury Azure pro podporu spravovaných identit byste měli použít šablony Bicep. Spravované identity nepoužívají tajné kódy ani hesla, takže k zajištění integrity nepotřebujete Key Vault ani strategii obměny tajných kódů. Připojovací řetězec můžete uložit ve službě App Configuration Service.

Příklad: Referenční implementace používá šablony Bicep k vytvoření spravované identity (2) přidružení identity k webové aplikaci a (3) udělit identitě oprávnění pro přístup k databázi SQL. Argument Authentication v připojovací řetězec říká klientské knihovně Microsoftu, aby se připojila ke spravované identitě (viz následující kód).

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

Další informace najdete v tématu Připojení do databáze SQL z .NET App Service.

Použití centrálního úložiště tajných kódů ke správě tajných kódů

Když přesunete aplikaci do cloudu, použijte Azure Key Vault k bezpečnému ukládání všech těchto tajných kódů. Toto centralizované úložiště nabízí zabezpečené úložiště, obměnu klíčů, auditování přístupu a monitorování služeb, které nepodporují spravované identity. Pro konfigurace aplikací se doporučuje Aplikace Azure Konfigurace.

Příklad: Referenční implementace ukládá následující tajné kódy ve službě Key Vault: (1) Uživatelské jméno a heslo databáze PostgreSQL, (2) heslo služby Redis Cache a (3) tajný klíč klienta pro microsoft Entra ID přidružené k implementaci knihovny MICROSOFT Authentication Library (MSAL).

Neumisťujte službu Key Vault do toku požadavku HTTP

Načtěte tajné kódy ze služby Key Vault při spuštění aplikace místo během každého požadavku HTTP. Key Vault je určený k bezpečnému ukládání a načítání citlivých dat během nasazování. Vysoká frekvence přístupu v rámci požadavků HTTP může překročit možnosti propustnosti služby Key Vault, což vede k omezením požadavků a chybám stavového kódu HTTP 429. Další informace najdete v tématu Omezení transakcí služby Key Vault.

Použití jedné metody pro přístup k tajným kódům ve službě Key Vault

Při konfiguraci webové aplikace pro přístup k tajným kódům ve službě Key Vault máte dvě primární možnosti:

Nastavení aplikace služby App Service: Pomocí nastavení aplikace ve službě App Service můžete tajný kód vložit přímo jako proměnnou prostředí.
Přímý odkaz na tajný kód: Přímo odkazujte na tajný kód v kódu vaší aplikace. Přidejte do souboru vlastností aplikace konkrétní odkaz, například application.properties pro aplikace v Javě, aby aplikace komunikuje se službou Key Vault.

Je důležité zvolit jednu z těchto metod a držet se s ní kvůli jednoduchosti a vyhnout se zbytečné složitosti.

Preferovat metody dočasného přístupu

Pomocí dočasných oprávnění můžete chránit před neoprávněným přístupem a porušením zabezpečení. Pro dočasný přístup použijte sdílené přístupové podpisy (SAS). Sas delegování uživatele použijte k maximalizaci zabezpečení při udělování dočasného přístupu. Je to jediný SAS, který používá přihlašovací údaje Microsoft Entra a nevyžaduje klíč účtu úložiště.

Použití privátních koncových bodů

Pro všechny podporované služby Azure používejte privátní koncové body ve všech produkčních prostředích. Privátní koncové body poskytují privátní připojení mezi prostředky ve virtuální síti Azure a službami Azure. Ve výchozím nastavení komunikace s většinou služeb Azure překračuje veřejný internet. Privátní koncové body nevyžadují žádné změny kódu, konfigurace aplikací ani připojovací řetězec. Další informace najdete v tématu Vytvoření privátního koncového bodu a osvědčených postupů pro zabezpečení koncových bodů.

Příklad: Aplikace Azure Konfigurace, Azure SQL Database, Azure Cache for Redis, Azure Storage, Aplikace Azure Service a Key Vault používají privátní koncový bod.

Použití firewallu webových aplikací a omezení příchozího internetového provozu

Veškerý příchozí internetový provoz do webové aplikace musí projít bránou firewall webových aplikací, aby se chránil před běžnými webovými zneužitími. Vynutit průchod veškerého příchozího internetového provozu přes veřejný nástroj pro vyrovnávání zatížení, pokud ho máte, a bránu firewall webových aplikací.

Příklad: Referenční implementace vynutí veškerý příchozí internetový provoz prostřednictvím služby Front Door a brány firewall webových aplikací Azure. V produkčním prostředí ponechte původní název hostitele HTTP.

Konfigurace zabezpečení databáze

Správa istrator-level přístup k databázi uděluje oprávnění k provádění privilegovaných operací. Mezi privilegované operace patří vytváření a odstraňování databází, úpravy schémat tabulek nebo změna uživatelských oprávnění. Vývojáři často potřebují přístup na úrovni správce, aby mohli udržovat databázi nebo řešit problémy.

Vyhněte se trvalým zvýšeným oprávněním. Vývojářům byste měli udělit přístup jen za běhu k provádění privilegovaných operací. S přístupem za běhu dostanou uživatelé dočasná oprávnění k provádění privilegovaných úloh.
Neudělujte aplikaci zvýšená oprávnění. Neměli byste udělovat přístup na úrovni správce k identitě aplikace. Pro aplikaci byste měli nakonfigurovat přístup s nejnižšími oprávněními k databázi. Omezuje poloměr výbuchu chyb a porušení zabezpečení.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a režijní náklady na správu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů. Model Reliable Web App implementuje techniky, automatické škálování a efektivní využití prostředků pro cenově optimalizovanou webovou aplikaci.

Rightsize resources for each environment

Seznamte se s různými úrovněmi výkonu služeb Azure a používejte pouze odpovídající skladovou položku pro potřeby každého prostředí. Produkční prostředí potřebují skladové položky, které splňují smlouvy o úrovni služeb (SLA), funkce a škálování potřebné pro produkční prostředí. Neprodukční prostředí obvykle nepotřebují stejné funkce. Pokud potřebujete další úspory, zvažte cenové možnosti azure pro vývoj/testování, rezervace Azure a plány úspor Azure pro výpočetní prostředky.

Příklad: Referenční implementace používá k aktivaci konfigurací nasazení prostředků parametry Bicep. Jeden z těchto parametrů označuje úrovně prostředků (SKU), které se mají nasadit. Webová aplikace používá výkonnější a dražší skladové položky pro produkční prostředí a levnější skladové položky pro neprodukční prostředí (viz následující kód).

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

Použití automatického škálování

Automatické škálování automatizuje horizontální škálování pro produkční prostředí. Automatické škálování na základě metrik výkonu Triggery výkonu využití procesoru jsou dobrým výchozím bodem, pokud nerozumíte kritériím škálování vaší aplikace. Musíte nakonfigurovat a přizpůsobit triggery škálování (procesor, paměť RAM, síť a disk), aby odpovídaly chování vaší webové aplikace. Neškusujte vertikálně tak, aby splňovaly časté změny v poptávce. Je méně nákladově efektivní. Další informace najdete v tématu Škálování ve službě Aplikace Azure Service a automatickém škálování v Microsoft Azure.

Příklad: Referenční implementace používá následující konfiguraci v šabloně Bicep. Vytvoří pravidlo automatického škálování pro službu Aplikace Azure Service. Pravidlo škáluje až 10 instancí a ve výchozím nastavení se nastaví na jednu instanci. Využívá využití procesoru jako trigger pro horizontální navýšení nebo snížení kapacity. Webová aplikace hostující platformu škáluje na 85 % využití procesoru a škáluje se na 60 %. Nastavení horizontálního navýšení kapacity 85 % místo procenta blížícího se 100 % poskytuje vyrovnávací paměť pro ochranu před kumulovaným uživatelským provozem způsobeným rychlými relacemi. Chrání také před velkým nárůstem provozu škálováním na začátku, aby se zabránilo maximálnímu využití procesoru. Tato pravidla automatického škálování nejsou univerzální (viz následující kód).

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: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Efektivní používání prostředků

Používejte sdílené služby. Centralizace a sdílení určitých prostředků poskytuje optimalizaci nákladů a nižší režii na správu. Umístěte sdílené síťové prostředky do virtuální sítě rozbočovače.

Příklad: Referenční implementace umístí službu Azure Firewall, Azure Bastion a Key Vault do virtuální sítě centra.
Odstraňte nepoužívané prostředí. Pokud chcete optimalizovat náklady, odstraňte neprodukční prostředí po hodinách nebo během svátků. Infrastrukturu můžete použít jako kód k odstranění prostředků Azure a celých prostředí. Odeberte deklaraci prostředku, který chcete odstranit ze šablony Bicep. Pomocí operace citlivostní operace zobrazte náhled změn, než se projeví. Zálohujte data, která budete potřebovat později. Seznamte se se závislostmi prostředku, který odstraňujete. Pokud existují závislosti, budete možná muset tyto prostředky aktualizovat nebo odebrat. Další informace najdete v tématu Operace citlivostní operace nasazení Bicep.
Společné přidělení funkcí Pokud máte volnou kapacitu, společně přidělte prostředky a funkce aplikace v jednom prostředku Azure. Například více webových aplikací může používat jeden server (plán služby App Service) nebo jednu mezipaměť může podporovat více datových typů.

Příklad: Referenční implementace používá jednu instanci Azure Cache for Redis pro správu relací jak ve front-endu (ukládání košíku, tak tokenů MSAL) a back-end webových aplikací (držících data o nadcházejících koncertech). Rozhodne se pro nejmenší skladovou položku Redis, která nabízí více než potřebnou kapacitu, efektivně využívanou použitím více datových typů k řízení nákladů.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu. Model Reliable Web App implementuje infrastrukturu jako kód pro nasazení infrastruktury a monitorování pozorovatelnosti.

Automatizace nasazení

Pomocí kanálu CI/CD nasaďte změny ze správy zdrojového kódu do produkčního prostředí. Pokud používáte Azure DevOps, měli byste použít Azure Pipelines. Pokud používáte GitHub, použijte GitHub Actions. podpora Azure s šablona ARM (JSON), Bicep a Terraform a obsahuje šablony pro každý prostředek Azure. Další informace najdete v tématu Šablony Bicep, Azure Resource Manager a Terraform a opakovatelná infrastruktura

Příklad: Referenční implementace používá Azure Dev CLI a infrastrukturu jako kód (šablony Bicep) k vytvoření prostředků Azure, nastavení konfigurace a nasazení požadovaných prostředků.

Konfigurace sledování

Pokud chcete monitorovat webovou aplikaci, shromážděte a analyzujte metriky a protokoly z kódu aplikace, infrastruktury (modulu runtime) a platformy (prostředků Azure). Přidejte nastavení diagnostiky pro každý prostředek Azure ve vaší architektuře. Každá služba Azure má jinou sadu protokolů a metrik, které můžete zaznamenat. Další informace najdete v tématu Monitorování platformy a monitorování služby App Service.

Monitorování standardních metrik

Pomocí Aplikace Azure Přehledy můžete sledovat základní metriky, jako je propustnost požadavků, průměrná doba trvání požadavků, chyby a monitorování závislostí. Pomocí AddApplicationInsightsTelemetry balíčku Microsoft.ApplicationInsights.AspNetCore NuGet povolte shromažďování telemetrie. Další informace najdete v tématu Povolení telemetrie Přehledy aplikací a injektáž závislostí v .NET.

Příklad: Referenční implementace používá kód ke konfiguraci standardních metrik v Přehledy aplikace (viz následující kód).

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

Vytvoření vlastní telemetrie podle potřeby

Pomocí služby Application Přehledy můžete shromažďovat vlastní telemetrii, abyste lépe porozuměli uživatelům webové aplikace. Vytvořte instanci TelemetryClient třídy a pomocí TelemetryClient metod vytvořte správnou metriku. Převést dotaz na widget řídicího panelu Azure.

Příklad: Referenční implementace přidává metriky, které provoznímu týmu pomáhají identifikovat, že webová aplikace úspěšně dokončila transakce. Ověří, že je webová aplikace online, a to tak, že monitoruje, jestli zákazníci můžou zadávat objednávky, ne měřením počtu požadavků nebo využití procesoru. Referenční implementace používá TelemetryClient prostřednictvím injektáže závislostí a metodu TrackEvent shromažďování telemetrie událostí souvisejících s aktivitou košíku. Telemetrie sleduje lístky, které uživatelé přidávají, odebírat a nakupovat (viz následující kód).

AddToCart spočítá, kolikrát uživatelé přidají do košíku určitý lístek (ConcertID).
RemoveFromCart zaznamenává lístky, které uživatelé odeberou z košíku.
CheckoutCart zaznamenává událost pokaždé, když si uživatel koupí lístek.

this.telemetryClient.TrackEvent spočítá lístky přidané do košíku. Poskytuje název události (AddToCart) a určuje slovník, který obsahuje concertIdcount a (viz následující kód).

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

Další informace naleznete v tématu:

Shromažďování metrik založených na protokolech

Sledujte metriky založené na protokolech, abyste získali lepší přehled o základním stavu a metrikách aplikace. K vyhledání a uspořádání dat můžete použít dotazy dotazovací jazyk Kusto (KQL) v Přehledy aplikace. Další informace najdete v tématu Aplikace Azure Přehledy metriky založené na protokolech a metriky založené na protokolech a předem agregované metriky v Přehledy aplikace.

Povolení diagnostiky platformy

Nastavení diagnostiky v Azure umožňuje zadat protokoly platformy a metriky, které chcete shromažďovat a kam je ukládat. Protokoly platformy jsou integrované protokoly, které poskytují informace o diagnostice a auditování. Pro většinu služeb Azure můžete povolit diagnostiku platformy, ale každá služba definuje vlastní kategorie protokolů. Různé služby Azure mají různé kategorie protokolů, které si můžete vybrat.

Povolte diagnostiku pro všechny podporované služby. Služby Azure vytvářejí protokoly platformy automaticky, ale služba je automaticky neukládá. Pro každou službu musíte povolit nastavení diagnostiky a měli byste ho povolit pro každou službu Azure, která podporuje diagnostiku.
Odešlete diagnostiku do stejného cíle jako protokoly aplikace. Když povolíte diagnostiku, vyberete protokoly, které chcete shromáždit, a kam je chcete odeslat. Protokoly platformy byste měli odeslat do stejného cíle jako protokoly aplikace, abyste mohli obě datové sady korelovat.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu. Model Reliable Web App používá model doplňování mezipaměti k minimalizaci latence vysoce požadovaných dat.

Použití vzoru doplňování mezipaměti

Model doplňování mezipaměti je strategie ukládání do mezipaměti, která zlepšuje správu dat v paměti. Vzor přiřazuje aplikaci odpovědnost za zpracování požadavků na data a zajištění konzistence mezi mezipamětí a trvalým úložištěm, jako je databáze. Když webová aplikace obdrží žádost o data, nejprve prohledá mezipaměť. Pokud data chybí, načte je z databáze, odpoví na žádost a odpovídajícím způsobem aktualizuje mezipaměť. Tento přístup zkracuje dobu odezvy a zvyšuje propustnost a snižuje potřebu většího škálování. Také posiluje dostupnost služby snížením zatížení primárního úložiště dat a minimalizací rizik výpadků.

Příklad: Referenční implementace zvyšuje efektivitu aplikace ukládáním důležitých dat do mezipaměti, jako jsou například informace o nadcházejících koncertech zásadních pro prodej vstupenek. Pro ukládání položek v paměti používá mezipaměť distribuované paměti jádra ASP.NET. Aplikace automaticky používá Azure Cache for Redis, když najde konkrétní připojovací řetězec. Podporuje také místní vývojová prostředí bez Redis, aby zjednodušila nastavení a snížila náklady a složitost. Metoda (AddAzureCacheForRedis) nakonfiguruje aplikaci tak, aby používala Azure Cache for Redis (viz následující kód).

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

Další informace naleznete v tématu Distribuované ukládání do mezipaměti v ASP.NET Core a AddDistributedMemoryCache metoda.

Ukládání dat do mezipaměti s vysokou potřebou

Upřednostnit ukládání do mezipaměti pro nejčastěji přístupná data. Identifikujte klíčové datové body, které řídí zapojení uživatelů a výkon systému. Implementujte strategie ukládání do mezipaměti speciálně pro tyto oblasti, abyste optimalizovali efektivitu modelu doplňování mezipaměti, což výrazně snižuje latenci a zatížení databáze. Azure Monitor slouží ke sledování procesoru, paměti a úložiště databáze. Tyto metriky vám pomůžou určit, jestli můžete použít menší skladovou položku databáze.

Příklad: Referenční implementace ukládá data, která podporují nadcházející koncerty. Stránka Nadcházející koncerty vytváří nejvíce dotazů do služby SQL Database a vytváří konzistentní výstup pro každou návštěvu. Vzor doplňování mezipaměti ukládá data do mezipaměti po prvním požadavku na tuto stránku, aby se snížilo zatížení databáze. Následující kód používá metodu GetUpcomingConcertsAsync k načtení dat do mezipaměti Redis z SQL Database. Metoda naplní mezipaměť nejnovějšími koncerty. Metoda filtruje data podle času, seřadí data a vrátí data kontroleru, aby zobrazil výsledky (viz následující kód).

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

Zachování aktuálnost dat mezipaměti

Naplánujte pravidelné aktualizace mezipaměti pro synchronizaci s nejnovějšími změnami databáze. Určete optimální frekvenci aktualizace na základě nestálosti dat a potřeb uživatelů. Tento postup zajišťuje, že aplikace používá model doplňování mezipaměti k zajištění rychlého přístupu i aktuálních informací.

Příklad: Referenční implementace ukládá data do mezipaměti pouze po dobu jedné hodiny. Při změně dat má proces vymazání klíče mezipaměti. Metoda CreateConcertAsync vymaže klíč mezipaměti (viz následující kód).

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

Zajištění konzistence dat

Implementujte mechanismy pro aktualizaci mezipaměti ihned po jakékoli operaci zápisu databáze. K zajištění soudržnosti mezipaměti použijte aktualizace řízené událostmi nebo vyhrazené třídy správy dat. Konzistentní synchronizace mezipaměti s úpravami databáze je ústředním principem doplňování mezipaměti.

Příklad: Referenční implementace používá metodu UpdateConcertAsync k zachování dat v mezipaměti konzistentní (viz následující kód).

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

Testování výkonu databáze

Výkon databáze může ovlivnit výkon a škálovatelnost aplikace. Je důležité otestovat výkon databáze, aby byla optimalizovaná. Mezi klíčové aspekty patří výběr správné oblasti cloudu, sdružování připojení, vzor doplňování do mezipaměti a optimalizace dotazů.

Otestujte segmenty směrování sítě. Přesunutí aplikace do cloudu může do databáze zavést další segmenty směrování sítě a latenci. Měli byste otestovat další segmenty směrování, které nové cloudové prostředí zavádí.
Stanovení základní úrovně výkonu Jako počáteční směrný plán byste měli použít místní metriky výkonu pro porovnání výkonu aplikace v cloudu.

Další kroky

Nasaďte referenční implementaci podle pokynů v úložišti GitHub. Další informace o aplikacích .NET, webových aplikacích, osvědčených postupech cloudu a migraci najdete v následujících zdrojích informací.

Upgrade aplikací rozhraní .NET Framework

Referenční implementace se nasadí do služby App Service, která používá Windows, ale může běžet v Linuxu. Platforma App Service pro Windows umožňuje přesunout webové aplikace .NET Framework do Azure bez upgradu na novější verze rozhraní. Informace o plánech služby App Service pro Linux nebo nových funkcích a vylepšeních výkonu přidaných do nejnovějších verzí .NET najdete v následujících doprovodných materiálech.

Přehled přenosu z rozhraní .NET Framework do .NET Získejte pokyny na základě vašeho konkrétního typu aplikace .NET.
Přehled pomocníka pro upgrade platformy .NET Přečtěte si o nástroji konzoly, který vám pomůže automatizovat mnoho úloh spojených s upgradem projektů rozhraní .NET Framework.
Migrace z ASP.NET na ASP.NET Core v sadě Visual Studio Přečtěte si o rozšíření sady Visual Studio, které vám může pomoct s přírůstkovou migrací webových aplikací.

Úvod do webových aplikací v Azure

Praktické seznámení s webovými aplikacemi .NET v Azure najdete v těchto doprovodných materiálech k nasazení základní webové aplikace .NET.

Osvědčené postupy pro cloud

Pokyny k přechodu na Azure a architekturu najdete tady:

Architektura přechodu na cloud Může vaší organizaci pomoct s přípravou a spuštěním strategie pro vytváření řešení v Azure.
Dobře navržená architektura. Sada hlavních tenetů, které lze použít ke zlepšení kvality úlohy.

U aplikací, které vyžadují vyšší cíl úrovně služby než model Reliable Web App, najdete v důležitých úlohách.

Pokyny k migraci

Následující nástroje a prostředky vám můžou pomoct s migrací místních prostředků do Azure.

Azure Migrate poskytuje zjednodušenou službu migrace, modernizace a optimalizace pro Azure, která zpracovává posouzení a migraci webových aplikací, SQL Serveru a virtuálních počítačů.
Průvodce migrací databází Azure poskytuje prostředky pro různé typy databází a různé nástroje navržené pro váš scénář migrace.
Aplikace Azure akcelerátor cílové zóny služby poskytuje pokyny pro posílení a škálování nasazení služby App Service.
Posouzení aplikací a kódu ve službě Azure Migrate

Share via