Moderní vzor webové aplikace pro Javu

Tento článek popisuje, jak implementovat model moderní webové aplikace. Model moderní webové aplikace definuje, jak modernizovat cloudové webové aplikace a zavést architekturu zaměřenou na služby. Tento model poskytuje pokyny k preskriptivní architektuře, kódu a konfiguraci, které odpovídají principům architektury Azure Well-Architected Framework. Tento vzor vychází ze vzoru Reliable Web App.

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

Model moderní webové aplikace vám pomůže optimalizovat oblasti vaší webové aplikace s vysokou poptávkou. Poskytuje podrobné pokyny pro oddělení těchto oblastí, aby bylo možné nezávislé škálování pro optimalizaci nákladů. Tento přístup umožňuje přidělit vyhrazené prostředky kritickým komponentám, což zvyšuje 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í. Umožňuje také nezávislou správu verzí jednotlivých komponent aplikace.

Implementace vzoru moderní webové aplikace

Tento článek obsahuje pokyny k implementaci vzoru moderní webové aplikace. Pomocí následujících odkazů přejděte na konkrétní 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 ke kódu. Implementujte čtyři vzory návrhu pro optimalizaci oddělených komponent: Strangler Fig, Queue-Based Vyrovnávání zatížení, Konkurující spotřebitelé a monitorování koncových bodů stavu.
• Pokyny ke konfiguraci. Nakonfigurujte ověřování, autorizaci, automatické škálování a kontejnerizaci pro oddělené komponenty.

Pokyny pro architekturu

Model moderní webové aplikace vychází ze vzoru Reliable Web App. Vyžaduje několik dalších komponent architektury. Potřebujete frontu zpráv, platformu kontejneru, službu úložiště a registr kontejnerů, jak je znázorněno v následujícím diagramu:

Pro vyšší cíl na úrovni služby (SLO) můžete do architektury webové aplikace přidat druhou oblast. Nakonfigurujte nástroj pro vyrovnávání zatížení tak, aby směrovat provoz do druhé oblasti tak, aby podporoval konfiguraci aktivní-aktivní nebo aktivní-pasivní v závislosti na vašich obchodních potřebách. Obě oblasti vyžadují stejné služby, s výjimkou jedné oblasti má centrální virtuální síť. 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 hostitele bastionu do virtuální sítě centra, abyste je mohli spravovat s rozšířeným zabezpečením. Následující diagram znázorňuje tuto architekturu:

Oddělení architektury

Pokud chcete implementovat model moderní webové aplikace, musíte oddělit stávající architekturu webové aplikace. Oddělení architektury znamená rozdělení monolitické aplikace do menších nezávislých služeb, z nichž každá zodpovídá za konkrétní funkci nebo funkci. 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 je kandidátem na oddělení. Služby, které představují jedinečné obchodní funkce a mají méně závislostí, jsou vhodnými kandidáty.

• Vyhodnoťte výhody služby. Zaměřte se na služby, které nejvíce využívají nezávislé škálování. Například externí závislost, jako je poskytovatel e-mailové služby v obchodní aplikaci, může vyžadovat větší izolaci od selhání. Zvažte služby, u které dochází k častým aktualizacím nebo změnám. Oddělení těchto služeb umožňuje nezávislé nasazení a snižuje riziko ovlivnění jiných částí aplikace.

• Vyhodnoťte technickou proveditelnost. Prozkoumejte aktuální architekturu a identifikujte technická omezení a závislosti, které by mohly ovlivnit proces oddělení. Plánování 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 chcete extrahovat. Pokyny najdete v části Výběr správných služeb Azure části tohoto článku.

• Oddělte službu webové aplikace. Definujte jasná rozhraní a rozhraní API, která nově extrahované služby webových aplikací můžou používat k interakci s jinými částmi systému. Navrhujte strategii správy dat, která každé službě umožňuje spravovat vlastní data, ale zajišťuje konzistenci a integritu. Konkrétní strategie implementace a vzory návrhu, které se mají použít během tohoto procesu extrakce, najdete v části Pokyny ke kódu části.

