Model spolehlivé webové aplikace pro .NET

Tento článek obsahuje pokyny k implementaci vzoru Spolehlivé webové aplikace. Tento model popisuje, jak upravit (znovuplatformovat) webové aplikace pro migraci do cloudu. Poskytuje preskriptivní architekturu, kód a pokyny ke konfiguraci, které jsou v souladu s principy architektury Azure Well-Architected Framework.

Proč model Reliable Web App pro .NET?

Model Reliable Web App je sada principů a technik implementace, které definují, jak byste při migraci webových aplikací do cloudu měli znovu vytvořit. Zaměřuje se na minimální aktualizace kódu, které je potřeba udělat, aby byly úspěšné v cloudu. Následující doprovodné materiály používají referenční implementaci jako příklad v celém příkladu. Pokyny se řídí replatformní cestou fiktivní společnosti Relecloud, která poskytuje obchodní kontext vaší cesty. Před implementací modelu Reliable Web App pro .NET měl Relecloud monolitickou místní webovou aplikaci pro lístky, která používala architekturu ASP.NET.

Implementace vzoru Reliable Web App

Tento článek obsahuje pokyny k architektuře, kódu a konfiguraci pro implementaci vzoru Reliable Web App. Pomocí následujících odkazů přejděte na konkrétní pokyny, které potřebujete:

• obchodní kontext. sladit tyto pokyny s obchodním kontextem a zjistit, jak definovat okamžité a dlouhodobé cíle, které řídí znovuplatformování rozhodnutí.
• pokyny k architektuře. Zjistěte, jak vybrat správné cloudové služby a navrhnout architekturu, která splňuje vaše obchodní požadavky.
• pokyny pro kód. Implementovat tři vzory návrhu, které zlepšují spolehlivost a efektivitu výkonu webové aplikace v cloudu: opakování, jistič a Cache-Aside vzory.
• pokyny ke konfiguraci . Konfigurace ověřování a autorizace, spravovaných identit, prostředí s právy, infrastruktury jako kódu a monitorování.

Obchodní kontext

Prvním krokem při opětovném vytvoření webové aplikace je definování obchodních cílů. Měli byste nastavit okamžité cíle, jako jsou cíle úrovně služeb (SLO) a cíle optimalizace nákladů a také budoucí cíle vaší webové aplikace. Tyto cíle ovlivňují vaši volbu cloudových služeb a architekturu vaší webové aplikace v cloudu. Definujte cílové SLO pro vaši webovou aplikaci, například 99,9% dobu provozu. Vypočítejte kombinovanou smlouvu SLA pro všechny služby, které ovlivňují dostupnost vaší webové aplikace.

Relecloud má například pozitivní prognózu prodeje a očekává zvýšenou poptávku po webové aplikaci pro vytváření lístků. Pro splnění této poptávky definovali cíle pro webovou aplikaci:

• Použijte změny kódu s nízkými náklady a vysokou hodnotou.
• Dosáhnout SLO 99,9%.
• Osvojte si postupy DevOps.
• Vytvořte prostředí optimalizovaná pro náklady.
• Zvýšení spolehlivosti a zabezpečení

Místní infrastruktura Relecloudu nebyla nákladově efektivním řešením pro dosažení těchto cílů. Rozhodli se, že migrace webové aplikace do Azure je nákladově nejefektivnější způsob, jak dosáhnout svých okamžitých a budoucích cílů.

Pokyny pro architekturu

Model Reliable Web App má několik základních prvků architektury. Potřebujete DNS ke správě překladu koncových bodů, firewallu webových aplikací pro blokování škodlivého provozu HTTP a nástroje pro vyrovnávání zatížení pro směrování a ochranu příchozích uživatelských požadavků. Aplikační platforma hostuje kód webové aplikace a volá všechny back-endové služby prostřednictvím privátních koncových bodů ve virtuální síti. Nástroj pro monitorování výkonu aplikace zaznamenává metriky a protokoly, které vám pomůžou porozumět vaší webové aplikaci.

Obrázek č. 1. Základní prvky architektury modelu Reliable Web App

Návrh architektury

Navrhněte infrastrukturu tak, aby podporovala metriky obnovení , jako je cíl doby obnovení (RTO) a cíl bodu obnovení (RPO). RtO má vliv na dostupnost a musí podporovat cíl úrovně služby. Určete cíl bodu obnovení a nakonfigurujte redundanci dat tak, aby splňoval cíl bodu obnovení.

