Model moderní webové aplikace pro .NET

V tomto článku se dozvíte, jak implementovat model moderní webové aplikace. Model moderní webové aplikace definuje, jak byste měli modernizovat webové aplikace v cloudu a zavést architekturu zaměřenou na služby. Vzor moderní webové aplikace poskytuje preskriptivní architekturu, kód a pokyny ke konfiguraci, které odpovídají principům architektury Azure Well-Architected Framework a vychází ze vzoru Spolehlivé webové aplikace.

Proč používat vzor moderní webové aplikace?

Model moderní webové aplikace pomáhá optimalizovat oblasti webové aplikace s vysokou poptávkou. Nabízí podrobné pokyny k oddělení těchto oblastí, což umožňuje nezávislé škálování pro optimalizaci nákladů. Tento přístup umožňuje přidělit vyhrazené prostředky kritickým komponentám a zvýšit tak celkový výkon. Oddělení oddělených služeb může zlepšit spolehlivost tím, že brání zpomalení v jedné části aplikace, aby ovlivnily ostatní. Oddělení také umožňuje nezávisle na sobě správu verzí jednotlivých komponent aplikace.

Implementace vzoru moderní webové aplikace

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

• Pokyny k architektuře: Zjistěte, jak modularizovat komponenty webových aplikací a vybrat vhodná řešení typu platforma jako služba (PaaS).
• Pokyny pro kód: Implementujte čtyři vzory návrhu pro optimalizaci oddělených komponent: Strangler Fig, vyrovnávání zatížení založené na frontě, konkurující spotřebitelé a vzory monitorování koncových bodů stavu.
• Pokyny ke konfiguraci: Konfigurace ověřování, autorizace, automatického škálování a kontejnerizace pro oddělené komponenty

Pokyny pro architekturu

Model moderní webové aplikace vychází ze vzoru Reliable Web App. K implementaci vyžaduje několik dalších komponent architektury. Potřebujete frontu zpráv, platformu kontejneru, oddělené úložiště dat služby a registr kontejnerů (viz obrázek 1).

Obrázek 1 Základní architektonické prvky modelu moderní webové aplikace

Pro vyšší cíl na úrovni služby (SLO) můžete do architektury webové aplikace přidat druhou oblast. Druhá oblast vyžaduje, abyste nástroj pro vyrovnávání zatížení nakonfigurovali tak, aby směrovat provoz do druhé oblasti tak, aby podporoval konfiguraci aktivní-aktivní nebo aktivní-pasivní. Pomocí hvězdicové síťové topologie můžete centralizovat a sdílet prostředky, jako je síťová brána firewall. Přístup k úložišti kontejneru prostřednictvím virtuální sítě centra. 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 Architektura vzoru moderní webové aplikace s druhou oblastí a hvězdicovou topologií sítě

Oddělená architektura

Pokud chcete implementovat model moderní webové aplikace, musíte oddělit stávající architekturu webové aplikace. Oddělení architektury zahrnuje rozdělení monolitické aplikace do menších nezávislých služeb, z nichž každá zodpovídá za konkrétní funkci nebo funkce. Tento proces zahrnuje vyhodnocení aktuální webové aplikace, úpravu architektury a nakonec extrahování kódu webové aplikace na platformu kontejneru. Cílem je systematicky identifikovat a extrahovat aplikační služby, které nejvíce využívají od oddělení. Pokud chcete oddělit architekturu, postupujte podle těchto doporučení:

• Identifikace hranic služby Použijte principy návrhu řízeného doménou k identifikaci ohraničených kontextů v monolitické aplikaci. Každý ohraničený kontext představuje logickou hranici a může být kandidátem pro samostatnou službu. Služby, které představují jedinečné obchodní funkce a mají méně závislostí, jsou vhodnými kandidáty na oddělení.

• Vyhodnoťte výhody služby. Zaměřte se na služby, které nejvíce využívají nezávislé škálování. Oddělení těchto služeb a převod úloh zpracování od synchronních na asynchronní operace umožňuje efektivnější správu prostředků, podporuje nezávislá nasazení a snižuje riziko dopadu jiných částí aplikace během aktualizací nebo změn. Rezervaci objednávky můžete například oddělit od zpracování objednávek.

• Vyhodnoťte technickou proveditelnost. Prozkoumejte aktuální architekturu a identifikujte technická omezení a závislosti, které by mohly ovlivnit proces oddělení. Naplánujte způsob správy a sdílení dat napříč službami. Oddělené služby by měly spravovat vlastní data a minimalizovat přímý přístup k databázi přes hranice služeb.

• Nasaďte služby Azure. Vyberte a nasaďte služby Azure, které potřebujete k podpoře služby webové aplikace, kterou jste chtěli extrahovat. Pokyny najdete v následující části Výběr správných služeb Azure.

• Oddělte služby webových aplikací. Definujte jasná rozhraní a rozhraní API pro nově extrahované služby webových aplikací pro interakci s dalšími částmi systému. Navrhujte strategii správy dat, která každé službě umožňuje spravovat vlastní data a zároveň zajistit konzistenci a integritu. Konkrétní strategie implementace a vzory návrhu, které se mají použít během tohoto procesu extrakce, najdete v části s pokyny kódu .

• Pro oddělené služby používejte nezávislé úložiště. Každá oddělená služba by měla mít vlastní izolované úložiště dat, aby bylo možné usnadnit nezávislou správu verzí, nasazení, škálovatelnost a zachování integrity dat. Referenční implementace například odděluje službu vykreslování lístků od webového rozhraní API a eliminuje potřebu služby pro přístup k databázi rozhraní API. Místo toho služba komunikuje s adresou URL, kde se obrázky lístků vygenerovaly zpět do webového rozhraní API, prostřednictvím zprávy služby Azure Service Bus a rozhraní API uchovává cestu ke své databázi.

