Moderní vzor webové aplikace pro Javu

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 s vysokou poptávkou vaší webové aplikace. 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í a nezávisle povolují 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, službu úložiště 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. 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 potřebách vaší firmy. Obě oblasti vyžadují stejné služby s výjimkou jedné oblasti má centrální virtuální síť, která se připojuje. Přijměte hvězdicovou síťovou topologii, která umožňuje 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í:

• Identifikujte hranice služeb Pomocí principů návrhu řízeného doménou identifikujte ohraničené kontexty v rámci monolitické aplikace. 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í. 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í. 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žbu webové aplikace. 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í úložiště dat, aby se usnadnilo správa verzí a nasazení. 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. 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 se 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 obr. 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í 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 požadavků 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.

  Referenční implementace například extrahuje funkci doručování e-mailů do samostatné služby, která se dá postupně zavést, aby zvládla větší část požadavků na odesílání e-mailů obsahujících 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). 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, 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í StreamBridge třídy asynchronně publikovat zprávy do fronty bez blokování volajícího vlákna (viz příklad kódu):

  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, 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. 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. Přečtěte si Spring Cloud Stream se službou Service Bus , kde najdete další seznam nastavení, která spravují chování způsobu využívání zpráv.

• 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 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, 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říjmu zpráv z fronty se ujistěte, že se systém předvídatelně škáluje tak, že nakonfiguruje souběžnost tak, aby odpovídal návrhu systému. Výsledky zátěžového testu vám pomůžou určit odpovídající počet souběžných zpráv, které se mají zpracovat, a můžete začít od jednoho, abyste mohli měřit, jak systém funguje.

• 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. U služby Service Bus se zprávy přesunou do fronty dead-leter po zadaném počtu pokusů o doručení nebo explicitním zamítnutí aplikací.

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

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

Procesor protokoluje podrobnosti zpracování zpráv, které pomáhají při řešení potíží a monitorování. Zaznamenává chyby deserializace a poskytuje přehledy potřebné při ladění procesu. Služba se škáluje na úrovni kontejneru, což umožňuje efektivní zpracování špiček zpráv na základě délky fronty (viz následující 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 poskytuje integrovanou podporu kontrol stavu pomocí ovladače Spring Boot, který 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. Ovladač Spring Boot zveřejňuje koncový bod /actuator/health , který obsahuje integrované indikátory stavu a vlastní kontroly různých závislostí. Pokud chcete povolit koncový bod stavu, přidejte do spring-boot-starter-actuator souboru pom.xml nebo build.gradle závislost.

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

  Nakonfigurujte koncový bod stavu, jak application.properties je znázorněno v referenční implementaci: txt 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 komunitní moduly plug-in, jako jsou integrace Azure Spring Apps nebo mikrometrů, které poskytují indikátory stavu těchto služeb. Pokud jsou potřeba vlastní kontroly, můžete je implementovat vytvořením vlastního HealthIndicator typu 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 (e.g., 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 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 ověření aktivity a připravenosti aplikací nasazených do container Apps pomocí adres URL kontroly stavu. Další informace najdete v tématu Sondy stavu v kontejnerových aplikacích.

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 zpětného odvrácení 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.

• Přijměte standardní knihovny odolnosti pro klienty HTTP. Pro klienty HTTP můžete použít odolnost 4* společně s RestTemplate nebo WebClient Springu ke zpracování opakovaných pokusů v komunikaci HTTP. Spring restTemplate je možné 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, 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.

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áhá 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 nástroje Bicep nebo podobné nástroje 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 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 oprávnění pro nasazení definováním rolí pro nabízení a přijetí změn služby Container Registry (viz následující 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 current user access to 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čí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 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 často poskytuje škálování na základě událostí, jako je automatické škálování řízené událostmi Kubernetes (KEDA), 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 každou N zprávu 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 v závislosti na počtu zpráv v zadané frontě služby Service Bus. Parametr messageCount je nastavený na 10, což znamená, že škálovač přidá jednu repliku pro každých 10 zpráv ve frontě. Maximální počet replik (max_replicas) je nastaven na 10 a minimální repliky jsou implicitně 0, pokud není přepsáno, což službě umožňuje vertikálně snížit kapacitu na nulu, pokud ve frontě nejsou žádné zprávy. Připojovací řetězec pro frontu Service Bus se bezpečně ukládá 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.

    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 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 Java použijte oficiální základní image OpenJDK. Tyto image obsahují jenom minimální sadu balíčků potřebných ke spuštění Javy, což minimalizuje velikost balíčku i prostor pro útok.

• Použijte vícefázové soubory Dockerfile. Pomocí vícefázových souborů Dockerfile oddělte prostředky času sestavení od image kontejneru modulu runtime. Pomáhá udržovat produkční image v malém a zabezpečeném prostředí. 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. Kontejnery Java spusťte 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.

Referenční implementace ukazuje proces sestavení Dockeru pro kontejnerizaci aplikace v Javě. Tento 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. Deklarace svazku: Je definován dočasný svazek (/tmp), který umožňuje dočasné úložiště souborů 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 spolu s agentem Application Insights (applicationinsights-agent.jar) pro monitorování.
3. Nastavení vstupního bodu: Kontejner je nakonfigurovaný tak, aby spustil aplikaci s povoleným agentem Application Insights a pomocí java -javaagent monitorování aplikace během běhu.

Tento soubor Dockerfile udržuje image štíhlou pouze zahrnutím závislostí modulu runtime, které jsou vhodné pro prostředí nasazení, jako je Container Apps, které podporují kontejnery založené na Linuxu.

# Use 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 entry point 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í můžete simulovat a sledovat vzory návrhu.

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