• Zvolte spolehlivost infrastruktury. Určete, kolik zón dostupnosti a oblastí potřebujete ke splnění požadavků na dostupnost. Přidejte zóny dostupnosti a oblasti, dokud kombinovaná smlouva SLA nesplňuje cíl úrovně služeb. Model Spolehlivé webové aplikace podporuje více oblastí pro konfiguraci aktivní-aktivní nebo aktivní-pasivní. Referenční implementace například používá konfiguraci aktivní-pasivní, aby splňovala cíl úrovně služby 99,9 %.

  U webové aplikace ve více oblastech nakonfigurujte nástroj pro vyrovnávání zatížení tak, aby směrovat provoz do druhé oblasti, aby podporoval konfiguraci aktivní-aktivní nebo aktivní-pasivní v závislosti na potřebě vaší firmy. Obě oblasti vyžadují stejné služby, s výjimkou jedné oblasti má centrální virtuální síť, která propojuje oblasti. Přijměte hvězdicovou síťovou topologii, která umožňuje centralizovat a sdílet prostředky, jako je síťová brána firewall. Pokud máte virtuální počítače, přidejte hostitele bastionu do virtuální sítě centra, abyste je mohli spravovat s rozšířeným zabezpečením. (Viz obrázek 2.)

  

  Obrázek č. 2. Model Reliable Web App s druhou oblastí a hvězdicovou topologií.

• Zvolte síťovou topologii. Zvolte správnou síťovou topologii pro požadavky na web a sítě. Pokud plánujete používat více virtuálních sítí, použijte hvězdicovou topologii sítě . Poskytuje výhody nákladů, správy a zabezpečení a možnosti hybridního připojení k místním a virtuálním sítím.

Výběr správných služeb Azure

Když webovou aplikaci přesunete do cloudu, měli byste zvolit služby Azure, které splňují vaše obchodní požadavky, a v souladu s aktuálními funkcemi místní webové aplikace. Toto zarovnání pomáhá minimalizovat úsilí o přeformulování. Použijte například služby, které umožňují zachovat stejný databázový stroj a podporovat stávající middleware a architektury. Následující části obsahují pokyny pro výběr správných služeb Azure pro vaši webovou aplikaci.

Například před přesunem do cloudu byla webová aplikace Relecloudu pro lístky místní monolitická aplikace ASP.NET. Běžela na dvou virtuálních počítačích a použila databázi SQL Serveru. Webová aplikace utrpěla běžné problémy se škálovatelností a nasazením funkcí. Tento výchozí bod, jejich obchodní cíle a SLO řídily své volby služeb.

• Aplikační platforma: Jako aplikační platformu použijte službu Aplikace Azure Service. Relecloud jako aplikační platformu zvolil App Service z následujících důvodů:

  • Smlouva o vysoké úrovni služeb (SLA). Má vysokou smlouvu SLA, která splňuje SLO produkčního prostředí 99,9%.
  • Nižší režijní náklady na správu Jedná se o plně spravované řešení, které zpracovává škálování, kontroly stavu a vyrovnávání zatížení.
  • Podpora .NET Podporuje verzi rozhraní .NET, ve které je aplikace napsaná.
  • Funkce kontejnerizace Webová aplikace může konvergovat v cloudu bez kontejnerizace, ale aplikační platforma také podporuje kontejnerizaci bez změny služeb Azure.
  • Automatické škálování Webová aplikace se může automaticky škálovat na základě uživatelského provozu a nastavení konfigurace. Platforma také podporuje vertikální navýšení nebo snížení kapacity, aby vyhovovala různým požadavkům na hostování.

• Správa identit: Jako řešení pro správu identit a přístupu použijte Microsoft Entra ID . Relecloud zvolil Microsoft Entra ID z následujících důvodů:

  • Ověřování a autorizace. Aplikace musí ověřovat a autorizovat zaměstnance call center.
  • Škálovatelný. Microsoft Entra ID škáluje na podporu větších scénářů.
  • Řízení identit uživatelů. Zaměstnanci call centra můžou používat své stávající podnikové identity.
  • Podpora protokolu autorizace. Microsoft Entra ID podporuje OAuth 2.0 pro spravované identity.