• Implementujte samostatné kanály nasazení pro každou oddělenou službu. Samostatné kanály nasazení umožňují aktualizaci jednotlivých služeb vlastním tempem. Pokud různé týmy nebo organizace ve vaší společnosti vlastní různé služby, mají samostatné kanály nasazení každému týmu kontrolu nad jejich vlastními nasazeními. K nastavení těchto kanálů použijte nástroje kontinuální integrace a průběžného doručování (CI/CD), jako je Jenkins, GitHub Actions nebo Azure Pipelines.

• Revidovat bezpečnostní prvky Ujistěte se, že jsou vaše bezpečnostní prvky aktualizované tak, aby zahrnovaly novou architekturu, včetně pravidel brány firewall a řízení přístupu.

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

Pro každou službu Azure ve vaší architektuře se podívejte na příslušného průvodce službami Azure v architektuře. Pro model moderní webové aplikace potřebujete systém zasílání zpráv, který podporuje asynchronní zasílání zpráv, aplikační platformu, která podporuje kontejnerizaci a úložiště imagí kontejneru.

• Zvolte frontu zpráv. Fronta zpráv je důležitou součástí architektur orientovaných na služby. Oddělí odesílatele zpráv a příjemce, aby bylo možné asynchronní zasílání zpráv. Pokyny k výběru služby zasílání zpráv Azure použijte k výběru systému zasílání zpráv Azure, který podporuje vaše potřeby návrhu. Azure má tři služby zasílání zpráv: Azure Event Grid, Azure Event Hubs a Service Bus. Začněte službou Service Bus jako výchozí volbou a použijte další dvě možnosti, pokud Service Bus nevyhovuje vašim potřebám.
  
  

  Služba	Případ použití
  Service Bus	Zvolte Service Bus pro spolehlivé, seřazené a případně transakční doručování vysoce hodnotných zpráv v podnikových aplikacích.
  Event Grid	Pokud potřebujete efektivně zpracovávat velký počet diskrétních událostí, zvolte Event Grid. Event Grid je škálovatelný pro aplikace řízené událostmi, u kterých je potřeba směrovat mnoho malých nezávislých událostí (jako jsou změny stavu prostředků) na předplatitele v modelu s nízkou latencí a publikováním odběru.
  Event Hubs	Zvolte službu Event Hubs pro masivní příjem dat s vysokou propustností, jako jsou telemetrie, protokoly nebo analýzy v reálném čase. Služba Event Hubs je optimalizovaná pro scénáře streamování, ve kterých je potřeba hromadná data ingestovat a zpracovávat nepřetržitě.

• Implementujte službu kontejneru. Pro části aplikace, které chcete kontejnerizovat, potřebujete aplikační platformu, která podporuje kontejnery. K rozhodování použijte pokyny k volbě služby kontejneru Azure. Azure má tři hlavní služby kontejnerů: Azure Container Apps, Azure Kubernetes Service (AKS) a Aplikace Azure Service. Začněte s Container Apps jako výchozí volbou a použijte další dvě možnosti, pokud Container Apps nevyhovuje vašim potřebám.
  
  

  Služba	Případ použití
  Container Apps	Zvolte Container Apps, pokud potřebujete bezserverovou platformu, která automaticky škáluje a spravuje kontejnery v aplikacích řízených událostmi.
  AKS	Pokud potřebujete podrobnou kontrolu nad konfiguracemi Kubernetes a pokročilými funkcemi pro škálování, sítě a zabezpečení, zvolte AKS.
  Web Apps pro kontejner	Pro nejjednodušší prostředí PaaS zvolte Web App for Containers ve službě App Service.

• Implementujte úložiště kontejneru. Při použití jakékoli výpočetní služby založené na kontejnerech je potřeba mít úložiště pro ukládání imagí kontejneru. Můžete použít veřejný registr kontejneru, jako je Docker Hub nebo spravovaný registr, jako je Azure Container Registry. S rozhodováním vám pomůže úvod do registrů kontejnerů v Azure.

Pokyny pro kód

Pokud chcete úspěšně oddělit a extrahovat nezávislou službu, musíte aktualizovat kód webové aplikace pomocí následujících vzorů návrhu: model strangler fig, model vyrovnávání zatížení na základě fronty, model konkurenčních spotřebitelů, model monitorování koncových bodů stavu a vzor opakování.

Obrázek 3 Role vzorů návrhu

1. Model Strangler Fig: Model Strangler Fig přírůstkově migruje funkce z monolitické aplikace do oddělené služby. Tento model implementujte v hlavní webové aplikaci, aby se postupně migrovaly funkce do nezávislých služeb směrováním provozu na základě koncových bodů.

2. Model vyrovnávání zatížení na základě fronty: Model vyrovnávání zatížení na základě fronty spravuje tok zpráv mezi producentem a příjemcem pomocí fronty jako vyrovnávací paměti. Tento model implementujte v části producenta oddělené služby pro asynchronní správu toku zpráv pomocí fronty.

3. Model Konkurenční spotřebitelé: Model Konkurující příjemci umožňuje více instancím oddělené služby nezávisle číst ze stejné fronty zpráv a soutěžit o zpracování zpráv. Tento model implementujte v oddělené službě za účelem distribuce úloh napříč několika instancemi.

4. Model monitorování koncových bodů stavu: Model Monitorování koncových bodů stavu zveřejňuje koncové body pro monitorování stavu a stavu různých částí webové aplikace. (4a) Tento model implementujte v hlavní webové aplikaci. (4b) Implementujte ji také v oddělené službě pro sledování stavu koncových bodů.

