Model spolehlivé webové aplikace pro Javu

Tento článek obsahuje pokyny k implementaci vzoru Spolehlivé webové aplikace. Tento model popisuje, jak upravit (znovuplatformovat) webové aplikace pro migraci do cloudu. Nabízí preskriptivní architekturu, kód a pokyny pro konfiguraci v souladu s principy dobře navržená architektura.

Proč model Reliable Web App pro Javu?

Model Reliable Web App je sada principů a technik implementace, které definují, jak byste při migraci do cloudu měli znovu vytvořit webové aplikace. Zaměřuje se na minimální aktualizace kódu, které je potřeba udělat, aby byly úspěšné v cloudu. Následující doprovodné materiály používají referenční implementaci jako příklad v celém příkladu a řídí se replatformní cestou fiktivní společnosti Contoso Fiber, která poskytuje obchodní kontext vaší cesty. Před implementací vzoru Reliable Web App pro Javu měla Contoso Fiber monolitický místní systém pro správu účtů zákazníků (CAMS), který používal architekturu Spring Boot.

Implementace vzoru Reliable Web App

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

• Obchodní kontext: Srovnejte tyto pokyny s obchodním kontextem a zjistěte, jak definovat okamžité a dlouhodobé cíle, které řídí replatforming rozhodnutí.
• Pokyny k architektuře: Zjistěte, jak vybrat správné cloudové služby a navrhnout architekturu, která splňuje vaše obchodní požadavky.
• Pokyny pro kód: Implementace tří vzorů návrhu pro zlepšení spolehlivosti a efektivity výkonu webové aplikace v cloudu: opakování, jistič a modely doplňování do mezipaměti
• Pokyny ke konfiguraci: Konfigurace ověřování a autorizace, spravovaných identit, prostředí s právy, infrastruktury jako kódu a monitorování

Obchodní kontext

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

Společnost Contoso Fiber například chtěla rozšířit místní webovou aplikaci CAMS (Customer Account Management System) tak, aby se dostala do jiných oblastí. Pro splnění zvýšené poptávky ve webové aplikaci stanovili následující cíle:

• Použití změn kódu s nízkými náklady a vysokou hodnotou
• Dosažení cíle úrovně služeb (SLO) 99,9 %
• Přijetí postupů DevOps
• Vytváření prostředí optimalizovaných pro náklady
• Zvýšení spolehlivosti a zabezpečení

Společnost Contoso Fiber zjistila, že jejich místní infrastruktura nebyla nákladově efektivním řešením pro škálování aplikace. Rozhodli se tedy, že migrace webové aplikace CAMS do Azure je nákladově nejefektivnější způsob, jak dosáhnout svých okamžitých a budoucích cílů.

Pokyny pro architekturu

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

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

Návrh architektury

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

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

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

  

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

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

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

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

Například před přechodem do cloudu byla webová aplikace CAMS společnosti Contoso Fiber místní monolitická webová aplikace v Javě. Jedná se o aplikaci Spring Boot s databází PostgreSQL. Webová aplikace je obchodní aplikace podpory. Je to pro zaměstnance. Zaměstnanci společnosti Contoso Fiber tuto aplikaci používají ke správě případů podpory od svých zákazníků. Webová aplikace utrpěla běžné problémy se škálovatelností a nasazováním funkcí. Tento výchozí bod, jejich obchodní cíle a SLO řídily své volby služeb.

• Aplikační platforma: Jako aplikační platformu použijte službu Aplikace Azure Service. Společnost Contoso Fiber jako aplikační platformu zvolila službu Aplikace Azure Service z následujících důvodů:

  • Přirozený průběh: Společnost Contoso Fiber nasadila na svůj místní server soubor Spring Boot jar a chtěla minimalizovat množství změny architektury pro tento model nasazení. App Service poskytuje robustní podporu pro spouštění aplikací Spring Boot a pro Contoso Fiber bylo přirozené progrese, aby používala App Service. Azure Container Apps je také atraktivní alternativou pro tuto aplikaci. Další informace najdete v tématu Co je Azure Spring Apps? a Java v Azure Container Apps – přehled.
  • Vysoká smlouva SLA: Má vysokou smlouvu SLA, která splňuje požadavky pro produkční prostředí.
  • Nižší režijní náklady na správu: Jedná se o plně spravované řešení hostování.
  • Funkce kontejnerizace: App Service spolupracuje s privátními registry imagí kontejnerů, jako je Azure Container Registry. Společnost Contoso Fiber může tyto registry použít ke kontejnerizaci webové aplikace v budoucnu.
  • Automatické škálování: Webová aplikace může rychle vertikálně navýšit, snížit nebo snížit kapacitu na základě uživatelského provozu.

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

  • Ověřování a autorizace: Aplikace musí ověřovat a autorizovat zaměstnance call centra.
  • Škálovatelné: Škáluje se tak, aby podporovala větší scénáře.
  • Řízení identit uživatelů: Zaměstnanci call centra můžou používat své stávající podnikové identity.
  • Podpora autorizačního protokolu: Podporuje OAuth 2.0 pro spravované identity.