• Pro oddělené služby používejte nezávislé úložiště. Pro zjednodušení správy verzí a nasazení se ujistěte, že každá oddělená služba má vlastní úložiště dat. Například referenční implementace odděluje e-mailovou službu od webové aplikace a eliminuje potřebu služby pro přístup k databázi. Místo toho služba komunikuje se stavem doručení e-mailu zpět do webové aplikace prostřednictvím zprávy služby Azure Service Bus a webová aplikace uloží poznámku do své databáze.

• Implementujte samostatné kanály nasazení pro každou oddělenou službu. Pokud implementujete samostatné kanály nasazení, je možné každou službu aktualizovat podle vlastního plánu. Pokud různé týmy nebo organizace ve vaší společnosti vlastní různé služby, použití samostatných kanálů nasazení dává každému týmu kontrolu nad 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 se službou Service Bus a použijte jednu z dalších dvou možností, 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, ve 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 publikování a odběru s nízkou latencí.
  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 prvky aplikace, které chcete kontejnerizovat, potřebujete aplikační platformu, která podporuje kontejnery. Zvolit službu kontejneru Azure pokyny vám můžou pomoct ji vybrat. 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 a použijte jednu z dalších dvou možností, 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 App for Containers	Pro nejjednodušší prostředí PaaS zvolte Web App for Containers ve službě App Service.

• Implementujte úložiště kontejneru. Pokud používáte výpočetní službu založenou na kontejneru, musíte 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. Pokyny k Úvod do registrů kontejnerů v Azure vám můžou pomoct vybrat.

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: Strangler Fig, Queue-Based vyrovnávání zatížení, konkurenční spotřebitelé, monitorování koncových bodů stavu a opakování. Následující diagram znázorňuje role těchto vzorů:

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 Konkurující spotřebitelé: Model Konkurující spotřebitelé umožňuje více instancí 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. vzor 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 komponent 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) Implementovat tento vzor v hlavní webové aplikaci, na všech odchozích voláních do jiných služeb Azure, jako jsou volání do 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. Následující tabulka obsahuje podrobnosti.

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 máte například v monolitické aplikaci koncový bod /users a tuto funkci přesunete do oddělené služby, směrovací vrstva směruje všechny požadavky na /users do nové služby.

• Správa zavedení funkcí Implementujte příznaky funkcí a postupné zavádění , abyste postupně zaváděli 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 jistotu o stabilitě a výkonu služby.

  Například referenční implementace extrahuje funkci doručování e-mailů do samostatné služby. Službu je možné postupně zavést, aby zvládla větší procento požadavků na odesílání e-mailů, které obsahují příručky podpory společnosti Contoso. Vzhledem k tomu, že nová služba prokáže svou spolehlivost a výkon, může nakonec převzít celou sadu e-mailových zodpovědností od monolitického dokončení přechodu.

• 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). Ujistěte se, že nová oddělená služba může zpracovávat požadavky nezávisle, když je přístupná 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, zatímco čeká, až oddělená služba zpracuje zprávy ve frontě. Pokud proces vyžaduje výsledek operace oddělené služby, implementujte alternativní způsob řešení situace při čekání na dokončení operace ve frontě. Například ve Spring Bootu můžete pomocí třídy StreamBridge asynchronně publikovat zprávy do fronty bez blokování volajícího vlákna:

  private final StreamBridge streamBridge;
  
  public SupportGuideQueueSender(StreamBridge streamBridge) {
      this.streamBridge = streamBridge;
  }
  
  // Asynchronously publish a message without blocking the calling thread
  @Override
  public void send(String to, String guideUrl, Long requestId) {
      EmailRequest emailRequest = EmailRequest.newBuilder()
              .setRequestId(requestId)
              .setEmailAddress(to)
              .setUrlToManual(guideUrl)
              .build();
  
      log.info("EmailRequest: {}", emailRequest);
  
      var message = emailRequest.toByteArray();
      streamBridge.send(EMAIL_REQUEST_QUEUE, message);
  
      log.info("Message sent to the queue");
  }
  

  Tento příklad v Javě používá StreamBridge k asynchronnímu odesílání zpráv. Tento přístup zajišťuje, že hlavní aplikace zůstane responzivní a dokáže zpracovávat další úlohy současně, zatímco oddělená služba zpracovává požadavky zařazené do fronty se spravovatelnou rychlostí.