5. Model opakování: Vzor opakování zpracovává přechodné selhání opakováním operací, které můžou občas selhat. (5a) Tento model implementujte u všech odchozích volání do jiných služeb Azure v hlavní webové aplikaci, jako jsou volání fronty zpráv a privátní koncové body. (5b) Tento model implementujte také v oddělené službě, která zpracovává přechodné chyby při volání privátních koncových bodů.

Každý vzor návrhu poskytuje výhody, které jsou v souladu s jedním nebo více pilíři architektury Well-Architected Framework (viz následující tabulka).

Implementace vzoru Strangler Fig

Pomocí modelu Strangler Fig můžete postupně migrovat funkce z monolitického základu kódu do nových nezávislých služeb. Extrahujte nové služby z existujícího monolitického základu kódu a pomalu modernizujte důležité části webové aplikace. Při implementaci modelu Strangler Fig postupujte podle těchto doporučení:

• Nastavte vrstvu směrování. V monolitickém základu kódu webové aplikace implementujte vrstvu směrování, která směruje provoz na základě koncových bodů. Použijte vlastní logiku směrování podle potřeby ke zpracování konkrétních obchodních pravidel pro směrování provozu. Pokud /users máte například koncový bod v monolitické aplikaci a tuto funkci jste přesunuli do oddělené služby, směrovací vrstva směruje všechny požadavky na /users novou službu.

• Správa zavedení funkcí Pomocí knihoven pro správu funkcí .NET implementujte příznaky funkcí a postupné zavádění , abyste mohli postupně zavádět oddělené služby. Stávající monolitické směrování aplikací by mělo řídit, kolik žádostí oddělené služby obdrží. Začněte s malým procentem požadavků a zvyšte využití v průběhu času, protože získáte důvěru v jeho stabilitu a výkon. Například referenční implementace extrahuje funkci vykreslování lístků do samostatné služby, která se dá postupně zavést pro zpracování větší části požadavků na vykreslování lístků. Vzhledem k tomu, že nová služba prokáže svou spolehlivost a výkon, může nakonec převzít celou funkci vykreslování lístků z monolitu a dokončit přechod.

• Použijte fasádní službu (v případě potřeby). Služba fasády je užitečná, když jeden požadavek potřebuje pracovat s více službami nebo když chcete skrýt složitost základního systému před klientem. Pokud však oddělená služba nemá žádná veřejná rozhraní API, nemusí být nutná služba fasády. V monolitickém základu kódu webové aplikace implementujte façade službu pro směrování požadavků na příslušný back-end (monolitické nebo mikroslužby). V nové oddělené službě se ujistěte, že nová služba může zpracovávat požadavky nezávisle při přístupu přes fasádu.

Implementace modelu vyrovnávání zatížení na základě fronty

Implementujte model vyrovnávání zatížení na základě fronty v části producenta oddělené služby tak, aby asynchronně zpracovával úlohy, které nepotřebují okamžité odpovědi. Tento model zlepšuje celkovou odezvu systému a škálovatelnost pomocí fronty ke správě distribuce úloh. Umožňuje oddělení služby zpracovávat požadavky konzistentní rychlostí. Pokud chcete tento model efektivně implementovat, postupujte podle těchto doporučení:

• Použití odblokování front zpráv Ujistěte se, že proces, který odesílá zprávy do fronty, neblokuje jiné procesy při čekání na oddělení služby pro zpracování zpráv ve frontě. Pokud proces vyžaduje výsledek operace oddělené služby, máte alternativní způsob, jak zvládnout situaci při čekání na dokončení operace ve frontě. Například referenční implementace používá Service Bus a await klíčové slovo s messageSender.PublishAsync() k asynchronnímu publikování zpráv do fronty bez blokování vlákna, které spouští tento kód:

  // Asynchronously publish a message without blocking the calling thread
  await messageSender.PublishAsync(new TicketRenderRequestMessage(Guid.NewGuid(), ticket, null, DateTime.Now), CancellationToken.None);
  

  Tento přístup zajišťuje, aby hlavní aplikace zůstala responzivní a dokázala zpracovávat další úlohy současně, zatímco oddělená služba zpracovává požadavky zařazené do fronty s možností správy.

• Implementujte opakování a odebrání zprávy. Implementujte mechanismus pro opakování zpracování zpráv ve frontě, které nelze úspěšně zpracovat. Pokud chyby potrvají, měly by se tyto zprávy z fronty odebrat. Service Bus má například integrované funkce fronty opakování a nedoručených zpráv.

• Nakonfigurujte zpracování idempotentních zpráv. Logika, která zpracovává zprávy z fronty, musí být idempotentní pro zpracování případů, kdy může být zpráva zpracována více než jednou. Například referenční implementace používá ServiceBusClient.CreateProcessor s AutoCompleteMessages = true a ReceiveMode = ServiceBusReceiveMode.PeekLock k zajištění, aby zprávy byly zpracovány pouze jednou a lze je znovu zpracovat při selhání (viz následující kód).

  // Create a processor for idempotent message processing
  var processor = serviceBusClient.CreateProcessor(path, new ServiceBusProcessorOptions
  {
      // Allow the messages to be auto-completed
      // if processing finishes without failure.
      AutoCompleteMessages = true,
  
      // PeekLock mode provides reliability in that unsettled messages
      // will be redelivered on failure.
      ReceiveMode = ServiceBusReceiveMode.PeekLock,
  
      // Containerized processors can scale at the container level
      // and need not scale via the processor options.
      MaxConcurrentCalls = 1,
      PrefetchCount = 0
  });
  