• Databáze: Použijte službu, která umožňuje zachovat stejný databázový stroj. Použijte rozhodovací strom úložiště dat. Společnost Contoso Fiber zvolila Azure Database for PostgreSQL a možnost flexibilního serveru z následujících důvodů:

  • Spolehlivost: Model nasazení flexibilního serveru podporuje zónově redundantní vysokou dostupnost napříč několika zónami dostupnosti. Tato konfigurace udržuje záložní pohotovostní server v jiné zóně dostupnosti ve stejné oblasti Azure. Konfigurace replikuje data synchronně na pohotovostní server.
  • Replikace mezi oblastmi: Má funkci repliky pro čtení, která umožňuje asynchronně replikovat data do databáze repliky jen pro čtení v jiné oblasti.
  • Výkon: Poskytuje předvídatelný výkon a inteligentní ladění pro zlepšení výkonu databáze pomocí skutečných dat o využití.
  • Nižší režijní náklady na správu: Jedná se o plně spravovanou službu Azure, která snižuje povinnosti správy.
  • Podpora migrace: Podporuje migraci databází z místních databází PostgreSQL s jedním serverem. Nástroj pro migraci můžou použít ke zjednodušení procesu migrace.
  • Konzistence s místními konfiguracemi: Podporuje různé komunitní verze PostgreSQL, včetně verze, kterou Contoso Fiber aktuálně používá.
  • Odolnost. Flexibilní nasazení serveru automaticky vytvoří zálohy serveru a uloží je pomocí zónově redundantního úložiště (ZRS) ve stejné oblasti. Svou databázi můžou obnovit k určitému bodu v čase během doby uchovávání záloh. Funkce zálohování a obnovení vytvoří lepší cíl bodu obnovení (přijatelné množství ztráty dat), než by společnost Contoso Fiber mohla vytvořit místně.

• Monitorování výkonu aplikací: Pomocí Application Insights můžete analyzovat telemetrii ve vaší aplikaci. Společnost Contoso Fiber se rozhodla používat Application Insights z následujících důvodů:

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

• Mezipaměť: Zvolte, jestli chcete přidat mezipaměť do architektury webové aplikace. Azure Cache for Redis je primární řešení mezipaměti Azure. Jedná se o spravované úložiště dat v paměti založené na softwaru Redis. Společnost Contoso Fiber přidala Azure Cache for Redis z následujících důvodů:

  • Rychlost a svazek: Má vysokou propustnost dat a nízkou latenci čtení pro běžně používaná a pomalá data.
  • Různorodá podpora: Jedná se o jednotné umístění mezipaměti, které můžou používat všechny instance webové aplikace.
  • Externí úložiště dat Místní aplikační servery prováděly místní ukládání do mezipaměti virtuálního počítače. Toto nastavení nenačítá data s vysokou četností a nemohla zneplatnit data.
  • Nesticky relace: Mezipaměť umožňuje webové aplikaci externalizovat stav relace a používat nesticky relace. Většina webových aplikací v Javě spuštěných místně používá ukládání do mezipaměti na straně klienta. Ukládání do mezipaměti na straně klienta se neškálí správně a zvyšuje nároky na paměť na hostiteli. Díky použití služby Azure Cache for Redis má Contoso Fiber plně spravovanou škálovatelnou službu mezipaměti, která zlepšuje škálovatelnost a výkon svých aplikací. Společnost Contoso Fiber používala architekturu abstrakce mezipaměti (Spring Cache) a k prohození poskytovatele mezipaměti potřebovala pouze minimální změny konfigurace. Povolila jim přejít od poskytovatele Ehcache na poskytovatele Redis.

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

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

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

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