• 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ů, ve kterých může být zpráva zpracována více než jednou. Ve Spring Bootu můžete použít @StreamListener nebo @KafkaListener s jedinečným identifikátorem zprávy, abyste zabránili duplicitnímu zpracování. Nebo můžete obchodní proces uspořádat tak, aby fungoval v funkčním přístupu se službou Spring Cloud Stream, kde consume je metoda definovaná způsobem, který při opakovaném spuštění vytvoří stejný výsledek. Seznam nastavení, která spravují chování spotřeby zpráv, najdete v tématu Spring Cloud Stream se službou Service Bus.

• Umožňuje spravovat změny uživatelského prostředí. Při použití asynchronního zpracování nemusí být úkoly dokončeny okamžitě. Pokud chcete nastavit očekávání a vyhnout se nejasnostem, ujistěte se, že uživatelé vědí, kdy se jejich úkoly stále zpracovávají. 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 Konkurující příjemci v oddělené službě pro správu 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. Model zvyšuje vyrovnávání zatížení a zvyšuje 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 po počáteční aplikaci.

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

• Zpracování souběžných zpráv Když služby přijímají zprávy z fronty, ujistěte se, že se systém předvídatelně škáluje konfigurací souběžnosti tak, aby odpovídal návrhu systému. Výsledky zátěžového testu vám můžou pomoct určit odpovídající počet souběžných zpráv, které se mají zpracovat. Můžete začít od jednoho, abyste změřili, jak systém funguje.

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

• Používejte spolehlivé režimy zpracování zpráv. Použijte spolehlivý režim zpracování, například Náhled-Lock, který automaticky opakuje zprávy, které selžou zpracování. Tento režim poskytuje větší spolehlivost než metody první odstraně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 nedoručených zpráv 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 problematické zprávy do samostatné fronty. Se službou Service Bus se zprávy přesunou do fronty dead-leter po zadaném počtu pokusů o doručení nebo při explicitním zamítnutí aplikace.

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

• Škálování na základě délky fronty Služby, které využívají zprávy z fronty, by se 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 váš systém vyžaduje oznámení pro zpracování po zprávách, nastavte vyhrazenou frontu odpovědí nebo odpovědí. Toto nastavení odděluje provozní zasílání zpráv od procesů oznámení.

• Používejte bezstavové služby. Zvažte použití bezstavových služeb ke zpracování požadavků z fronty. Díky tomu můžete snadno škálovat a efektivně využívat prostředky.

• 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íží.

Referenční implementace používá model Konkurující příjemci ve bezstavové službě, která běží v Container Apps, ke zpracování žádostí o doručování e-mailů z fronty služby Service Bus.

Procesor protokoluje podrobnosti zpracování zpráv, které vám pomůžou s řešením potíží a monitorováním. Zaznamenává chyby deserializace a poskytuje přehledy, které můžou být užitečné při ladění. Služba se škáluje na úrovni kontejneru, aby umožňovala efektivní zpracování špiček zpráv na základě délky fronty. Tady je kód:

@Configuration
public class EmailProcessor {

    private static final Logger log = LoggerFactory.getLogger(EmailProcessor.class);