• Databáze: Použijte službu, která umožňuje zachovat stejný databázový stroj. Výběr provedete pomocí rozhodovacího stromu úložiště dat. Webová aplikace Relecloud používala místní SQL Server. Chtěli použít existující schéma databáze, uložené procedury a funkce. V Azure je k dispozici několik produktů SQL, ale Relecloud zvolil Azure SQL Database z následujících důvodů:

  • Spolehlivost. Úroveň pro obecné účely poskytuje vysokou redundanci SLA a více oblastí. Může podporovat vysoké uživatelské zatížení.
  • Nižší režijní náklady na správu SQL Database poskytuje spravovanou instanci databáze SQL.
  • Podpora migrace Podporuje migraci databází z místního SQL Serveru.
  • Konzistence s místními konfiguracemi Podporuje existující uložené procedury, funkce a zobrazení.
  • Odolnost. Podporuje zálohování a obnovení k určitému bodu v čase.
  • Odborné znalosti a minimální přepracování. SQL Database umožňuje Relecloudu využívat stávající odborné znalosti a vyžaduje minimální práci na přijetí.

• monitorování výkonu aplikací: k analýze telemetrie pro vaši aplikaci použijte Application Insights. Relecloud se rozhodl používat Application Insights z následujících důvodů:

  • Integrace se službou Azure Monitor Poskytuje nejlepší integraci se službou Azure Monitor.
  • Detekce anomálií Automaticky detekuje anomálie výkonu.
  • Řešení problémů. Pomáhá diagnostikovat problémy ve spuštěné aplikaci.
  • Monitorování. Shromažďuje informace o tom, jak uživatelé aplikaci používají, a umožňuje snadno sledovat vlastní události.
  • Mezera viditelnosti Místní řešení nemělo řešení pro monitorování výkonu aplikací. Application Insights poskytuje snadnou integraci s aplikační platformou a kódem.

• Cache: Zvolte, jestli chcete přidat mezipaměť do architektury webové aplikace. Azure Cache for Redis je primárním řešením mezipaměti Azure. Jedná se o spravované úložiště dat v paměti založené na softwaru Redis. Zatížení webové aplikace Relecloud je silně zkosené směrem k prohlížení koncertů a podrobností o místě. Relecloud přidal Azure Cache for Redis z následujících důvodů:

  • Nižší režijní náklady na správu Jedná se o plně spravovanou službu.
  • Rychlost a hlasitost. Má vysokou propustnost dat a nízkou latenci čtení pro běžně používaná a pomalu se měnící data.
  • Různorodá podpora. Je to jednotné umístění mezipaměti pro všechny instance webové aplikace, které se mají použít.
  • Externí úložiště dat Místní aplikační servery prováděly místní ukládání do mezipaměti virtuálního počítače. Toto nastavení nenačítá data s vysokou četností a nemohla zneplatnit data.
  • Nesticky relace. Externalizace stavu relace podporuje nesticky relace.

• nástroj pro vyrovnávání zatížení : webové aplikace, které používají řešení PaaS, by měly v závislosti na architektuře a požadavcích webové aplikace používat Azure Front Door, Azure Application Gateway nebo obojí. Pomocí rozhodovacího stromu nástroje pro vyrovnávání zatížení vyberte správný nástroj pro vyrovnávání zatížení. Relecloud potřeboval nástroj pro vyrovnávání zatížení vrstvy 7, který by mohl směrovat provoz napříč několika oblastmi. Společnost potřebovala webovou aplikaci pro více oblastí, aby splňovala cíl úrovně služby (SLO) 99,9%. Relecloud zvolil Azure Front Door z následujících důvodů:

  • Globální vyrovnávání zatížení Jedná se o nástroj pro vyrovnávání zatížení vrstvy 7, který může směrovat provoz napříč několika oblastmi.
  • Firewall webových aplikací Nativně se integruje se službou Azure Web Application Firewall.
  • Flexibilita směrování Umožňuje týmu aplikace nakonfigurovat příchozí přenos dat, aby podporoval budoucí změny v aplikaci.
  • Zrychlení provozu. Pomocí libovolného vysílání se dostane k nejbližšímu bodu přítomnosti Azure a najde nejrychlejší trasu do webové aplikace.
  • Vlastní domény. Podporuje vlastní názvy domén s flexibilním ověřováním domény.
  • Sondy stavu Aplikace vyžaduje inteligentní monitorování sond stavu. Azure Front Door používá odpovědi z sondy k určení nejlepšího zdroje pro směrování požadavků klientů.
  • Podpora monitorování Podporuje integrované sestavy s řídicím panelem typu all-in-one pro azure Front Door i vzory zabezpečení. Můžete nakonfigurovat výstrahy, které se integrují se službou Azure Monitor. Azure Front Door umožňuje aplikaci protokolovat jednotlivé požadavky a neúspěšné sondy stavu.
  • Ochrana před útoky DDoS Má integrovanou ochranu před útoky DDoS vrstvy 3-4.
  • Síť pro doručování obsahu. Umístí Relecloud k používání sítě pro doručování obsahu. Síť pro doručování obsahu poskytuje akceleraci lokality.