• Správce tajných kódů: Pokud máte tajné kódy pro správu v Azure, použijte Azure Key Vault . Společnost Contoso Fiber používala službu Key Vault z následujících důvodů:

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

• Zabezpečení koncových bodů: Pomocí služby Azure Private Link můžete přistupovat k řešením typu platforma jako služba přes privátní koncový bod ve vaší virtuální síti. Provoz mezi vaší virtuální sítí a službou prochází přes páteřní síť Microsoftu. Společnost Contoso Fiber zvolila private Link z následujících důvodů:

  • Vylepšená komunikace zabezpečení: Umožňuje aplikacím privátní přístup ke službám na platformě Azure a snižuje síťové nároky úložišť dat, které pomáhají chránit před únikem dat.
  • Minimální úsilí: Privátní koncové body podporují platformu webové aplikace a databázovou platformu, které webová aplikace používá. Obě platformy zrcadlí stávající místní konfigurace pro minimální změnu.

• Zabezpečení sítě: Pomocí služby Azure Firewall můžete řídit příchozí a odchozí provoz na úrovni sítě. Pomocí služby Azure Bastion se bezpečně připojte k virtuálním počítačům bez vystavení portů RDP/SSH. Společnost Contoso Fiber přijala hvězdicovou síťovou topologii a chtěla do centra umístit sdílené služby zabezpečení sítě. Azure Firewall zlepšuje zabezpečení kontrolou veškerého odchozího provozu z paprsků, aby se zvýšilo zabezpečení sítě. Společnost Contoso Fiber potřebovala Azure Bastion pro zabezpečená nasazení z hostitele jump v podsíti DevOps.

Pokyny pro kód

Pokud chcete úspěšně přesunout webovou aplikaci do cloudu, musíte aktualizovat kód webové aplikace vzorem opakování, vzorem Jistič a vzorem návrhu doplňování mezipaměti.

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

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

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

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

3. Model doplňování mezipaměti: Model doplňování mezipaměti se přidává do mezipaměti a načítá z mezipaměti častěji než úložiště dat. Tento model implementujte u požadavků na databázi.

Implementace vzoru opakování

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

K implementaci vzoru Opakování v Javě použijte zjednodušenou knihovnu odolnosti proti chybám. Například referenční implementace přidá model Opakování dekódováním metody listServicePlans kontroleru plánu služby s poznámkami Retry. Kód opakuje volání seznamu plánů služeb z databáze, pokud se počáteční volání nezdaří. Referenční implementace konfiguruje zásady opakování, včetně maximálních pokusů, doby čekání a výjimek, které by se měly opakovat. Zásada opakování je nakonfigurovaná v application.propertiessouboru .

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Implementace systému jističe

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

K implementaci modelu Jistič použijte dokumentaci Spring Circuit Breaker a Resilience4j. Například referenční implementace implementuje model Jistič dekódováním metod atributem Circuit Breaker.

Implementace modelu doplňování mezipaměti

Přidejte do webové aplikace model doplňování mezipaměti, abyste zlepšili správu dat v paměti. Vzor přiřazuje aplikaci odpovědnost za zpracování požadavků na data a zajištění konzistence mezi mezipamětí a trvalým úložištěm, jako je databáze. Zkracuje dobu odezvy, vylepšuje propustnost a snižuje potřebu většího škálování. Snižuje také zatížení primárního úložiště dat, což zlepšuje spolehlivost a optimalizaci nákladů. Pokud chcete implementovat model doplňování mezipaměti, postupujte podle těchto doporučení:

• Nakonfigurujte aplikaci tak, aby používala mezipaměť. Pokud chcete povolit ukládání do mezipaměti, přidejte balíček spring-boot-starter-cache jako závislost do souboru pom.xml . Tento balíček poskytuje výchozí konfigurace pro mezipaměť Redis.

• Ukládání vysoce potřebných dat do mezipaměti U dat s vysokou potřebou použijte model doplňování mezipaměti, aby se zvýšila jeho efektivita. Azure Monitor slouží ke sledování procesoru, paměti a úložiště databáze. Tyto metriky vám pomůžou určit, jestli můžete po použití vzoru Doplňování mezipaměti použít menší skladovou položku databáze. Pokud chcete do kódu ukládat konkrétní data do mezipaměti, přidejte poznámku @Cacheable . Tato poznámka říká Springu, které metody by měly mít uložené výsledky v mezipaměti.