• Umožňuje spravovat změny prostředí. Asynchronní zpracování může vést k tomu, že se úlohy okamžitě nedokončují. Uživatelé by měli vědět, kdy se jejich úkol stále zpracovává, aby nastavili správná očekávání a vyhnuli se nejasnostem. Pomocívizuálních Poskytněte uživatelům možnost dostávat oznámení, když je úkol hotový, například e-mail nebo nabízené oznámení.

Implementace modelu Konkurenční spotřebitelé

Implementujte model Konkurenční spotřebitelé v oddělených službách za účelem správy příchozích úkolů z fronty zpráv. Tento model zahrnuje distribuci úloh napříč několika instancemi oddělených služeb. Tyto služby zpracovávají zprávy z fronty, vylepšují vyrovnávání zatížení a zvyšují kapacitu systému pro zpracování souběžných požadavků. Model Konkurenční spotřebitelé je účinný v následujících případech:

• Posloupnost zpracování zpráv není zásadní.
• Fronta zůstává nedotčena poškozenými zprávami.
• Operace zpracování je idempotentní, což znamená, že ji lze použít vícekrát, aniž by se změnil výsledek nad rámec počáteční aplikace.

Pokud chcete implementovat model Konkurenční spotřebitelé, postupujte podle těchto doporučení:

• Zpracování souběžných zpráv Při přijímání zpráv z fronty se ujistěte, že je váš systém navržený tak, aby zpracovával více zpráv současně. Nastavte maximální počet souběžných volání na 1, aby jednotliví příjemci zpracovávali každou zprávu.

• Zakažte předběžné načítání. Zakažte předběžné načítání zpráv, aby příjemci načítali zprávy jenom tehdy, když jsou připravení.

• Používejte spolehlivé režimy zpracování zpráv. Použijte spolehlivý režim zpracování, například PeekLock (nebo jeho ekvivalent), který automaticky opakuje zprávy, které selžou zpracování. Tento režim zvyšuje spolehlivost oproti metodám při odstraňování. Pokud se jednomu pracovnímu procesu nepodaří zpracovat zprávu, musí být jiný schopen ji zpracovat bez chyb, a to i v případě, že je zpráva zpracována vícekrát.

• Implementujte zpracování chyb. Směrování poškozených nebo nezpracovaných zpráv do samostatné fronty s nedoručenými písmeny Tento návrh zabraňuje opakovanému zpracování. Můžete například zachytit výjimky během zpracování zpráv a přesunout problematickou zprávu do samostatné fronty.

• Zpracování zpráv mimo pořadí Navrhnou uživatele pro zpracování zpráv, které přicházejí z posloupnosti. Několik paralelních příjemců znamená, že můžou zpracovávat zprávy mimo pořadí.

• Škálování na základě délky fronty Služby využívající zprávy z fronty by měly automaticky škálovat na základě délky fronty. Automatické škálování na základě škálování umožňuje efektivní zpracování špiček příchozích zpráv.

• Použijte frontu pro odpovědi na zprávy. Pokud systém vyžaduje oznámení pro následné zpracování zpráv, nastavte vyhrazenou frontu odpovědí nebo odpovědí. Toto nastavení rozdělí provozní zasílání zpráv z procesů oznámení.

• Používejte bezstavové služby. Zvažte použití bezstavových služeb ke zpracování požadavků z fronty. Umožňuje snadné škálování a efektivní využití prostředků.

• Nakonfigurujte protokolování. Integrujte protokolování a zpracování konkrétních výjimek v rámci pracovního postupu zpracování zpráv. Zaměřte se na zachycení chyb serializace a nasměrování těchto problematických zpráv do mechanismu nedoručených zpráv. Tyto protokoly poskytují cenné přehledy pro řešení potíží.

Například referenční implementace používá model Konkurující příjemci ve bezstavové službě spuštěné v Container Apps ke zpracování žádostí o vykreslování lístků z fronty služby Service Bus. Konfiguruje procesor fronty pomocí:

• AutoCompleteMessages: Automaticky dokončí zprávy, pokud se zpracovávají bez selhání.
• ReceiveMode: Používá režim PeekLock a znovu odešle zprávy, pokud nejsou vyřešené.
• MaxConcurrentCalls: Nastavte na 1 pro zpracování jedné zprávy najednou.
• PrefetchCount: Nastavte na hodnotu 0, aby se zabránilo předběžnému načítání zpráv.

Procesor protokoluje podrobnosti zpracování zpráv, které pomáhají při řešení potíží a monitorování. Zaznamenává chyby deserializace a směruje neplatné zprávy do fronty nedoručených zpráv, což brání opakovanému zpracování chybných zpráv. Služba se škáluje na úrovni kontejneru, což umožňuje efektivní zpracování špiček zpráv na základě délky fronty.

// Create a processor for the given queue that will process
// incoming messages.
var processor = serviceBusClient.CreateProcessor(path, new ServiceBusProcessorOptions
{
    // Allow the messages to be auto-completed
    // if processing finishes without failure.
    AutoCompleteMessages = true,
    // PeekLock mode provides reliability in that unsettled messages
    // are redelivered on failure.
    ReceiveMode = ServiceBusReceiveMode.PeekLock,
    // Containerized processors can scale at the container level
    // and need not scale via the processor options.
    MaxConcurrentCalls = 1,
    PrefetchCount = 0
});

