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. Nabízí preskriptivní architekturu, kód a pokyny pro konfiguraci v souladu s principy dobře navržená architektura.

Proč model Reliable Web App pro .NET?

Model Reliable Web App je sada principů a technik implementace, které definují, jak byste při migraci do cloudu měli znovu vytvořit webové aplikace. 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 a řídí se 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: Srovnejte tyto pokyny s obchodním kontextem a zjistěte, jak definovat okamžité a dlouhodobé cíle, které řídí replatforming 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: Implementace tří vzorů návrhu pro zlepšení spolehlivosti a efektivity výkonu webové aplikace v cloudu: opakování, jistič a modely doplňování do mezipaměti
• 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 na úrovni služeb 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žití změn kódu s nízkými náklady a vysokou hodnotou
• Dosažení cíle úrovně služeb (SLO) 99,9 %
• Přijetí postupů DevOps
• Vytváření prostředí optimalizovaných 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 tedy, ž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í za účelem ochrany a směrování 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, aby porozuměl 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í (RPO) a nakonfigurujte redundanci dat tak, aby splňovala cíl bodu obnovení.

• Zvolte spolehlivost infrastruktury. Určete, kolik zón dostupnosti a oblastí potřebujete ke splnění vašich potřeb dostupnosti. 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 do virtuální sítě centra hostitele bastionu, abyste je mohli bezpečně spravovat (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 mít více virtuálních sítí, použijte hvězdicovou topologii sítě. Poskytuje výhody nákladů, správy a zabezpečení s možnostmi 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ž přesunete webovou aplikaci do cloudu, měli byste vybrat služby Azure, které splňují vaše obchodní požadavky, a v souladu s aktuálními funkcemi místní webové aplikace. Sladě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řechodem do cloudu byla webová aplikace Relecloud pro lístky místní, monolitická ASP.NET aplikace. Běžela na dvou virtuálních počítačích a měla databázi Microsoft SQL Serveru. Webová aplikace utrpěla běžné problémy se škálovatelností a nasazování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 Aplikace Azure Service z následujících důvodů:

  • Smlouva SLA (High Service Level Agreement): Má vysokou smlouvu SLA, která splňuje cíl úrovně služeb (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 .NET, ve které je aplikace napsaná.
  • Funkce kontejnerizace: Webová aplikace může konvergovat v cloudu bez kontejnerizace, ale aplikační platforma také podporuje kontejnerizaci beze změny služeb Azure.
  • Automatické škálování: Webová aplikace se může automaticky škálovat a navyšovat 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 centra.
  • Škálovatelné: Škáluje se tak, aby podporovala větší scénáře.
  • Řízení identit uživatelů: Zaměstnanci call centra můžou používat své stávající podnikové identity.
  • Podpora autorizačního protokolu: Podporuje OAuth 2.0 pro spravované identity.

• Databáze: Použijte službu, která umožňuje zachovat stejný databázový stroj. Použijte rozhodovací strom úložiště dat. Webová aplikace Relecloud používala místní SQL Server. Chtěli proto 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 úroveň SLA a redundanci ve více oblastech. Může podporovat vysoké uživatelské zatížení.
  • Nižší režijní náklady na správu: 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 využívá interní odborné znalosti a vyžaduje minimální práci na přijetí.

• Monitorování výkonu aplikací: Pomocí Application Insights můžete analyzovat telemetrii ve vaší aplikaci. 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í potíží: 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.

• Mezipaměť: Zvolte, jestli chcete přidat mezipaměť do architektury webové aplikace. Azure Cache for Redis je primární řešení mezipaměti Azure. Jedná se o spravované úložiště dat v paměti založené na softwaru Redis. Načítání webových aplikací Relecloudu se výrazně zkosí směrem k zobrazení podrobností o koncertech a místě a z následujících důvodů se přidala služba Azure Cache for Redis:

  • Nižší režijní náklady na správu: Jedná se o plně spravovanou službu.
  • Rychlost a svazek: Má vysokou propustnost dat a nízkou latenci čtení pro běžně používaná a pomalá změna dat.
  • Různorodá podpora: Jedná se o jednotné umístění mezipaměti, které může používat všechny instance webové aplikace.
  • 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: Externí stav relace podporuje nesticky relace.

• Nástroj pro vyrovnávání zatížení: Webové aplikace využívající řešení PaaS by měly používat službu Azure Front Door, Aplikace Azure lication Gateway nebo obojí na základě architektury a požadavků webových aplikací. 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. Relecloud potřeboval 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.
  • Akcelerace provozu: K dosažení nejbližšího bodu přítomnosti v Azure používá jakékoli vysílání a najděte 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 potřebuje 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 front Door i vzory zabezpečení. Můžete nakonfigurovat výstrahy, které se integrují se službou Azure Monitor. 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žíval 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 firewallem webových aplikací spravovaným 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 odhlásit a odhlásit se z dřívějších funkcí ve verzi Preview v produkčním prostředí bez opětovného nasazení aplikace.
  • Podporuje kanál Git: Zdroj pravdivých informací o konfiguračních datech potřebných jako úložiště Git. Kanál potřebný k aktualizaci dat v centrálním úložišti konfigurace.
  • Podporuje spravované identity: 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 je lepším postupem zabezpečení ukládat tajné kódy do umístění, které podporuje řízení RBAC a auditování. Spravované identity jsou sice upřednostňovaným řešením pro připojení k prostředkům Azure, ale 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 dat a přenášených dat.
  • Podpora spravované identity: 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í: Usnadňuje přístup k auditu a generuje výstrahy při změně uložených tajných kódů.
  • Integrace: Poskytuje nativní integraci se službou Azure Configuration Store (App Configuration) a platformou pro hostování webů (App Service).

• Řešení úložiště: Projděte si možnosti úložiště Azure a vyberte si 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ů:

  • Zabezpečený přístup: 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í: Šifruje neaktivní uložená data a přenášená data.
  • Odolnost: 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ů: Pomocí služby Azure Private Link můžete přistupovat k řešením typu platforma jako služba 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 zabezpečení: Umožňuje aplikacím privátní přístup ke službám na platformě Azure a snižuje síťové nároky úložišť dat, které pomáhají chránit před únikem dat.
  • Minimální úsilí: Privátní koncové body podporují platformu webové aplikace a databázovou platformu, které webová aplikace používá. Obě platformy zrcadlí stávající místní konfigurace pro minimální změnu.

• Zabezpečení sítě: Pomocí služby Azure Firewall můžete řídit příchozí a odchozí provoz na úrovni sítě. Pomocí služby Azure Bastion se bezpečně připojte k virtuálním počítačům bez vystavení portů 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 zabezpečená nasazení 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 návrhu doplňování mezipaměti.

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

Každý vzor návrhu poskytuje výhody návrhu úloh, které jsou v souladu s jedním z více pilířů dobře navržená architektura. Tady je přehled vzorů, které byste měli implementovat:

1. Model 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č: 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. Model doplňování mezipaměti: Model doplňování mezipaměti se přidává do mezipaměti a načítá z mezipaměti častěji než ú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í požadavků a počet pokusů 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 musí urychlit implementaci. 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 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);
      }));
  