• Udržujte data mezipaměti aktuální. Naplánujte pravidelné aktualizace mezipaměti pro synchronizaci s nejnovějšími změnami databáze. Určete optimální frekvenci aktualizace na základě nestálosti dat a potřeb uživatelů. Tento postup zajišťuje, že aplikace používá model doplňování mezipaměti k zajištění rychlého přístupu i aktuálních informací. Výchozí nastavení mezipaměti nemusí vyhovovat vaší webové aplikaci. Tato nastavení můžete přizpůsobit v application.properties souboru nebo proměnných prostředí. Můžete například upravit spring.cache.redis.time-to-live hodnotu (vyjádřenou v milisekundách) a určit, jak dlouho mají data zůstat v mezipaměti před vyřazením.

• Zajistěte konzistenci dat. Implementujte mechanismy pro aktualizaci mezipaměti ihned po jakékoli operaci zápisu databáze. K zajištění soudržnosti mezipaměti použijte aktualizace řízené událostmi nebo vyhrazené třídy správy dat. Konzistentní synchronizace mezipaměti s úpravami databáze je ústředním principem doplňování mezipaměti.

Pokyny ke konfiguraci

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

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

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

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

  Úvodní sada Spring Boot pro Microsoft Entra ID zjednodušuje tento proces s využitím Spring Security a Spring Boot pro snadné nastavení. Nabízí různé toky ověřování, automatickou správu tokenů a přizpůsobitelné zásady autorizace spolu s možnostmi integrace s komponentami Spring Cloudu. To umožňuje jednoduchou integraci Microsoft Entra ID a OAuth 2.0 do aplikací Spring Boot bez ruční knihovny nebo konfigurace nastavení.

  Referenční implementace například používá platformu Microsoft Identity Platform (Microsoft Entra ID) jako zprostředkovatele identity pro webovou aplikaci. K přihlášení uživatele pomocí účtu Microsoft Entra používá autorizační kód OAuth 2.0. Následující fragment kódu XML definuje dvě požadované závislosti toku udělení autorizačního kódu OAuth 2.0. com.azure.spring: spring-cloud-azure-starter-active-directory Závislost umožňuje ověřování a autorizaci Microsoft Entra v aplikaci Spring Boot. org.springframework.boot: spring-boot-starter-oauth2-client Závislost podporuje ověřování a autorizaci OAuth 2.0 v aplikaci Spring Boot.

  <dependency>
      <groupid>com.azure.spring</groupid>
      <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
  </dependency>
  <dependency>
      <groupid>org.springframework.boot</groupid>
      <artifactid>spring-boot-starter-oauth2-client</artifactid>
  </dependency>
  

• Vytvořte registraci aplikace. ID Microsoft Entra vyžaduje registraci aplikace v primárním tenantovi. Registrace aplikace zajišťuje uživatelům, kteří získají přístup k webové aplikaci, identity v primárním tenantovi. Například referenční implementace používá Terraform k vytvoření registrace aplikace Microsoft Entra ID spolu s rolí správce účtů konkrétní aplikace.

  resource "azuread_application" "app_registration" {
    display_name     = "${azurecaf_name.app_service.result}-app"
    owners           = [data.azuread_client_config.current.object_id]
    sign_in_audience = "AzureADMyOrg"  # single tenant
  
    app_role {
      allowed_member_types = ["User"]
      description          = "Account Managers"
      display_name         = "Account Manager"
      enabled              = true
      id                   = random_uuid.account_manager_role_id.result
      value                = "AccountManager"
    }
  }
  