// Called for each message received by the processor.
processor.ProcessMessageAsync += async args =>
{
    logger.LogInformation("Processing message {MessageId} from {ServiceBusNamespace}/{Path}", args.Message.MessageId, args.FullyQualifiedNamespace, args.EntityPath);
    // Unhandled exceptions in the handler will be caught by
    // the processor and result in abandoning and dead-lettering the message.
    try
    {
        var message = args.Message.Body.ToObjectFromJson<T>();
        await messageHandler(message, args.CancellationToken);
        logger.LogInformation("Successfully processed message {MessageId} from {ServiceBusNamespace}/{Path}",args.Message.MessageId, args.FullyQualifiedNamespace, args.EntityPath);
    }
    catch (JsonException)
    {
        logger.LogError("Invalid message body; could not be deserialized to {Type}", typeof(T));
        await args.DeadLetterMessageAsync(args.Message, $"Invalid message body; could not be deserialized to {typeof(T)}",cancellationToken: args.CancellationToken);
    }
};

Implementace modelu monitorování koncových bodů stavu

Implementujte model monitorování koncových bodů stavu v hlavním kódu aplikace a oddělte kód služby pro sledování stavu koncových bodů aplikace. Orchestrátory, jako jsou AKS nebo Container Apps, můžou tyto koncové body dotazovat, aby ověřili stav služby a restartoval instance, které nejsou v pořádku. ASP.NET aplikace Core můžou přidat vyhrazený middleware pro kontrolu stavu, který efektivně obsluhuje data o stavu koncového bodu a klíčové závislosti. Pokud chcete implementovat model monitorování koncových bodů stavu, postupujte podle těchto doporučení:

• Implementujte kontroly stavu. K zajištění koncových bodů kontroly stavu použijte middleware ASP.NET Core Health Checks.

• Ověřte závislosti. Ujistěte se, že kontroly stavu ověřují dostupnost klíčových závislostí, jako je databáze, úložiště a systém zasílání zpráv. Balíček aspNetCore.Diagnostics.HealthChecks, který není microsoftem, může implementovat kontroly závislostí kontroly stavu pro řadu běžných závislostí aplikací.

  Referenční implementace používá například ASP.NET middleware kontroly stavu Core k zveřejnění koncových bodů kontroly stavu pomocí AddHealthChecks() metody v objektu builder.Services . Kód ověří dostupnost klíčových závislostí, služby Azure Blob Storage a fronty Service Bus pomocí AddAzureBlobStorage() metod a AddAzureServiceBusQueue() metod, které jsou součástí AspNetCore.Diagnostics.HealthChecks balíčku. Container Apps umožňuje nakonfigurovat sondy stavu, které jsou monitorované, aby se měřily, jestli jsou aplikace v pořádku nebo potřebují recyklaci.

  // Add health checks, including health checks for Azure services
  // that are used by this service.
  // The Blob Storage and Service Bus health checks are provided by
  // AspNetCore.Diagnostics.HealthChecks
  // (a popular open source project) rather than by Microsoft. 
  // https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks
  builder.Services.AddHealthChecks()
  .AddAzureBlobStorage(options =>
  {
      // AddAzureBlobStorage will use the BlobServiceClient registered in DI
      // We just need to specify the container name
      options.ContainerName = builder.Configuration.GetRequiredConfigurationValue("App:StorageAccount:Container");
  })
  .AddAzureServiceBusQueue(
      builder.Configuration.GetRequiredConfigurationValue("App:ServiceBus:Host"),
      builder.Configuration.GetRequiredConfigurationValue("App:ServiceBus:RenderRequestQueueName"),
      azureCredentials);
  
  // Further app configuration omitted for brevity
  app.MapHealthChecks("/health");
  

• Konfigurace prostředků Azure Nakonfigurujte prostředky Azure tak, aby používaly adresy URL kontroly stavu aplikace k potvrzení aktivity a připravenosti. Například referenční implementace používá Bicep ke konfiguraci adres URL kontroly stavu pro potvrzení aktivity a připravenosti prostředku Azure. Sonda aktivity, která každých 10 sekund po počátečním zpoždění 2 sekundy dosáhne /health koncového bodu.

  probes: [
    {
      type: 'liveness'
      httpGet: {
        path: '/health'
        port: 8080
      }
      initialDelaySeconds: 2
      periodSeconds: 10
    }
  ]
  

Implementace vzoru opakování

Model opakování umožňuje aplikacím zotavit se z přechodných chyb. Model Opakování je centrální pro model Reliable Web App, takže vaše webová aplikace by už měla používat model Opakování. Použijte model Opakování na požadavky na systémy zasílání zpráv a požadavky vydané oddělenými službami, které extrahujete z webové aplikace. Pokud chcete implementovat vzor opakování, postupujte podle těchto doporučení:

• Nakonfigurujte možnosti opakování. Při integraci s frontou zpráv nezapomeňte nakonfigurovat klienta zodpovědného za interakce s frontou s odpovídajícím nastavením opakování. Zadejte parametry, jako je maximální počet opakování, zpoždění mezi opakovanými pokusy a maximální zpoždění.

• Používejte exponenciální zpochybnění. Implementujte exponenciální strategii zpoždování pro pokusy o opakování. To znamená zvýšení doby mezi jednotlivými opakováními exponenciálním způsobem, což pomáhá snížit zatížení systému během období vysokého počtu selhání.