    @Bean
    Function<byte[], byte[]> consume() {
        return message -> {

            log.info("New message received");

            try {
                EmailRequest emailRequest = EmailRequest.parseFrom(message);
                log.info("EmailRequest: {}", emailRequest);

                EmailResponse emailResponse = EmailResponse.newBuilder()
                        .setEmailAddress(emailRequest.getEmailAddress())
                        .setUrlToManual(emailRequest.getUrlToManual())
                        .setRequestId(emailRequest.getRequestId())
                        .setMessage("Email sent to " + emailRequest.getEmailAddress() + " with URL to manual " + emailRequest.getUrlToManual())
                        .setStatus(Status.SUCCESS)
                        .build();

                return emailResponse.toByteArray();

            } catch (InvalidProtocolBufferException e) {
                throw new RuntimeException("Error parsing email request message", e);
            }
        };
    }
}

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. Spring Boot Poháněcí zařízení poskytuje integrovanou podporu kontrol stavu. Může vystavit koncové body kontroly stavu pro klíčové závislosti, jako jsou databáze, zprostředkovatelé zpráv a systémy úložiště. Pokud chcete implementovat model monitorování koncových bodů stavu, postupujte podle těchto doporučení:

• Implementujte kontroly stavu. Pomocí ovladače Spring Boot můžete poskytovat koncové body kontroly stavu. Poháněcí zařízení zveřejňuje koncový bod /actuator/health, který obsahuje integrované indikátory stavu a vlastní kontroly různých závislostí. Pokud chcete koncový bod stavu povolit, přidejte do souboru pom.xml nebo build.gradle závislost spring-boot-starter-actuator:

  <!-- Add Spring Boot Actuator dependency -->
  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  

  Nakonfigurujte koncový bod stavu v application.properties, jak je znázorněno v referenční implementaci:

      management.endpoints.web.exposure.include=metrics,health,info,retry,retryevents
  

• Ověřte závislosti. Ovladač Spring Boot zahrnuje indikátory stavu pro různé závislosti, jako jsou databáze, zprostředkovatelé zpráv (RabbitMQ nebo Kafka) a služby úložiště. Pokud chcete ověřit dostupnost služeb Azure, jako je Azure Blob Storage nebo Service Bus, použijte technologie, jako je Azure Spring Apps nebo Micrometer, které poskytují indikátory stavu pro tyto služby. Pokud potřebujete vlastní kontroly, můžete je implementovat tak, že vytvoříte vlastní HealthIndicator bean:

  import org.springframework.boot.actuate.health.Health;
  import org.springframework.boot.actuate.health.HealthIndicator;
  import org.springframework.stereotype.Component;
  
  @Component
  public class CustomAzureServiceBusHealthIndicator implements HealthIndicator {
      @Override
      public Health health() {
          // Implement your health check logic here (for example, ping Service Bus).
          boolean isServiceBusHealthy = checkServiceBusHealth();
          return isServiceBusHealthy ? Health.up().build() : Health.down().build();
      }
  
      private boolean checkServiceBusHealth() {
          // Implement health check logic (pinging or connecting to the service).
          return true; // Placeholder. Implement the actual logic.
      }
  }
  

• Konfigurace prostředků Azure Nakonfigurujte prostředek Azure tak, aby používal adresy URL kontroly stavu aplikace k potvrzení aktivity a připravenosti. Terraform můžete například použít k potvrzení aktivity a připravenosti aplikací nasazených do Container Apps. Další informace najdete v tématu Sondy stavu v kontejnerových aplikacích.

Implementace vzoru opakování

Vzor opakování umožňuje aplikacím zotavit se z přechodných chyb. Tento model je centrální pro model Spolehlivé webové aplikace, takže vaše webová aplikace by už měla používat model opakování. Použijte vzor 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í. Nezapomeňte nakonfigurovat klienta, který odpovídá za interakci s frontou zpráv 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 zpětného odvrácení pro pokusy o opakování. Tato strategie zahrnuje zvýšení doby mezi jednotlivými opakováními exponenciálně, což pomáhá snížit zatížení systému v obdobích 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í. Tyto integrované mechanismy jsou optimalizované pro typické případy použití služby, můžou efektivněji zpracovávat opakování a vyžadovat méně konfigurace.