• Vynucujte autorizaci v aplikaci. Pomocí řízení přístupu na základě role (RBAC) přiřaďte k rolím aplikací nejnižší oprávnění. Definujte konkrétní role pro různé akce uživatelů, abyste se vyhnuli překrývání a zajistili srozumitelnost. Namapujte uživatele na příslušné role a ujistěte se, že mají přístup jenom k potřebným prostředkům a akcím. Nakonfigurujte Spring Security tak, aby používala úvodní sadu Spring Boot pro ID Microsoft Entra. Tato knihovna umožňuje integraci s ID Microsoft Entra a pomáhá zajistit, aby se uživatelé bezpečně ověřili. Konfigurace a povolení knihovny MSAL (Microsoft Authentication Library) poskytuje přístup k dalším funkcím zabezpečení. Mezi tyto funkce patří ukládání tokenů do mezipaměti a automatická aktualizace tokenů.

  Referenční implementace například vytvoří role aplikací, které odrážejí typy uživatelských rolí v systému správy účtů společnosti Contoso Fiber. Role se při autorizaci překládají na oprávnění. Mezi příklady rolí specifických pro aplikace v CAMS patří správce účtů, zástupce podpory úrovně 1 (L1) a zástupce služby Field Service. Role Správce účtů má oprávnění přidávat nové uživatele a zákazníky aplikací. Zástupce služby Field Service může vytvořit lístky podpory. Atribut PreAuthorize omezuje přístup ke konkrétním rolím.

      @GetMapping("/new")
      @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
      public String newAccount(Model model) {
          if (model.getAttribute("account") == null) {
              List<ServicePlan> servicePlans = accountService.findAllServicePlans();
              ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
              NewAccountRequest accountFormData = new NewAccountRequest();
              accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
              model.addAttribute("account", accountFormData);
              model.addAttribute("servicePlans", servicePlans);
          }
          model.addAttribute("servicePlans", accountService.findAllServicePlans());
          return "pages/account/new";
      }
      ...
  

  K integraci s ID Microsoft Entra používá referenční implementace tok udělení autorizačního kódu OAuth 2.0. Tento tok umožňuje uživateli přihlásit se pomocí účtu Microsoft. Následující fragment kódu ukazuje, jak nakonfigurovat SecurityFilterChain použití Microsoft Entra ID pro ověřování a autorizaci.

  @Configuration(proxyBeanMethods = false)
  @EnableWebSecurity
  @EnableMethodSecurity
  public class AadOAuth2LoginSecurityConfig {
      @Bean
      SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
          http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
              .and()
                  .authorizeHttpRequests()
              .requestMatchers(EndpointRequest.to("health")).permitAll()
              .anyRequest().authenticated()
              .and()
                  .logout(logout -> logout
                              .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                              .clearAuthentication(true)
                              .invalidateHttpSession(true));
          return http.build();
      }
  }
  ...
  

• Upřednostněte dočasný přístup k úložišti. Pomocí dočasných oprávnění můžete chránit před neoprávněným přístupem a porušením zabezpečení, jako jsou sdílené přístupové podpisy (SAS). SAS delegování uživatelů slouží k maximalizaci zabezpečení při udělování dočasného přístupu. Jedná se o jediný SAS, který používá přihlašovací údaje Microsoft Entra ID a nevyžaduje trvalý klíč účtu úložiště.

• Vynucujte autorizaci v Azure. Pomocí Azure RBAC přiřaďte identitám uživatelů nejnižší oprávnění. Azure RBAC určuje, k jakým identitám prostředků Azure mají přístup, co můžou s těmito prostředky dělat a k jakým oblastem mají přístup.

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

Implementace spravovaných identit

Spravované identity používejte pro všechny služby Azure, které podporují spravované identity. Spravovaná identita umožňuje prostředkům Azure (identitám úloh) ověřování a interakci s ostatními službami Azure bez správy přihlašovacích údajů. Hybridní a starší systémy můžou uchovávat místní řešení ověřování, aby se migrace zjednodušila, ale měla by co nejdříve přejít na spravované identity. Pokud chcete implementovat spravované identity, postupujte podle těchto doporučení:

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

• Nakonfigurujte nejnižší oprávnění. Azure RBAC použijte k udělení jenom oprávnění, která jsou pro operace důležitá, například akce CRUD v databázích nebo přístup k tajným kódům. Oprávnění identit úloh jsou trvalá, takže identitám úloh nemůžete poskytnout oprávnění za běhu ani krátkodobé oprávnění. Pokud Azure RBAC nepokrývá konkrétní scénář, doplňte Azure RBAC pomocí zásad přístupu na úrovni služeb Azure.

• Zabezpečte zbývající tajné kódy. Ukládejte všechny zbývající tajné kódy ve službě Azure Key Vault. Načtěte tajné kódy ze služby Key Vault při spuštění aplikace místo během každého požadavku HTTP. Přístup s vysokou frekvencí v rámci požadavků HTTP může překročit limity transakcí služby Key Vault. Uložte konfigurace aplikací v konfiguraci Aplikace Azure.

Nastavení správné velikosti prostředí

Používejte úrovně výkonu (SKU) služeb Azure, které splňují potřeby jednotlivých prostředí bez nadbytečného využití. Pokud chcete prostředí správně upravit, postupujte podle těchto doporučení:

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