• Firewall webových aplikací: Použijte Azure Web Application Firewall k zajištění centralizované ochrany před běžnými zneužitími a ohroženími zabezpečení webu. Relecloud používá Azure Web Application Firewall z následujících důvodů:

  • Globální ochrana. Poskytuje vylepšenou globální ochranu webových aplikací bez obětování výkonu.
  • Ochrana botnetu Tým může monitorovat a konfigurovat nastavení pro řešení problémů zabezpečení souvisejících s botnety.
  • Parita s místním prostředím Místní řešení běželo za bránou firewall webových aplikací spravovanou IT.
  • Snadné použití. Firewall webových aplikací se integruje se službou Azure Front Door.

• Úložiště konfigurace: Zvolte, jestli chcete do webové aplikace přidat úložiště konfigurace aplikace. Aplikace Azure Configuration je služba pro centrální správu nastavení aplikace a příznaků funkcí. Projděte si osvědčené postupy konfigurace aplikací a rozhodněte se, jestli je tato služba vhodná pro vaši aplikaci. Relecloud chtěl nahradit konfiguraci založenou na souborech centrálním úložištěm konfigurace, které se integruje s aplikační platformou a kódem. Do architektury přidali konfiguraci aplikace z následujících důvodů:

  • Flexibilita. Podporuje příznaky funkcí. Příznaky funkcí umožňují uživatelům vyjádřit výslovný souhlas s funkcemi ve verzi Preview v produkčním prostředí bez nutnosti opětovného nasazení aplikace.
  • Podpora kanálu Git Zdrojem pravdivých informací o konfiguračních datech musí být úložiště Git. Kanál potřebný k aktualizaci dat v centrálním úložišti konfigurace.
  • Podpora spravovaných identit Podporuje spravované identity, které zjednodušují a pomáhají zabezpečit připojení k úložišti konfigurace.

• Správce tajných kódů: Pokud máte tajné kódy pro správu v Azure, použijte Azure Key Vault . Key Vault můžete začlenit do aplikací .NET pomocí objektu ConfigurationBuilder. Místní webová aplikace Relecloud uložila tajné kódy do konfiguračních souborů kódu, ale lepším postupem zabezpečení je ukládat tajné kódy do umístění, které podporuje řízení RBAC a auditování. I když spravované identity jsou upřednostňovaným řešením pro připojení k prostředkům Azure, Relecloud měl tajné kódy aplikací, které potřebují ke správě. Služba Relecloud používala službu Key Vault z následujících důvodů:

  • Šifrování. Podporuje šifrování neaktivních uložených a přenášených dat.
  • Podpora spravovaných identit Aplikační služby můžou používat spravované identity pro přístup k úložišti tajných kódů.
  • Monitorování a protokolování Key Vault usnadňuje přístup k auditu a generuje výstrahy při změně uložených tajných kódů.
  • Integrace. Key Vault poskytuje nativní integraci se službou Azure Configuration Store (App Configuration) a platformou pro hostování webů (App Service).

• Řešení úložiště: Viz možnosti úložiště Azure vybrat správné řešení úložiště na základě vašich požadavků. Místní webová aplikace Relecloud měla diskové úložiště připojené ke každému webovému serveru, ale tým chtěl použít řešení externího úložiště dat. Relecloud zvolil Službu Azure Blob Storage z následujících důvodů:

  • Vylepšený přístup k zabezpečení. Webová aplikace může eliminovat koncové body pro přístup k úložišti vystaveným veřejnému internetu s anonymním přístupem.
  • Šifrování. Blob Storage šifruje neaktivní uložená data a přenášená data.
  • Odolnost. Blob Storage podporuje zónově redundantní úložiště (ZRS). Zónově redundantní úložiště synchronně replikuje data napříč třemi zónami dostupnosti Azure v primární oblasti. Každá zóna dostupnosti je v samostatném fyzickém umístění, které má nezávislý výkon, chlazení a síť. Tato konfigurace by měla zajistit odolnost imagí lístků proti ztrátě.