• Pro klienty HTTP používejte standardní knihovny odolnosti. Pro klienty HTTP můžete použít Resilience4j společně s Spring RestTemplate nebo WebClient ke zpracování opakovaných pokusů v komunikaci HTTP. RestTemplate můžete zabalit pomocí logiky opakování Resilience4j, která efektivně zpracovává přechodné chyby HTTP.

• 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. Pokud jsou například dostupné, použijte režimy náhledu zámku. 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.

Pokyny ke konfiguraci

Následující části obsahují pokyny k implementaci aktualizací konfigurace. Každá část odpovídá jednomu nebo více pilířům architektury Well-Architected.

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 zahrnutí citlivých informací, jako jsou připojovací řetězce v kódu nebo konfiguračních souborech.

• 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 je 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.

• Použití infrastruktury jako kódu (IaC). K definování a správě cloudových prostředků použijte Bicep nebo podobný nástroj IaC, jako je Terraform. 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ěli jenom oprávnění, která potřebují k provádění svých úkolů. Pravidelně kontrolujte a upravujte tato oprávnění.

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

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í definováním rolí pro nabízení a přijetí změn služby Container Registry. Tady je kód:

resource "azurerm_role_assignment" "container_app_acr_pull" {
  principal_id         = var.aca_identity_principal_id
  role_definition_name = "AcrPull"
  scope                = azurerm_container_registry.acr.id
}

resource "azurerm_user_assigned_identity" "container_registry_user_assigned_identity" {
  name                = "ContainerRegistryUserAssignedIdentity"
  resource_group_name = var.resource_group
  location            = var.location
}

resource "azurerm_role_assignment" "container_registry_user_assigned_identity_acr_pull" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_user_assigned_identity.container_registry_user_assigned_identity.principal_id
}


# For demo purposes, allow the current user to access the container registry.
# Note: When running as a service principal, this is also needed.
resource "azurerm_role_assignment" "acr_contributor_user_role_assignement" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "Contributor"
  principal_id         = data.azuread_client_config.current.object_id
}

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