• Použijte programovací knihovny opakování. Pro komunikaci HTTP integrujte standardní knihovnu odolnosti, jako je Polly nebo Microsoft.Extensions.Http.Resilience. Tyto knihovny nabízejí 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 (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);
  }
  

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 zabraňuje 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 ke zjištění požadavků HTTP, které může bezpečně opakovat, ale omezuje počet agregovaných chyb v zadaném časovém období (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));
}

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 Cache, protože zlepšuje výkon snížením databázových dotazů a umožňuje nesticky relace, aby nástroj pro vyrovnávání zatížení mohl rovnoměrně distribuovat provoz. Například referenční implementace používá distribuovanou mezipaměť Redis. 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();
      }
  }
  

• Ukládání vysoce potřebných dat do mezipaměti U dat s vysokou potřebou použijte model doplňování mezipaměti, aby se zvýš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 Doplňování mezipaměti 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čte data do mezipaměti Redis z SQL Database a naplní mezipaměť nejnovějšími daty koncertů (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>();
  }
  

• Udržujte data mezipaměti aktuální. 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í. 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 (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);
  }
  

• 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. Napří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();
  }
  

Pokyny ke konfiguraci

Následující části obsahují pokyny k implementaci aktualizací konfigurací. 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 s jedním tenantem i více tenanty, které uživatelům umožňují přihlásit se pomocí svých identit Microsoftu nebo účtů sociálních sítí.