• zabezpečení koncových bodů : používat azure Private Link pro přístup k řešením platformy jako služby (PaaS) přes privátní koncový bod ve vaší virtuální síti. Provoz mezi vaší virtuální sítí a službou prochází přes páteřní síť Microsoftu. Relecloud zvolil Private Link z následujících důvodů:

  • Vylepšená komunikace se zabezpečením Private Link umožňuje aplikaci privátní přístup ke službám na platformě Azure a snižuje síťové nároky úložišť dat, aby se chránila před únikem dat.
  • Minimální úsilí. Privátní koncové body podporují platformu webové aplikace a databázovou platformu, kterou webová aplikace používá. Obě platformy zrcadlí stávající místní konfigurace, takže se vyžaduje minimální změna.

• Zabezpečení sítě. K řízení příchozího a odchozího provozu na úrovni sítě použijte služby Azure Firewall. Pomocí azure Bastion se připojte k virtuálním počítačům s rozšířeným zabezpečením, aniž byste museli vystavit porty RDP/SSH. Relecloud přijal hvězdicovou síťovou topologii a chtěl do centra umístit sdílené služby zabezpečení sítě. Azure Firewall zlepšuje zabezpečení kontrolou veškerého odchozího provozu z paprsků, aby se zvýšilo zabezpečení sítě. Relecloud potřeboval Azure Bastion pro nasazení s rozšířeným zabezpečením z přeskakujícího hostitele v podsíti DevOps.

Pokyny pro kód

Pokud chcete úspěšně přesunout webovou aplikaci do cloudu, musíte aktualizovat kód webové aplikace vzorem Opakování, vzorem Jistič a vzorem Cache-Aside.

Obrázek č. 3. Role vzorů návrhu

Každý vzor návrhu poskytuje výhody návrhu úloh, které odpovídají jednomu nebo více pilířům Well-Architected Frameworku. Tady je přehled vzorů, které byste měli implementovat:

1. Vzor opakování Vzor opakování zpracovává přechodné selhání opakováním operací, které můžou občas selhat. Tento model implementujte u všech odchozích volání do jiných služeb Azure.

2. Model jističe. Model Jistič zabraňuje aplikaci v opakování operací, které nejsou přechodné. Tento model implementujte ve všech odchozích voláních do jiných služeb Azure.

3. Cache-Aside vzor. Vzor Cache-Aside načítá data na vyžádání do mezipaměti z úložiště dat. Tento model implementujte u požadavků na databázi.

Implementace vzoru opakování

Přidejte do kódu aplikace vzor Opakování, který řeší dočasné přerušení služeb. Těmto přerušením se říká přechodné chyby. Přechodné chyby se obvykle řeší během několika sekund. Model opakování umožňuje znovu odeslat neúspěšné požadavky. Umožňuje také nakonfigurovat zpoždění mezi opakovanými pokusy a počtem pokusů o provedení před zřetězením selhání.

• Použijte integrované mechanismy opakování. Použijte integrovaný mechanismus opakování, který většina služeb Azure poskytuje k urychlení implementace. Referenční implementace například používá odolnost připojení v Entity Framework Core k použití vzoru opakování v požadavcích na SLUŽBU SQL Database:

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

• Použijte programovací knihovny opakování. Pro komunikaci HTTP integrujte standardní knihovnu odolnosti, jako je Polly nebo Microsoft.Extensions.Http.Resilience. Tyto knihovny poskytují komplexní mechanismy opakování, které jsou zásadní pro správu komunikace s externími webovými službami. Například referenční implementace používá Polly k vynucení vzoru opakování pokaždé, když kód vytvoří objekt, který volá IConcertSearchService objekt:

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

Implementace systému jističe

Pomocí vzoru Jistič můžete zpracovávat přerušení služeb, které nejsou přechodnými chybami. Model Jistič brání aplikaci v nepřetržitém pokusu o přístup k nereagující službě. Uvolní aplikaci a pomáhá zabránit plýtvání cykly procesoru, aby aplikace zachovala integritu výkonu pro koncové uživatele.

Například referenční implementace 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í:

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

Implementace modelu doplňování mezipaměti

Přidejte do webové aplikace model doplňování mezipaměti, abyste zlepšili 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. Zkracuje dobu odezvy, vylepšuje propustnost a snižuje potřebu většího škálování. Snižuje také zatížení primárního úložiště dat, což zlepšuje spolehlivost a optimalizaci nákladů. Pokud chcete implementovat model doplňování mezipaměti, postupujte podle těchto doporučení:

• Nakonfigurujte aplikaci tak, aby používala mezipaměť. Produkční aplikace by měly používat distribuovanou mezipaměť Redis. Tato mezipaměť zlepšuje výkon snížením počtu databázových dotazů. Umožňuje také nesticky relace, aby nástroj pro vyrovnávání zatížení mohl rovnoměrně distribuovat provoz. Referenční implementace používá distribuovanou mezipaměť Redis. Metoda AddAzureCacheForRedis nakonfiguruje aplikaci tak, aby používala Azure Cache for Redis:

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

• Ukládání vysoce potřebných dat do mezipaměti Použijte vzor Cache-Aside na data s vysokou potřebou, aby se zlepšila jeho efektivita. 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 po použití vzoru Cache-Aside použít menší skladovou položku databáze. Například referenční implementace ukládá do mezipaměti vysoce potřebná data, která podporují stránku Nadcházející koncerty. Metoda GetUpcomingConcertsAsync načítá data do mezipaměti Redis z SQL Database a naplní mezipaměť nejnovějšími daty koncertu:

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

• Udržujte data mezipaměti aktuální. Naplánujte pravidelné aktualizace mezipaměti pro synchronizaci s nejnovějšími změnami databáze. K určení optimální obnovovací frekvence použijte nestálost dat a uživatelé. Tento postup zajišťuje, aby aplikace používala model Cache-Aside k zajištění rychlého přístupu i aktuálních informací. Například referenční implementace ukládá data do mezipaměti pouze po dobu jedné hodiny a používá metodu CreateConcertAsync k vymazání klíče mezipaměti při změně dat:

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

• Zajistěte konzistenci 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. Referenční implementace používá metodu UpdateConcertAsync k zachování konzistentních dat v mezipaměti:

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

Pokyny ke konfiguraci

Následující části obsahují pokyny k implementaci aktualizací konfigurace. Každý oddíl je v souladu s jedním nebo více pilíři dobře navržená architektura.

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

Při migraci webových aplikací do Azure nakonfigurujte mechanismy ověřování a autorizace uživatelů. Postupujte podle těchto doporučení:

• Použijte platformu Identity Platform. K nastavení ověřování webové aplikace použijte platformu Microsoft Identity Platform. Tato platforma podporuje aplikace, které používají jeden adresář Microsoft Entra, více adresářů Microsoft Entra z různých organizací a identity Microsoftu nebo účty sociálních sítí.

• Vytvořte registraci aplikace. ID Microsoft Entra vyžaduje registraci aplikace v primárním tenantovi. Registrace aplikace pomáhá zajistit, aby uživatelé, kteří získají přístup k webové aplikaci, měli identity v primárním tenantovi.

• Používejte funkce platformy. Minimalizujte potřebu vlastního ověřovacího kódu pomocí funkcí platformy k ověřování uživatelů a přístupu k datům. Například App Service poskytuje integrovanou podporu ověřování, abyste mohli při psaní minimálního nebo žádného kódu ve webové aplikaci přihlašovat uživatele a přistupovat k datům.

• Vynucujte autorizaci v aplikaci. Pomocí RBAC přiřaďte nejnižší oprávnění k aplikačním rolím. Definujte konkrétní role pro různé akce uživatelů, abyste se vyhnuli překrývání a zajistili srozumitelnost. Namapujte uživatele na příslušné role a ujistěte se, že mají přístup jenom k potřebným prostředkům a akcím.

• Upřednostněte dočasný přístup k úložišti. 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í. Pomocí sdílených přístupových podpisů (SAS) můžete například omezit přístup na určité časové období. Sas delegování uživatele můžete použít k maximalizaci zabezpečení při udělení dočasného přístupu. Jedná se o jediný SAS, který používá přihlašovací údaje Microsoft Entra ID a nevyžaduje trvalý klíč účtu úložiště.

• Vynucujte autorizaci v Azure. Pomocí Azure RBAC přiřaďte identitám uživatelů nejnižší oprávnění. Azure RBAC definuje prostředky Azure, ke kterým mají identity přístup, co můžou s těmito prostředky dělat, a oblasti, ke kterým mají přístup.

• Vyhněte se trvalým zvýšeným oprávněním. Microsoft Entra Privileged Identity Management umožňuje udělit přístup za běhu pro privilegované operace. Vývojáři například často potřebují přístup na úrovni správce k vytváření nebo odstraňování databází, úpravám schémat tabulek a změnám uživatelských oprávnění. Při použití přístupu za běhu obdrží identity uživatelů dočasná oprávnění k provádění privilegovaných úloh.

Použití spravovaných identit