• Použijte funkci opakování sady SDK. Pro služby se specializovanými sadami SDK, jako je Service Bus nebo Blob Storage, použijte integrované mechanismy opakování. Integrované mechanismy opakování jsou optimalizované pro obvyklé případy použití služby a můžou efektivněji zpracovávat opakování s méně požadovanou konfigurací ve vaší části. Například referenční implementace používá předdefinované funkce opakování sady Service Bus SDK (ServiceBusClient a ServiceBusRetryOptions). Objekt ServiceBusRetryOptions načte nastavení MessageBusOptions pro konfiguraci nastavení opakování, jako jsou MaxRetries, Delay, MaxDelay a TryTimeout.

  // ServiceBusClient is thread-safe and can be reused for the lifetime
  // of the application.
  services.AddSingleton(sp =>
  {
      var options = sp.GetRequiredService<IOptions<MessageBusOptions>>().Value;
      var clientOptions = new ServiceBusClientOptions
      {
          RetryOptions = new ServiceBusRetryOptions
          {
              Mode = ServiceBusRetryMode.Exponential,
              MaxRetries = options.MaxRetries,
              Delay = TimeSpan.FromSeconds(options.BaseDelaySecondsBetweenRetries),
              MaxDelay = TimeSpan.FromSeconds(options.MaxDelaySeconds),
              TryTimeout = TimeSpan.FromSeconds(options.TryTimeoutSeconds)
          }
      };
      return new ServiceBusClient(options.Host, azureCredential ?? new DefaultAzureCredential(), clientOptions);
  });
  

• Přijměte standardní knihovny odolnosti pro klienty HTTP. 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.

• Zpracování uzamčení zpráv U systémů založených na zprávách implementujte strategie zpracování zpráv, které podporují opakování bez ztráty dat, například použití režimů peek-lock, pokud jsou k dispozici. Po opakovaných selháních se ujistěte, že se neúspěšné zprávy efektivně opakují a přesunou se do fronty nedoručených zpráv.

Implementace distribuovaného trasování

S tím, jak se aplikace stávají více orientovanými na služby a jejich komponenty jsou oddělené, je monitorování toku provádění mezi službami zásadní. Model moderní webové aplikace používá Application Insights a Azure Monitor k získání přehledu o stavu a výkonu aplikací prostřednictvím rozhraní API OpenTelemetry, která podporují distribuované trasování.

Distribuované trasování sleduje požadavek uživatele při procházení více služeb. Při přijetí požadavku se označí identifikátorem trasování, který se předá jiným komponentám prostřednictvím hlaviček HTTP a vlastnosti služby Service Bus během vyvolání závislostí. Trasování a protokoly pak zahrnují identifikátor trasování i identifikátor aktivity (nebo identifikátor rozsahu), který odpovídá konkrétní komponentě a její nadřazené aktivitě. Monitorovací nástroje, jako je Application Insights, ji používají k zobrazení stromu aktivit a protokolů napříč různými službami, které jsou zásadní pro monitorování distribuovaných aplikací.

• Nainstalujte knihovny OpenTelemetry. Pomocí knihoven instrumentace můžete povolit trasování a metriky z běžných komponent. Přidejte vlastní instrumentaci s System.Diagnostics.ActivitySource a System.Diagnostics.Activity v případě potřeby. Pomocí knihoven exportéru můžete naslouchat diagnostice OpenTelemetry a zaznamenávat je v trvalých úložištích. Využijte existující vývozce nebo vytvořte vlastní pomocí System.Diagnostics.ActivityListener.

• Nastavte OpenTelemetry. Použijte distribuci OpenTelemetry (Azure.Monitor.OpenTelemetry.AspNetCore) služby Azure Monitor. Ujistěte se, že exportuje diagnostiku do Application Insights a zahrnuje integrovanou instrumentaci pro běžné metriky, trasování, protokoly a výjimky z modulu runtime .NET a ASP.NET Core. Zahrňte další balíčky instrumentace OpenTelemetry pro klienty SQL, Redis a Azure SDK.

• Monitorování a analýza Po konfiguraci se ujistěte, že se protokoly, trasování, metriky a výjimky zaznamenávají a odesílají do Application Insights. Ověřte, že jsou zahrnuté identifikátory trasování, aktivity a nadřazené aktivity, což umožňuje Application Insights poskytovat ucelenou viditelnost trasování napříč protokoly HTTP a hranicemi služby Service Bus. Pomocí tohoto nastavení můžete efektivně monitorovat a analyzovat aktivity vaší aplikace napříč službami.

Ukázka moderní webové aplikace používá distribuci OpenTelemetry (Azure.Monitor.OpenTelemetry.AspNetCore) služby Azure Monitor. Další balíčky instrumentace se používají pro klienty SQL, Redis a Azure SDK. OpenTelemetry se konfiguruje ve službě moderní webové aplikace pro vykreslování lístků takto:

builder.Logging.AddOpenTelemetry(o => 
{ 
    o.IncludeFormattedMessage = true; 
    o.IncludeScopes = true; 
}); 

builder.Services.AddOpenTelemetry() 
    .UseAzureMonitor(o => o.ConnectionString = appInsightsConnectionString) 
    .WithMetrics(metrics => 
    { 
        metrics.AddAspNetCoreInstrumentation() 
                .AddHttpClientInstrumentation() 
                .AddRuntimeInstrumentation(); 
    }) 
    .WithTracing(tracing => 
    { 
        tracing.AddAspNetCoreInstrumentation() 
                .AddHttpClientInstrumentation() 
                .AddSource("Azure.*"); 
    }); 

Metoda builder.Logging.AddOpenTelemetry směruje veškeré protokolování přes OpenTelemetry a zajišťuje konzistentní trasování a protokolování napříč aplikací. Registrací služeb OpenTelemetry v builder.Services.AddOpenTelemetryaplikaci se nastaví shromažďování a export diagnostiky, které se pak odesílají do Application Insights prostřednictvím UseAzureMonitor. Kromě toho je instrumentace klientů pro komponenty, jako je Service Bus a klienti HTTP, nakonfigurovaná prostřednictvím WithMetrics a WithTracingpovolením automatické metriky a shromažďování trasování, aniž by bylo nutné změnit stávající využití klienta, pouze aktualizaci konfigurace.

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