• Vytvořte registraci aplikace. ID Microsoft Entra vyžaduje registraci aplikace v primárním tenantovi. Registrace aplikace zajišťuje uživatelům, kteří získají přístup k webové aplikaci, 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. Služba App Service například poskytuje integrovanou podporu ověřování, takže se můžete přihlásit uživatele a přistupovat k datům napsáním minimálního nebo žádného kódu ve webové aplikaci.

• Vynucujte autorizaci v aplikaci. Pomocí řízení přístupu na základě role (RBAC) přiřaďte k rolím aplikací nejnižší oprávnění. 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í, jako jsou sdílené přístupové podpisy (SAS). SAS delegování uživatelů slouží k maximalizaci zabezpečení při udělování 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 určuje, k jakým identitám prostředků Azure mají přístup, co můžou s těmito prostředky dělat a k jakým oblastem 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í. S přístupem za běhu získávají identity uživatelů dočasná oprávnění k provádění privilegovaných úloh.

Implementace spravovaných identit

Spravované identity používejte pro všechny služby Azure, které podporují spravované identity. Spravovaná identita umožňuje prostředkům Azure (identitám úloh) ověřování a interakci s ostatními službami Azure bez správy přihlašovacích údajů. Hybridní a starší systémy můžou uchovávat místní řešení ověřování, aby se migrace zjednodušila, ale měla by co nejdříve přejít 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í. Toto nastavení 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 z nich. Jinak použijte spravované identity přiřazené systémem.

• Nakonfigurujte nejnižší oprávnění. Azure RBAC použijte k udělení jenom oprávnění, která jsou pro operace důležitá, například 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.

• Zabezpečte zbývající tajné kódy. 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.

Například referenční implementace používá Authentication argument v databázi SQL připojovací řetězec, aby se app Service mohl 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 (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 in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Nastavení správné velikosti prostředí

Používejte úrovně výkonu (SKU) služeb Azure, které splňují potřeby jednotlivých prostředí bez nadbytečného využití. Pokud chcete prostředí správně upravit, 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í pro optimalizaci nákladů Předprodukční prostředí by měla používat prostředky s nižšími náklady, zakázat nepotřebné služby a uplatňovat slevy, jako jsou ceny azure pro vývoj/testování. Ujistěte se, že předprodukční prostředí jsou dostatečně podobná produkčnímu prostředí , aby nedocházelo k rizikům. Tento zůstatek zajišťuje, že testování zůstane efektivní bez zbytečných nákladů.

• Definujte skladové položky pomocí infrastruktury jako kódu (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í zajišťuje, 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í. Začněte s využitím procesoru jako triggerem počátečního škálování, pokud neznáte požadavky vaší aplikace na škálování. Zpřesněte triggery škálování tak, aby zahrnovaly další metriky, jako je paměť 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ód prostřednictvím kanálů kontinuální integrace a průběžného doručování (CI/CD). Azure má 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 nebo GitHub Actions pro projekty GitHub, využijte Azure Pipelines.

• 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 architekturu napodobování. K testování externích koncových bodů využ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 jsou snadno integrované 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 vytváření v Aplikace Azure lication Insights můžete shromažďovat telemetrická data aplikací, jako je propustnost požadavků, průměrná doba trvání požadavků, chyby a monitorování závislostí beze změn kódu.

  Referenční implementace používá AddApplicationInsightsTelemetry z balíčku Microsoft.ApplicationInsights.AspNetCore NuGet k povolení shromažďování telemetrie (viz následující kód).

  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ý obsahuje concertId count a (viz následující kód).

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

• Monitorujte platformu. Povolte diagnostiku pro všechny podporované služby a odešlete diagnostiku do stejného cíle jako protokoly aplikací pro korelaci. Služby Azure vytvářejí protokoly platformy automaticky, ale ukládají se 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í aplikace ASP.NET do Azure a zvýrazní nezbytné změny 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:

• Implementace změn kódu s nízkými náklady a vysokou hodnotou
• Dosažení cíle úrovně služeb (SLO) 99,9 %
• Přijetí postupů DevOps
• Vytváření prostředí optimalizovaných pro náklady
• Zvýšení spolehlivosti 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 CAMS 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 3 Architektura referenční implementace Stáhněte si soubor Visia této architektury.