Používejte spravované identity pro všechny služby Azure, které je podporují. Spravovaná identita umožňuje prostředkům Azure (identitám úloh) ověřování a interakci s ostatními službami Azure, aniž byste museli spravovat přihlašovací údaje. Pokud chcete migraci zjednodušit, můžete i nadále používat místní řešení ověřování pro hybridní a starší systémy, ale měli byste je co nejdříve převést na spravované identity. Pokud chcete implementovat spravované identity, postupujte podle těchto doporučení:

• Vyberte správný typ spravované identity. Upřednostňujte spravované identity přiřazené uživatelem, pokud máte dva nebo více prostředků Azure, které potřebují stejnou sadu oprávnění. Tento přístup je efektivnější než vytváření spravovaných identit přiřazených systémem pro každý z těchto prostředků a přiřazování stejných oprávnění všem. Jinak použijte spravované identity přiřazené systémem.

• Nakonfigurujte nejnižší oprávnění. Pomocí Azure RBAC udělte 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í. Pokud Azure RBAC nepokrývá konkrétní scénář, doplňte Azure RBAC pomocí zásad přístupu na úrovni služeb Azure.

• Zajištění zabezpečení zbývajících tajných kódů Ukládejte všechny zbývající tajné kódy ve službě Azure Key Vault. 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. Přístup s vysokou frekvencí v rámci požadavků HTTP může překročit limity transakcí služby Key Vault. Uložte konfigurace aplikací v konfiguraci Aplikace Azure.

Referenční implementace používá argument Authentication v připojovacím řetězci databáze SQL, aby se služba App Service připojit k databázi SQL pomocí spravované identity: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Používá DefaultAzureCredential k povolení připojení webového rozhraní API ke službě Key Vault pomocí spravované identity:

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

Nastavení práv k prostředím

Používejte úrovně výkonu (SKU) služeb Azure, které splňují potřeby jednotlivých prostředí, aniž by je překročily. Pokud chcete oprávnění k vašim prostředím, postupujte podle těchto doporučení:

• Odhad nákladů Pomocí cenové kalkulačky Azure můžete odhadnout náklady na každé prostředí.

• Optimalizace nákladů v produkčních prostředích 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í. Nepřetržitě monitorujte využití prostředků a upravte skladové položky tak, aby odpovídaly skutečným požadavkům na výkon.

• předprodukční prostředí optimalizace nákladů.předprodukční prostředí by měla používat méně nákladné prostředky a využívat slevy, jako je cen azure pro vývoj/testování. V těchto prostředích byste měli zakázat služby, které nejsou potřeba. Současně zajistěte, aby předprodukční prostředí byla dostatečně podobná produkčním prostředím, aby nedocházelo k rizikům. Udržování tohoto zůstatku zajišťuje, že testování zůstane efektivní bez zbytečných nákladů.

• K definování skladových položek použijte infrastrukturu jako kód (IaC). Implementujte IaC, abyste dynamicky vybrali a nasadily správné skladové položky na základě prostředí. Tento přístup zvyšuje konzistenci a zjednodušuje správu.

Referenční implementace například používá parametry Bicep k nasazení dražších úrovní (SKU) do produkčního prostředí:

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

Implementace automatického škálování

Automatické škálování pomáhá zajistit, aby webová aplikace zůstala odolná, responzivní a schopná efektivně zpracovávat dynamické úlohy. Pokud chcete implementovat automatické škálování, postupujte podle těchto doporučení:

• Automatizace horizontálního navýšení kapacity Automatické škálování Azure slouží k automatizaci horizontálního škálování v produkčních prostředích. Nakonfigurujte pravidla automatického škálování tak, aby škálovat na základě klíčových metrik výkonu, aby vaše aplikace zvládla různá zatížení.

• Upřesněte triggery škálování. Pokud neznáte požadavky vaší aplikace na škálování, použijte jako trigger počátečního škálování využití procesoru. Zpřesněte triggery škálování tak, aby zahrnovaly další metriky, jako je ram, propustnost sítě a vstupně-výstupní operace disku. Cílem je shodovat chování webové aplikace za účelem lepšího výkonu.

• Zadejte vyrovnávací paměť se škálováním na více systémů. Nastavte prahové hodnoty škálování tak, aby se aktivovaly před dosažením maximální kapacity. Nakonfigurujte například škálování tak, aby probíhalo při 85% využití procesoru, a nečekejte, dokud nedosáhne 100 %. Tento proaktivní přístup pomáhá udržovat výkon a vyhnout se potenciálním kritickým bodům.

Automatizace nasazení prostředků