Pokud chcete nakonfigurovat ověřování a autorizaci u všech nových služeb Azure (identit úloh), které přidáte do webové aplikace, postupujte podle těchto doporučení:

• Používejte spravované identity pro každou novou službu. Každá nezávislá služba by měla mít vlastní identitu a používat spravované identity pro ověřování mezi službami. Spravované identity eliminují potřebu správy přihlašovacích údajů v kódu a snižují riziko úniku přihlašovacích údajů. Pomáhají vám vyhnout se vkládání citlivých informací, jako jsou připojovací řetězec do kódu nebo konfiguračních souborů.

• Udělte každé nové službě nejnižší oprávnění. Každému novému identitě služby přiřaďte pouze potřebná oprávnění. Pokud například identita potřebuje odeslat jenom do registru kontejneru, neudělujte jí oprávnění k přijetí změn. Tato oprávnění pravidelně zkontrolujte a podle potřeby upravte. Pro různé role, jako je nasazení a aplikace, použijte různé identity. Tím se omezí potenciální poškození, pokud dojde k ohrožení jedné identity.

• Přijmout infrastrukturu jako kód (IaC). K definování a správě cloudových prostředků použijte bicep nebo podobné nástroje IaC. IaC zajišťuje konzistentní použití konfigurací zabezpečení ve vašich nasazeních a umožňuje řídit verze nastavení infrastruktury.

Pokud chcete nakonfigurovat ověřování a autorizaci pro uživatele (identity uživatelů), postupujte podle těchto doporučení:

• Udělte uživatelům nejnižší oprávnění. Stejně jako u služeb zajistěte, aby uživatelům byla udělena jenom oprávnění, která potřebují k provádění svých úloh. Pravidelně kontrolujte a upravujte tato oprávnění.

• Proveďte pravidelné audity zabezpečení. Pravidelně kontrolujte a auditujte nastavení zabezpečení. Vyhledejte všechny chybné konfigurace nebo nepotřebná oprávnění a okamžitě je opravte.

Referenční implementace používá IaC k přiřazování spravovaných identit do přidaných služeb a konkrétních rolí ke každé identitě. Definuje role a přístup k oprávněním pro nasazení (containerRegistryPushRoleId), vlastníka aplikace (containerRegistryPushRoleId) a aplikaci Container Apps (containerRegistryPullRoleIdviz následující kód).

roleAssignments: \[
    {
    principalId: deploymentSettings.principalId
    principalType: deploymentSettings.principalType
    roleDefinitionIdOrName: containerRegistryPushRoleId
    }
    {
    principalId: ownerManagedIdentity.outputs.principal_id
    principalType: 'ServicePrincipal'
    roleDefinitionIdOrName: containerRegistryPushRoleId
    }
    {
    principalId: appManagedIdentity.outputs.principal_id
    principalType: 'ServicePrincipal'
    roleDefinitionIdOrName: containerRegistryPullRoleId
    }
\]

Referenční implementace přiřadí spravovanou identitu jako novou identitu Container Apps při nasazení (viz následující kód).

module renderingServiceContainerApp 'br/public:avm/res/app/container-app:0.1.0' = {
  name: 'application-rendering-service-container-app'
  scope: resourceGroup()
  params: {
    // Other parameters omitted for brevity
    managedIdentities: {
      userAssignedResourceIds: [
        managedIdentity.id
      ]
    }
  }
}

Konfigurace nezávislého automatického škálování

Model moderní webové aplikace začíná roztřídět monolitickou architekturu a zavádí oddělení služeb. Když oddělíte architekturu webové aplikace, můžete nezávisle škálovat oddělené služby. Škálování služeb Azure tak, aby podporovaly nezávislou službu webové aplikace, nikoli celou webovou aplikaci, optimalizuje náklady na škálování při splnění požadavků. Pokud chcete kontejnery automaticky škálovat, postupujte podle těchto doporučení:

• Používejte bezstavové služby. Zajistěte, aby vaše služby byly bezstavové. Pokud vaše aplikace .NET obsahuje stav relace v procesu, externalizujte ji do distribuované mezipaměti, jako je Redis nebo databáze, jako je SQL Server.

• Nakonfigurujte pravidla automatického škálování. Použijte konfigurace automatického škálování, které poskytují nákladově nejefektivnější kontrolu nad vašimi službami. U kontejnerizovaných služeb poskytuje škálování na základě událostí, jako je automatické škálování řízené událostmi Kubernetes (KEDA), často podrobné řízení, které umožňuje škálování na základě metrik událostí. Container Apps a AKS podporují KEDA. Pro služby, které nepodporují KEDA, jako je App Service, použijte funkce automatického škálování poskytované samotnou platformou. Mezi tyto funkce často patří škálování na základě pravidel založených na metrikách nebo provozu HTTP.

• Nakonfigurujte minimální repliky. Pokud chcete zabránit studenému startu, nakonfigurujte nastavení automatického škálování tak, aby zachovalo minimálně jednu repliku. Studený start je, když inicializujete službu ze zastaveného stavu, což často vytváří zpožděnou odpověď. Pokud je minimalizace nákladů prioritou a můžete tolerovat zpoždění studeného spuštění, nastavte minimální počet replik na 0 při konfiguraci automatického škálování.

• Nakonfigurujte období cooldownu. K zavedení zpoždění mezi událostmi škálování použijte odpovídající období cooldownu. Cílem je zabránit nadměrným aktivitám škálování aktivovaným dočasnými špičkami zatížení.