Model moderní webové aplikace začne rozčlenit 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. Ujistěte se, že vaše služby nejsou bezstavové. Pokud vaše webová aplikace 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í založené na událostech, jako je Kubernetes Event-Driven Autoscaler (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ým spuštěním, nakonfigurujte nastavení automatického škálování tak, aby se zachovala minimálně jedna replika. Studený start je inicializace služby ze zastaveného stavu. Studená začátek často zpožďuje odpověď. Pokud je minimalizace nákladů prioritou a můžete tolerovat zpoždění studeného spuštění, nastavte při konfiguraci automatického škálování minimální počet replik na 0.

• 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 zpráv požadavku. Nástroj pro škálování se pokusí udržovat jednu repliku služby pro každou N zpráv ve frontě (zaokrouhleno nahoru).

Referenční implementace například používá škálovací nástroj KEDA služby Service Bus k automatickému škálování kontejnerové aplikace na základě délky fronty Service Bus. Pravidlo škálování s názvem service-bus-queue-length-ruleupraví počet replik služby na základě počtu zpráv v zadané frontě služby Service Bus. Parametr messageCount je nastaven na 10, který nakonfiguruje škálovací nástroj tak, aby přidal jednu repliku pro každých 10 zpráv ve frontě. Maximální počet replik (max_replicas) je nastaven na 10. Minimální počet replik je implicitně 0, pokud se nepřepíše. Tato konfigurace umožňuje službě vertikálně snížit kapacitu na nulu, pokud ve frontě nejsou žádné zprávy. Připojovací řetězec pro frontu Service Bus se uloží jako tajný kód v Azure s názvem azure-servicebus-connection-string, který se používá k ověření škálovače ve službě Service Bus. Tady je kód Terraformu:

    max_replicas = 10
    min_replicas = 1

    custom_scale_rule {
      name             = "service-bus-queue-length-rule"
      custom_rule_type = "azure-servicebus"
      metadata = {
        messageCount = 10
        namespace    = var.servicebus_namespace
        queueName    = var.email_request_queue_name
      }
      authentication {
        secret_name       = "azure-servicebus-connection-string"
        trigger_parameter = "connection"
      }
    }

Nasazení služby Containerize

Kontejnerizace je zapouzdření všech závislostí potřebných aplikací ve zjednoduš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 v monolitické aplikaci identifikujete hranice domény. 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 Java použijte oficiální základní image OpenJDK. Tyto image obsahují pouze minimální sadu balíčků, které Java potřebuje ke spuštění. Použití těchto imagí minimalizuje velikost balíčku i prostor pro útok.

• Použijte vícefázové soubory Dockerfile. Pomocí souboru Dockerfile s více fázemi oddělte prostředky v době sestavení od image kontejneru modulu runtime. Použití tohoto typu souboru pomáhá udržovat produkční image malé a zabezpečené. Můžete také použít předkonfigurovaný buildový server a zkopírovat soubor JAR do image kontejneru.

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

• Poslouchejte na portu 8080. Když spouštíte kontejnery jako uživatel, který není v kořenovém adresáři, nakonfigurujte aplikaci tak, aby naslouchala na portu 8080. Toto je běžná konvence pro uživatele, kteří nejsou kořeny.

• Zapouzdření závislostí Ujistěte se, že všechny závislosti, které aplikace potřebuje, jsou 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 nasadíte do Container Apps, musíte použít image Dockeru pro Linux.

Referenční implementace ukazuje proces sestavení Dockeru pro kontejnerizaci aplikace v Javě. Soubor Dockerfile používá jednofázové sestavení se základní imagí OpenJDK (mcr.microsoft.com/openjdk/jdk:17-ubuntu), která poskytuje nezbytné prostředí modulu runtime Java.

Soubor Dockerfile obsahuje následující kroky:

1. Deklarování svazku Je definován dočasný svazek (/tmp). Tento svazek poskytuje dočasné úložiště souborů, které je oddělené od hlavního systému souborů kontejneru.
2. Kopírování artefaktů Soubor JAR aplikace (email-processor.jar) se zkopíruje do kontejneru společně s agentem Application Insights (applicationinsights-agent.jar), který se používá k monitorování.
3. Nastavení vstupního bodu Kontejner je nakonfigurovaný tak, aby spustil aplikaci s povoleným agentem Application Insights. Kód používá java -javaagent k monitorování aplikace během běhu.

Soubor Dockerfile udržuje image malou jenom zahrnutím závislostí modulu runtime. Je vhodný pro prostředí nasazení, jako jsou Container Apps, které podporují kontejnery založené na Linuxu.

# Use the OpenJDK 17 base image on Ubuntu as the foundation.
FROM mcr.microsoft.com/openjdk/jdk:17-ubuntu

# Define a volume to allow temporary files to be stored separately from the container's main file system.
VOLUME /tmp

# Copy the packaged JAR file into the container.
COPY target/email-processor.jar app.jar

# Copy the Application Insights agent for monitoring.
COPY target/agent/applicationinsights-agent.jar applicationinsights-agent.jar

# Set the entrypoint to run the application with the Application Insights agent.
ENTRYPOINT ["java", "-javaagent:applicationinsights-agent.jar", "-jar", "/app.jar"]

Nasazení referenční implementace

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

Následující diagram znázorňuje architekturu referenční implementace:

stáhnout soubor Visia této architektury.