Využijte automatizaci k nasazení a aktualizaci prostředků a kódu Azure napříč všemi prostředími. Postupujte podle těchto doporučení:

• Použijte infrastrukturu jako kód. Nasaďte infrastrukturu jako kódu pomocí kanálů kontinuální integrace a průběžného doručování (CI/CD). Azure poskytuje předem připravené šablony Bicep, ARM (JSON) a Terraform pro každý prostředek Azure.

• Použijte kanál kontinuální integrace nebo průběžného nasazování (CI/CD). Pomocí kanálu CI/CD nasaďte kód ze správy zdrojového kódu do různých prostředí, jako je testování, příprava a produkce. Pokud pracujete s Azure DevOps, použijte Azure Pipelines. Použijte GitHub Actions pro projekty GitHubu.

• Integrace testování jednotek Určete prioritu spuštění a předání všech testů jednotek v rámci kanálu před jakýmkoli nasazením do App Services. Začleňte nástroje pro kvalitu kódu a pokrytí, jako je SonarQube, abyste dosáhli komplexního pokrytí testování.

• Osvojte si architektury napodobování. K testování, které zahrnuje externí koncové body, použijte architektury napodobování. Tyto architektury umožňují vytvářet simulované koncové body. Eliminují nutnost konfigurovat skutečné externí koncové body a zajistit jednotné testovací podmínky napříč prostředími.

• Proveďte kontroly zabezpečení. Pomocí testování zabezpečení statických aplikací (SAST) můžete ve zdrojovém kódu najít chyby zabezpečení a kódovat chyby. Kromě toho proveďte analýzu složení softwaru (SCA) za účelem prozkoumání knihoven a komponent třetích stran z hlediska bezpečnostních rizik. Nástroje pro tyto analýzy se snadno integrují do GitHubu i Azure DevOps.

Implementace monitorování

Implementujte monitorování aplikací a platforem za účelem zvýšení efektivity provozu a efektivity výkonu vaší webové aplikace. Pokud chcete implementovat monitorování, postupujte podle těchto doporučení:

• Shromážděte telemetrii aplikací. Pomocí automatického v Azure Application Insights můžete shromažďovat telemetrické aplikace, jako je propustnost požadavků, průměrná doba trvání požadavku, chyby a monitorování závislostí. Abyste mohli tuto telemetrii používat, nemusíte provádět žádné změny kódu.

  Referenční implementace používá AddApplicationInsightsTelemetry z balíčku NuGet Microsoft.ApplicationInsights.AspNetCore k povolení shromažďování telemetrie:

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

• Vytvořte vlastní metriky aplikací. Pro vlastní telemetrii aplikací použijte instrumentaci založenou na kódu. Přidejte do kódu sadu Application Insights SDK a použijte rozhraní API Application Insights.

  Referenční implementace shromažďuje telemetrii událostí souvisejících s aktivitou košíku. this.telemetryClient.TrackEvent spočítá lístky přidané do košíku. Poskytuje název události (AddToCart) a určuje slovník, který má concertId a count:

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

• Monitorujte platformu. Povolte diagnostiku pro všechny podporované služby. Odešle diagnostiku do stejného cíle jako protokoly aplikace pro korelaci. Služby Azure vytvářejí protokoly platformy automaticky, ale ukládají je jenom při povolení diagnostiky. Povolte nastavení diagnostiky pro každou službu, která podporuje diagnostiku.

Nasazení referenční implementace

Referenční implementace provede vývojáře simulovanou migrací z místní ASP.NET aplikace do Azure a zvýrazní změny, které jsou nezbytné během počáteční fáze přijetí. Tento příklad používá aplikaci pro vstupenky na koncert pro fiktivní společnost Relecloud, která prodává lístky prostřednictvím své místní webové aplikace. Relecloud pro svou webovou aplikaci nastavil následující cíle:

• Implementujte změny kódu s nízkými náklady a vysokou hodnotou.
• Dosáhnout SLO 99,9%.
• Osvojte si postupy DevOps.
• Vytvořte prostředí optimalizovaná pro náklady.
• Zvyšte spolehlivost a zabezpečení.

Relecloud zjistil, že jejich místní infrastruktura nebyla nákladově efektivním řešením pro splnění těchto cílů. Rozhodli se, že migrace webové aplikace do Azure je nákladově nejefektivnější způsob, jak dosáhnout svých okamžitých a budoucích cílů. Následující architektura představuje koncový stav implementace modelu spolehlivé webové aplikace Relecloud.

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