• Nakonfigurujte škálování na základě fronty. Pokud vaše aplikace používá frontu zpráv, jako je Service Bus, nakonfigurujte nastavení automatického škálování tak, aby se škálovat na základě délky fronty se zprávami požadavku. Cílem škálování je udržovat jednu repliku služby pro všechny N zprávy ve frontě (zaokrouhleno nahoru).

Referenční implementace například pomocí škálovače KEDA služby Service Bus škáluje aplikaci kontejneru na základě délky fronty. Škáluje service-bus-queue-length-rule službu na základě délky zadané fronty služby Service Bus. Parametr messageCount je nastavený na 10, takže škálovač má jednu repliku služby pro každých 10 zpráv ve frontě. Parametry scaleMaxReplicas nastaví scaleMinReplicas maximální a minimální počet replik pro službu. Tajný queue-connection-string klíč, který obsahuje připojovací řetězec pro frontu služby Service Bus, se načte ze služby Azure Key Vault. Tento tajný klíč slouží k ověření škálovače ve službě Service Bus.

scaleRules: [
  {
    name: 'service-bus-queue-length-rule'
    custom: {
      type: 'azure-servicebus'
      metadata: {
        messageCount: '10'
        namespace: renderRequestServiceBusNamespace
        queueName: renderRequestServiceBusQueueName
      }
      auth: [
        {
          secretRef: 'render-request-queue-connection-string'
          triggerParameter: 'connection'
        }
      ]
    }
  }
]

scaleMaxReplicas: 5
scaleMinReplicas: 0

Nasazení služby Containerize

Kontejnerizace znamená, že všechny závislosti pro funkci aplikace jsou zapouzdřeny v odlehčené imagi, která se dá spolehlivě nasadit do široké škály hostitelů. Pokud chcete nasazení kontejnerizovat, postupujte podle těchto doporučení:

• Identifikujte hranice domény. Začněte tím, že identifikujete hranice domény v rámci monolitické aplikace. To vám pomůže určit, které části aplikace můžete extrahovat do samostatných služeb.

• Vytváření imagí Dockeru Při vytváření imagí Dockeru pro služby .NET použijte chycené základní image. Tyto image obsahují pouze minimální sadu balíčků potřebných ke spuštění .NET, což minimalizuje velikost balíčku i prostor pro útok.

• Použijte vícefázové soubory Dockerfile. Implementujte vícefázové soubory Dockerfile pro oddělení prostředků času sestavení od image kontejneru modulu runtime. Pomáhá udržovat produkční image v malém a zabezpečeném prostředí.

• Spusťte ho jako uživatele, který není v kořenovém adresáři. Spusťte kontejnery .NET jako uživatele, který neníroot (prostřednictvím uživatelského jména nebo UID, $APP_UID), aby byl v souladu s principem nejnižšího oprávnění. Omezuje potenciální účinky ohroženého kontejneru.

• Poslouchejte na portu 8080. Při spuštění jako uživatel bez kořene nakonfigurujte aplikaci tak, aby naslouchala na portu 8080. Je to běžná konvence pro uživatele, kteří nejsou kořeny.

• Zapouzdření závislostí Ujistěte se, že jsou všechny závislosti pro funkci aplikace zapouzdřené v imagi kontejneru Dockeru. Zapouzdření umožňuje spolehlivé nasazení aplikace do široké škály hostitelů.

• Zvolte správné základní image. Základní image, kterou zvolíte, závisí na vašem prostředí nasazení. Pokud například nasazujete do Container Apps, musíte použít image Dockeru pro Linux.

Například referenční implementace používá vícefázový proces sestavení. Počáteční fáze kompilují a sestavují aplikaci pomocí úplné image sady SDK (mcr.microsoft.com/dotnet/sdk:8.0-jammy). Konečná image modulu runtime se vytvoří ze chiseled základní image, která vylučuje sadu SDK a artefakty sestavení. Služba běží jako uživatel bez kořene aUSER $APP_UID zveřejňuje port 8080. Závislosti potřebné pro fungování aplikace jsou zahrnuty v imagi Dockeru, jak ukazují příkazy ke kopírování souborů projektu a obnovení balíčků. Použití imagí založených na Linuxu (mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled) zajišťuje kompatibilitu s Container Apps, která vyžaduje kontejnery Linuxu pro nasazení.

# Build in a separate stage to avoid copying the SDK into the final image
FROM mcr.microsoft.com/dotnet/sdk:8.0-jammy AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src

# Restore packages
COPY ["Relecloud.TicketRenderer/Relecloud.TicketRenderer.csproj", "Relecloud.TicketRenderer/"]
COPY ["Relecloud.Messaging/Relecloud.Messaging.csproj", "Relecloud.Messaging/"]
COPY ["Relecloud.Models/Relecloud.Models.csproj", "Relecloud.Models/"]
RUN dotnet restore "./Relecloud.TicketRenderer/Relecloud.TicketRenderer.csproj"

# Build and publish
COPY . .
WORKDIR "/src/Relecloud.TicketRenderer"
RUN dotnet publish "./Relecloud.TicketRenderer.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

# Chiseled images contain only the minimal set of packages needed for .NET 8.0
FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled AS final
WORKDIR /app
EXPOSE 8080

# Copy the published app from the build stage
COPY --from=build /app/publish .

# Run as non-root user
USER $APP_UID
ENTRYPOINT ["dotnet", "./Relecloud.TicketRenderer.dll"]

Nasazení referenční implementace

Nasaďte referenční implementaci moderního vzoru webové aplikace pro .NET. V úložišti jsou pokyny pro vývoj i produkční nasazení. Po nasazení můžete simulovat a sledovat vzory návrhu.

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