• Optimalizace nákladů v produkčních prostředích Produkční prostředí potřebují skladové položky, které splňují smlouvy o úrovni služeb (SLA), funkce a škálování potřebné pro produkční prostředí. Nepřetržitě monitorujte využití prostředků a upravte skladové položky tak, aby odpovídaly skutečným požadavkům na výkon.

• Předprodukční prostředí pro optimalizaci nákladů Předprodukční prostředí by měla používat prostředky s nižšími náklady, zakázat nepotřebné služby a uplatňovat slevy, jako jsou ceny azure pro vývoj/testování. Ujistěte se, že předprodukční prostředí jsou dostatečně podobná produkčnímu prostředí , aby nedocházelo k rizikům. Tento zůstatek zajišťuje, že testování zůstane efektivní bez zbytečných nákladů.

• Definujte skladové položky pomocí infrastruktury jako kódu (IaC). Implementujte IaC, abyste dynamicky vybrali a nasadily správné skladové položky na základě prostředí. Tento přístup zvyšuje konzistenci a zjednodušuje správu.

Například referenční implementace má volitelný parametr, který nasazuje různé skladové položky. Parametr prostředí dává šabloně Terraformu pokyn, aby vybral vývojové skladové položky.

azd env set APP_ENVIRONMENT prod

Implementace automatického škálování

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

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

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

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

Automatizace nasazení prostředků

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

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

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

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

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

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

Konfigurace sledování

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

• Shromážděte telemetrii aplikací. Pomocí automatického vytváření v Aplikace Azure lication Insights můžete shromažďovat telemetrická data aplikací, jako je propustnost požadavků, průměrná doba trvání požadavků, chyby a monitorování závislostí beze změn kódu. Spring Boot registruje v Application Insights několik základních metrik, jako je java virtual machine (JVM), CPU, Tomcat a další. Application Insights automaticky shromažďuje z rozhraní protokolování, jako jsou Log4j a Logback. Referenční implementace například používá Application Insights povolenou prostřednictvím Terraformu jako součást konfigurace služby App Service app_settings . (viz následující kód).

  app_settings = {
      APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
      ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
      ...
  }
  

  Další informace naleznete v tématu:

  • Konfigurace služby Azure Monitor Application Insights pro Spring Boot
  • Azure Monitor Application Insights pro Javu
  • Povolení OpenTelemetry služby Azure Monitor pro aplikace v Javě
  • Použití služby Azure Monitor Application Insights se spring bootem

• Vytvořte vlastní metriky aplikací. Implementujte instrumentaci založenou na kódu pro zachycení vlastní telemetrie aplikací přidáním sady Application Insights SDK a použitím jejího rozhraní API.

• Monitorujte platformu. Povolte diagnostiku pro všechny podporované služby a odešlete diagnostiku do stejného cíle jako protokoly aplikací pro korelaci. Služby Azure vytvářejí protokoly platformy automaticky, ale ukládají se jenom při povolení diagnostiky. Povolte nastavení diagnostiky pro každou službu, která podporuje diagnostiku. Referenční implementace používá Terraform k povolení diagnostiky Azure pro všechny podporované služby. Následující kód Terraformu nakonfiguruje nastavení diagnostiky pro službu App Service.

  # Configure Diagnostic Settings for App Service
  resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
    name                           = "app-service-diagnostic-settings"
    target_resource_id             = azurerm_linux_web_app.application.id
    log_analytics_workspace_id     = var.log_analytics_workspace_id
    #log_analytics_destination_type = "AzureDiagnostics"
  
    enabled_log {
      category_group = "allLogs"
  
    }
  
    metric {
      category = "AllMetrics"
      enabled  = true
    }
  }
  

Nasazení referenční implementace

Referenční implementace provede vývojáře simulovanou migrací z místní aplikace Java do Azure a zvýrazní potřebné změny během počáteční fáze přijetí. Tento příklad používá aplikaci webové aplikace CAMS (Customer Account Management System) pro fiktivní společnost Contoso Fiber. Contoso Fiber pro svou webovou aplikaci nastavil následující cíle:

• Implementace změn kódu s nízkými náklady a vysokou hodnotou
• Dosažení cíle úrovně služeb (SLO) 99,9 %
• Přijetí postupů DevOps
• Vytváření prostředí optimalizovaných pro náklady
• Zvýšení spolehlivosti a zabezpečení

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

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