Condividi tramite

Modello di app Web affidabile per Java

Questo articolo fornisce indicazioni per implementare il modello di app Web Reliable. Questo modello descrive come riformare le app Web per la migrazione cloud. Fornisce indicazioni sull'architettura, il codice e la configurazione prescrittive che si allineano ai principi di Azure Well-Architected Framework.

Perché usare il modello Reliable Web App per Java?

Il modello Reliable Web App è un set di principi e tecniche di implementazione che definiscono come riformare le app Web durante la migrazione al cloud. Enfatizza gli aggiornamenti minimi del codice per garantire il successo nel cloud. Queste linee guida usano un'implementazione di riferimento come esempio coerente in tutto. Segue il percorso di riplatforming dell'azienda fittizia Contoso Fiber per fornire il contesto aziendale per la propria migrazione. Prima che Contoso Fiber implementi il modello Reliable Web App per Java, gestisce un sistema di gestione degli account cliente (CAMS) monolitico e locale compilato con il framework Spring Boot.

Suggerimento

Logo di GitHub. L'implementazione di riferimento (esempio) del modello Reliable Web App rappresenta lo stato finale di un'implementazione completata. Questa app Web di livello di produzione include tutti gli aggiornamenti di codice, architettura e configurazione descritti in questo articolo. Distribuire e usare l'implementazione di riferimento per guidare l'implementazione personalizzata del modello di app Web Reliable.

Come implementare il modello di app Web Reliable

Trovare le linee guida specifiche necessarie nelle sezioni seguenti di questo articolo:

  • Contesto aziendale: allineare queste linee guida al contesto aziendale e imparare a definire obiettivi immediati e a lungo termine che determinano decisioni di riformatura.

  • Indicazioni sull'architettura: selezionare i servizi cloud corretti e progettare un'architettura che soddisfi i requisiti aziendali.

  • Indicazioni sul codice: implementare i modelli di progettazione di ripetizione, interruttore e Cache-Aside per migliorare l'affidabilità e l'efficienza delle prestazioni dell'app Web nel cloud.

  • Linee guida per la configurazione: configurare l'autenticazione e l'autorizzazione, le identità gestite, gli ambienti con diritti, l'infrastruttura come codice (IaC) e il monitoraggio.

Contesto aziendale

Il primo passaggio per ripiattaformare un'app Web consiste nel definire gli obiettivi aziendali. Impostare obiettivi immediati, ad esempio obiettivi a livello di servizio e obiettivi di ottimizzazione dei costi, insieme agli obiettivi futuri per l'applicazione Web. Questi obiettivi influenzano la scelta dei servizi cloud e l'architettura dell'applicazione nel cloud. Definire uno SLO di destinazione per l'applicazione web, ad esempio 99,9% di disponibilità. Calcolare il contratto di servizio composito per tutti i servizi che influiscono sulla disponibilità dell'app Web.

Contoso Fiber vuole espandere l'app Web CAMS locale per raggiungere altre aree. Per soddisfare la maggiore domanda sull'app Web, l'azienda stabilisce gli obiettivi seguenti:

  • Applicare modifiche al codice a basso costo e alto valore.
  • Raggiungere un SLO di 99.9%.
  • Adottare le procedure DevOps.
  • Creare ambienti ottimizzati per i costi.
  • Migliorare l'affidabilità e la sicurezza.

Contoso Fiber determina che l'infrastruttura locale non è una soluzione conveniente per il ridimensionamento dell'applicazione. L'azienda decide che la migrazione dell'applicazione Web CAMS ad Azure è il modo più conveniente per raggiungere gli obiettivi immediati e futuri.

Linee guida per l'architettura

Il modello Reliable Web App include alcuni elementi architetturali essenziali. È necessario Domain Name System (DNS) per gestire la risoluzione degli endpoint, un web application firewall per bloccare il traffico HTTP dannoso e un servizio di bilanciamento del carico per instradare e proteggere le richieste degli utenti in ingresso. La piattaforma dell'applicazione ospita il codice dell'applicazione Web e invoca i servizi back-end tramite endpoint privati nella sua rete virtuale. Uno strumento di monitoraggio delle prestazioni dell'applicazione acquisisce metriche e log per comprendere l'app Web.

Diagramma che mostra gli elementi architetturali essenziali del modello Reliable Web App.

Progettare l'architettura

Progettare l'infrastruttura per supportare le metriche di ripristino, ad esempio l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). Il RTO influisce sulla disponibilità e deve supportare il tuo SLO. Determinare un RPO e configurare la ridondanza dei dati per soddisfare l'RPO.

Selezionare i servizi di Azure corretti

Quando si sposta un'app web nel cloud, scegliere servizi di Azure che soddisfano i requisiti aziendali e si allineano alle funzionalità dell'app web locale. Questo allineamento aiuta a ridurre al minimo lo sforzo di ripiattaformazione. Ad esempio, usare i servizi che consentono di mantenere lo stesso motore di database e supportare il middleware e i framework esistenti.

Prima della migrazione, l'app Web CAMS di Contoso Fiber è un'applicazione Java monolitica locale. Si tratta di un'app Spring Boot con un database PostgreSQL. L'app Web è un'app di supporto line-of-business (LOB) per i dipendenti. Lo usano per gestire i casi di assistenza clienti. L'app presenta problemi comuni con la scalabilità e la distribuzione delle funzionalità. Questo punto di partenza, insieme agli obiettivi aziendali e ai contratti di servizio, influenza le proprie scelte di servizio.

L'elenco seguente fornisce indicazioni per selezionare i servizi di Azure corretti per l'app Web e descrive il motivo per cui Contoso Fiber seleziona servizi specifici:

  • Piattaforma dell'applicazione: Usare Servizio app di Azure come piattaforma dell'applicazione. Contoso Fiber usa il servizio app per i motivi seguenti:

    • Progressione naturale: Contoso Fiber distribuisce un file JAR Spring Boot nel server locale e vuole ridurre al minimo la quantità di riprogettazione per tale modello di distribuzione. Il servizio app offre un supporto affidabile per l'esecuzione di app Spring Boot, che lo rende un'opzione adatta. Azure Container Apps è anche un'opzione adatta per questa applicazione. Per ulteriori informazioni, consultare la Panoramica di App di contenitori e la Panoramica di Java su App di contenitori.

    • SLA elevato: App Service offre un SLA elevato che soddisfa i requisiti di produzione.

    • Riduzione del sovraccarico di gestione: Il servizio app è una soluzione di hosting gestita.

    • Funzionalità di containerizzazione: Il servizio app si integra con registri di immagini del contenitore privato, ad esempio Registro Azure Container. Contoso Fiber può usare questi registri per inserire in contenitori l'app Web in futuro.

    • Scalabilità automatica: L'app Web può aumentare rapidamente le prestazioni, ridurre le prestazioni, aumentare le prestazioni e aumentare il numero di istanze in base al traffico utente.

  • Gestione delle identità: Usare Microsoft Entra ID come soluzione di gestione delle identità e degli accessi. Contoso Fiber usa l'ID Microsoft Entra per i motivi seguenti:

    • Autenticazione e autorizzazione: L'applicazione deve autenticare e autorizzare i dipendenti del call center.

    • Scalabilità: Microsoft Entra ID viene ridimensionato per supportare scenari più grandi.

    • Controllo identità utente: I dipendenti del call center possono usare le identità aziendali esistenti.

    • Supporto del protocollo di autorizzazione: Microsoft Entra ID supporta OAuth 2.0 per le identità gestite.

  • Banca dati: Usare un servizio che consente di mantenere lo stesso motore di database. Usare l'albero delle decisioni dell'archivio dati per guidare la selezione. Contoso Fiber usa il modello di distribuzione server flessibile di Database di Azure per PostgreSQL per i motivi seguenti:

    • Affidabilità: Il modello di distribuzione server flessibile supporta la disponibilità elevata con ridondanza della zona in più zone di disponibilità. Questa configurazione gestisce un server warm standby in una zona di disponibilità diversa all'interno della stessa area di Azure. La configurazione replica i dati in modo sincrono nel server di standby.

    • Replica tra aree: Database di Azure per PostgreSQL offre una funzionalità di replica in lettura per replicare in modo asincrono i dati in un database di replica di sola lettura in un'altra area.

    • Prestazione: Database di Azure per PostgreSQL offre prestazioni prevedibili e un'ottimizzazione intelligente che migliora le prestazioni del database usando dati di utilizzo reali.

    • Riduzione del sovraccarico di gestione: Questo servizio di Azure gestito riduce gli obblighi di gestione.

    • Supporto per la migrazione: Supporta la migrazione del database da database PostgreSQL a server singolo locale. Contoso Fiber può usare lo strumento di migrazione per semplificare il processo di migrazione.

    • Coerenza con le configurazioni locali: Supporta diverse versioni della community di PostgreSQL, inclusa la versione attualmente usata da Contoso Fiber.

    • Resilienza: La distribuzione flessibile del server crea automaticamente backup del server e li archivia nell'archiviazione con ridondanza della zona (ZRS) all'interno della stessa area. Contoso Fiber può ripristinare il database in qualsiasi momento entro il periodo di conservazione dei backup. La funzionalità di backup e ripristino crea un RPO migliore rispetto agli ambienti locali.

  • Monitoraggio delle prestazioni dell'applicazione: Usare Application Insights per analizzare i dati di telemetria nell'applicazione. Contoso Fiber usa Application Insights per i motivi seguenti:

    • Integrazione con Monitoraggio di Azure: Offre la migliore integrazione con Monitoraggio di Azure.

    • Rilevamento anomalie: Rileva automaticamente le anomalie delle prestazioni.

    • Risoluzione dei problemi: Consente di diagnosticare i problemi nell'app in esecuzione.

    • Monitoraggio: Raccoglie i dati di utilizzo per l'app e tiene traccia degli eventi personalizzati.

    • Distanza di visibilità: La soluzione locale non ha una soluzione di monitoraggio delle prestazioni dell'applicazione. Application Insights offre un'integrazione semplice con la piattaforma e il codice dell'applicazione.

  • Cache: Scegliere se aggiungere una cache all'architettura dell'app Web. Redis gestito di Azure è la soluzione principale di Cache di Azure. Si tratta di un archivio dati gestito in memoria basato sul software Redis. Contoso Fiber aggiunge Azure Managed Redis per i motivi seguenti:

    • Velocità e volume: Offre velocità effettiva elevata dei dati e letture a bassa latenza per i dati a modifica lenta e a cui si accede di frequente.

    • Supporto diversificato: Si tratta di un percorso unificato della cache che tutte le istanze dell'app Web possono usare.

    • Archivio dati esterno: I server applicazioni locali usano la memorizzazione nella cache locale della macchina virtuale. Questa configurazione non esegue l'offload dei dati a cui si accede di frequente e non può invalidare i dati non aggiornati.

    • Sessioni senza persistenza: La cache consente all'app Web di esternalizzare lo stato della sessione e di usare sessioni senza persistenza. La maggior parte delle app Web Java eseguite in locale si basa sulla memorizzazione nella cache sul lato client in memoria. Questo approccio non scala bene e aumenta l'occupazione di memoria sull'host. Azure Managed Redis offre un servizio cache gestito e scalabile per migliorare la scalabilità e le prestazioni delle applicazioni. Contoso Fiber usa Spring Cache come framework di astrazione della cache e richiede solo modifiche minime alla configurazione per passare da un provider Ehcache al provider Redis.

  • Bilanciamento del carico: Le applicazioni Web che usano soluzioni PaaS (Platform as a Service) devono usare Frontdoor di Azure, gateway applicazione di Azure o entrambi, a seconda dell'architettura e dei requisiti dell'app Web. Usare l'albero delle decisioni del servizio di bilanciamento del carico per selezionare il bilanciamento del carico corretto. Contoso Fiber necessita di un servizio di bilanciamento del carico di livello 7 in grado di instradare il traffico tra più aree e un'app Web multiregione per soddisfare lo SLO di 99.9%. L'azienda usa Frontdoor di Azure per i motivi seguenti:

    • Bilanciamento del carico globale: Questo servizio di bilanciamento del carico di livello 7 può instradare il traffico tra più aree.

    • Web application firewall: Si integra in modo nativo con Web application firewall di Azure.

    • Flessibilità di routing: Consente al team dell'applicazione di configurare l'ingresso per supportare le modifiche future dell'applicazione.

    • Accelerazione del traffico: Usa il routing anycast per raggiungere il punto di presenza di Azure più vicino e trovare la route più veloce per l'app Web.

    • Domini personalizzati: Supporta nomi di dominio personalizzati con convalida del dominio flessibile.

    • Sondu di salute: L'applicazione richiede il monitoraggio intelligente delle sonde di salute. Azure Front Door utilizza le risposte del probe per determinare l'origine migliore per l'instradamento delle richieste dei client.

    • Supporto per il monitoraggio: Frontdoor di Azure supporta i report predefiniti con un dashboard integrato per frontdoor di Azure e i modelli di sicurezza. Fornisce avvisi che si integrano con Monitoraggio di Azure. Azure Front Door consente all'applicazione di loggare ogni richiesta e i tentativi falliti di verifica dell'integrità.

    • Protezione DDoS (Distributed Denial of Service): Ha una protezione DDoS predefinita al livello 3 e al livello 4.

    • Rete per la distribuzione di contenuti: Posiziona Contoso Fiber per usare una rete per la distribuzione di contenuti. La rete per la distribuzione di contenuti fornisce l'accelerazione del sito.

  • Web application firewall: Usare Web application firewall di Azure per fornire protezione centralizzata da exploit Web e vulnerabilità comuni. Contoso Fiber usa Web application firewall di Azure per i motivi seguenti:

    • Protezione globale: Offre una migliore protezione globale delle app Web mantenendo al contempo le prestazioni.

    • Protezione botnet: Il team può monitorare e configurare le impostazioni per risolvere i problemi di sicurezza correlati alle botnet.

    • Parità con l'ambiente locale: La soluzione locale viene eseguita dietro un web application firewall gestito dall'IT.

    • Facilità d'uso: Web application firewall di Azure si integra con Frontdoor di Azure.

  • Gestione segreti: Usare Azure Key Vault se si hanno segreti da gestire in Azure. Contoso Fiber usa Key Vault per i motivi seguenti:

    • Crittografia: Supporta la crittografia dei dati a riposo e in movimento.

    • Supporto delle identità gestite: I servizi dell'applicazione possono usare le identità gestite per accedere all'archivio segreto.

    • Monitoraggio e registrazione: Key Vault facilita il controllo dell'accesso e genera avvisi quando cambiano i segreti archiviati.

    • Integrazione: Key Vault offre l'integrazione nativa con l'archivio di configurazione di Azure (Configurazione app di Azure) e la piattaforma di hosting Web (Servizio app).

  • Sicurezza degli endpoint: Usare collegamento privato di Azure per accedere alle soluzioni PaaS tramite un endpoint privato nella rete virtuale. Il traffico tra la rete virtuale e il servizio passa attraverso la rete backbone Microsoft. Contoso Fiber usa il collegamento privato per i motivi seguenti:

    • Comunicazione con sicurezza avanzata: Consente all'applicazione di accedere privatamente ai servizi nella piattaforma Azure e riduce il footprint di rete degli archivi dati per proteggersi dalla perdita di dati.

    • Sforzo minimo: Gli endpoint privati supportano la piattaforma dell'app Web e la piattaforma di database usata dall'app Web. Entrambe le piattaforme rispecchiano le configurazioni locali esistenti, quindi è necessaria una modifica minima.

  • Sicurezza di rete: Usare Firewall di Azure per controllare il traffico in ingresso e in uscita a livello di rete. Usare Azure Bastion per connettersi alle macchine virtuali con sicurezza avanzata, senza esporre porte Remote Desktop Protocol/Secure Shell (RDP/SSH). Contoso Fiber adotta una topologia di rete hub-spoke e inserisce i servizi di sicurezza di rete condivisi nell'hub. Firewall di Azure esamina il traffico in uscita dagli spoke per migliorare la sicurezza di rete. L'azienda usa Azure Bastion per distribuzioni di sicurezza avanzata da un jump host nella subnet DevOps.

Linee guida per il codice

Per spostare correttamente un'app Web nel cloud, è necessario aggiornare il codice dell'app Web usando i modelli Retry, Circuit Breaker e Cache-Aside.

Diagramma che mostra i ruoli dei modelli di progettazione nel modello Reliable Web App.

I modelli di progettazione seguenti offrono vantaggi dei carichi di lavoro che si collegano a uno o più pilastri del Framework Well-Architected.

  1. Il modello Di ripetizione dei tentativi gestisce gli errori temporanei ritentando le operazioni che potrebbero non riuscire in modo intermittente. Implementare questo modello in tutte le chiamate in uscita ad altri servizi di Azure.

  2. Il modello interruttore impedisce a un'applicazione di ripetere le operazioni che non sono temporanee. Implementare questo modello in tutte le chiamate in uscita ad altri servizi di Azure.

  3. Il modello Cache-Aside carica i dati su richiesta in una cache da un archivio dati. Implementare questo modello per le richieste al database.

Schema progettuale Affidabilità (RE) Sicurezza (SE) Ottimizzazione costi (CO) Eccellenza operativa (OE) Efficienza delle prestazioni (PE) Supporto dei principi WAF
modello di tentativo ripetuto ✔ RE:07
Modello Circuit Breaker ✔ ✔ RE:03
RE:07
PE:07
PE:11
modelloCache-Aside ✔ ✔ RE:05
PE:08
PE:12

Implementare lo schema di ripetizione dei tentativi

Aggiungi il modello di retry al codice dell'applicazione per risolvere le interruzioni temporanee del servizio. Queste interruzioni sono denominate errori temporanei. Gli errori temporanei si risolvono in genere entro pochi secondi. È possibile usare il modello Di ripetizione dei tentativi per inviare di nuovo richieste non riuscite. Consente inoltre di configurare il ritardo tra i tentativi e il numero di tentativi da fare prima di segnalare un errore.

Usare Resilience4j, una libreria leggera di tolleranza di errore, per implementare il modello Di ripetizione dei tentativi in Java. Per aggiungere il modello Retry, l'implementazione di riferimento decora il metodo del controller del piano servizio con Retry annotations. Il codice ritenta la chiamata a un elenco di piani di servizio dal database se la chiamata iniziale ha esito negativo. La politica di ripetizione dei tentativi per l'implementazione di riferimento include il numero massimo di tentativi, la durata dell'attesa e le eccezioni da ritentare. Configurare i criteri di ripetizione dei tentativi nel application.properties file.

    @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";
    }

Implementare il modello interruttore

Usare il Circuit Breaker per gestire le interruzioni del servizio che non sono guasti transitori. Il modello interruttore impedisce a un'applicazione di tentare continuamente di accedere a un servizio non rispondente. Rilascia l'applicazione e consente di evitare di sprecare cicli di unità di elaborazione centrale (CPU) in modo che l'applicazione mantenga l'integrità delle prestazioni per gli utenti.

Usare Spring Cloud Circuit Breaker e Resilience4j per implementare il modello circuit breaker. L'implementazione di riferimento applica il pattern Circuit Breaker decorando i metodi con l'attributo Circuit Breaker.

Implementare il modello di Cache-Aside

Aggiungere il modello diCache-Aside all'app Web per migliorare la gestione dei dati in memoria. Il modello assegna all'applicazione la responsabilità di gestire le richieste di dati e garantire la coerenza tra la cache e l'archiviazione permanente, ad esempio un database. Riduce i tempi di risposta, migliora la velocità effettiva e riduce la necessità di aumentare la scalabilità. Riduce anche il carico nell'archivio dati primario, migliorando l'affidabilità e l'ottimizzazione dei costi. Per implementare il modello di Cache-Aside, seguire queste indicazioni:

  • Configurare l'applicazione per l'uso di una cache. Per abilitare la memorizzazione nella cache, aggiungere il spring-boot-starter-cache pacchetto come dipendenza nel pom.xml file. Questo pacchetto fornisce configurazioni predefinite per la cache Redis.

  • Memorizzare nella cache i dati con esigenze elevate. Applicare il modello di Cache-Aside sui dati di elevata necessità per migliorarne l'efficacia. Usare Monitoraggio di Azure per tenere traccia della CPU, della memoria e dell'archiviazione del database. Queste metriche consentono di determinare se è possibile usare uno SKU di database più piccolo dopo aver applicato il modello di Cache-Aside. Per memorizzare nella cache dati specifici nel codice, aggiungere l'annotazione @Cacheable . Questa annotazione specifica a Spring quali metodi devono avere i risultati memorizzati nella cache.

  • Mantenere aggiornati i dati della cache. Pianificare gli aggiornamenti regolari della cache per la sincronizzazione con le modifiche più recenti del database. Usare la volatilità dei dati e le esigenze degli utenti per determinare la frequenza di aggiornamento ottimale. Questa procedura garantisce che l'applicazione usi il modello di Cache-Aside per fornire accesso rapido e informazioni correnti. Le impostazioni predefinite della cache potrebbero non essere adatte all'applicazione Web. È possibile personalizzare queste impostazioni nel application.properties file o nelle variabili di ambiente. Ad esempio, è possibile modificare il spring.cache.redis.time-to-live valore (espresso in millisecondi) per controllare per quanto tempo i dati devono rimanere nella cache prima della rimozione.

  • Garantire la coerenza dei dati. Implementare meccanismi per aggiornare la cache immediatamente dopo le operazioni di scrittura del database. Usare aggiornamenti basati su eventi o classi di gestione dei dati dedicate per garantire la coerenza della cache. La sincronizzazione coerente della cache con le modifiche del database è fondamentale per il modello di Cache-Aside.

Linee guida per la configurazione

Le sezioni seguenti forniscono indicazioni su come implementare gli aggiornamenti della configurazione. Ogni sezione è allineata a uno o più pilastri del framework di Well-Architected.

Configurazione Affidabilità (RE) Sicurezza (SE) Ottimizzazione costi (CO) Eccellenza operativa (OE) Efficienza delle prestazioni (PE) Supporto dei principi WAF
Configurare l'autenticazione e l'autorizzazione degli utenti ✔ ✔ SE:05
OE:10
Implementare le identità gestite ✔ ✔ SE:05
OE:10
Ottimizzare gli ambienti ✔ CO:05
CO:06
Implementare la scalabilità automatica ✔ ✔ ✔ RE:06
CO:12
PE:05
Automatizzare la distribuzione delle risorse ✔ OE:05
Implementare il monitoraggio ✔ ✔ ✔ OE:07
PE:04

Configurare l'autenticazione e l'autorizzazione degli utenti

Quando si esegue la migrazione di applicazioni Web ad Azure, configurare i meccanismi di autenticazione e autorizzazione degli utenti. Seguire queste raccomandazioni:

  • Usare una piattaforma di gestione delle identità. Usare Microsoft Identity Platform per gli sviluppatori perconfigurare l'autenticazione dell'app Web. Questa piattaforma supporta applicazioni che usano una singola directory di Microsoft Entra, più directory di Microsoft Entra di organizzazioni diverse e identità Microsoft o account di social networking.

    [Spring Boot Starter per Microsoft Entra ID](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide usa Spring Security e Spring Boot per garantire una configurazione e un'integrazione semplici. Offre vari flussi di autenticazione, gestione automatica dei token, criteri di autorizzazione personalizzabili e funzionalità di integrazione con i componenti spring cloud. Questo strumento consente un'integrazione semplice di Microsoft Entra ID e OAuth 2.0 nelle applicazioni Spring Boot senza configurazione manuale della libreria o delle impostazioni.

    L'implementazione di riferimento usa Microsoft Identity Platform (MICROSOFT Entra ID) come provider di identità per l'app Web. Usa la concessione del codice di autorizzazione OAuth 2.0 per accedere a un utente con un account Microsoft Entra. Il frammento XML seguente definisce le due dipendenze necessarie del flusso di concessione del codice di autorizzazione OAuth 2.0. La dipendenza com.azure.spring: spring-cloud-azure-starter-active-directory abilita l'autenticazione e l'autorizzazione di Microsoft Entra in un'applicazione Spring Boot. La dipendenza org.springframework.boot: spring-boot-starter-oauth2-client abilita l'autenticazione e l'autorizzazione di OAuth 2.0 in un'applicazione 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>

  • Creare una registrazione dell'applicazione. Microsoft Entra ID richiede una registrazione dell'applicazione nel tenant primario. La registrazione dell'applicazione garantisce che gli utenti che ottengono l'accesso all'app Web abbiano identità nel tenant primario. L'implementazione di riferimento usa Terraform per creare una registrazione dell'app Microsoft Entra ID insieme a un ruolo di Account Manager specifico dell'app:

    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"
  }
}

  • Far rispettare l'autorizzazione nell'applicazione. Usare il controllo degli accessi in base al ruolo per assegnare privilegi minimi ai ruoli dell'applicazione. Definire ruoli specifici per azioni utente diverse per evitare sovrapposizioni e garantire chiarezza. Mappare gli utenti ai ruoli appropriati e assicurarsi che abbiano accesso solo alle risorse e azioni necessarie. Configurare Spring Security per l'uso di Spring Boot Starter per Microsoft Entra ID. Questa libreria abilita l'integrazione con Microsoft Entra ID e garantisce che gli utenti siano autenticati in modo sicuro. Configurare e abilitare Microsoft Authentication Library (MSAL) per ottenere l'accesso a più funzionalità di sicurezza. Queste funzionalità includono la memorizzazione nella cache dei token e l'aggiornamento automatico dei token.

    L'implementazione di riferimento crea ruoli dell'app che riflettono i tipi di ruoli utente nel sistema di gestione degli account di Contoso Fiber. I ruoli si trasformano in permessi durante il processo di autorizzazione. Esempi di ruoli specifici dell'app in CAMS includono Account Manager, Il rappresentante del supporto di Livello 1 (L1) e Il rappresentante del servizio sul campo. Il ruolo Account Manager ha le autorizzazioni per aggiungere nuovi utenti e clienti di app. Un rappresentante del servizio sul campo può creare ticket di supporto. L'attributo PreAuthorize limita l'accesso a ruoli specifici.

        @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";
    }
    ...

    Per l'integrazione con Microsoft Entra ID, l'implementazione di riferimento usa il flusso di concessione del codice di autorizzazione OAuth 2.0 . Questo flusso consente a un utente di accedere usando un account Microsoft. Il seguente frammento di codice mostra come configurare il SecurityFilterChain per utilizzare Microsoft Entra ID per l'autenticazione e l'autorizzazione.

    @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();
    }
}
...

  • Preferisce l'accesso temporaneo all'archiviazione. Usare le autorizzazioni temporanee per proteggersi da accessi non autorizzati e violazioni. Ad esempio, è possibile usare firme di accesso condiviso (SAS) per limitare l'accesso a un periodo di tempo. Usare SAS di delega utente per ottimizzare la sicurezza quando si concede l'accesso temporaneo. Si tratta dell'unica firma di accesso condiviso che usa le credenziali di Microsoft Entra ID e non richiede una chiave di accesso permanente per l'account di archiviazione.

  • Applicare l'autorizzazione in Azure. Usa RBAC di Azure per assegnare privilegi minimi alle identità utente. Il controllo degli accessi in base al ruolo di Azure (Azure RBAC) definisce le risorse di Azure a cui le identità possono accedere, le operazioni che possono eseguire con tali risorse e le aree di accesso.

  • Evitare autorizzazioni con privilegi elevati permanenti. Usare Microsoft Entra Privileged Identity Management (PIM) per concedere l'accesso JIT (Just-In-Time) per le operazioni con privilegi. Ad esempio, gli sviluppatori hanno spesso bisogno di accesso a livello di amministratore per creare ed eliminare database, modificare gli schemi di tabella e modificare le autorizzazioni utente. Quando si usa l'accesso JIT, le identità utente ricevono autorizzazioni temporanee per eseguire attività con privilegi.

Implementare le identità gestite

Usare le identità gestite per tutti i servizi di Azure che li supportano. Un'identità gestita consente alle risorse di Azure, in particolare alle identità del carico di lavoro, di eseguire l'autenticazione e interagire con altri servizi di Azure senza richiedere la gestione delle credenziali. Per semplificare la migrazione, è possibile continuare a usare soluzioni di autenticazione locali per sistemi ibridi e legacy, ma è consigliabile eseguirne la transizione alle identità gestite il prima possibile. Per implementare le identità gestite, seguire queste indicazioni:

  • Selezionare il tipo corretto di identità gestita. Preferisce le identità gestite assegnate dall'utente quando si hanno due o più risorse di Azure che necessitano dello stesso set di autorizzazioni. Questo approccio è più efficiente rispetto alla creazione di identità gestite assegnate dal sistema per ognuna di queste risorse e l'assegnazione delle stesse autorizzazioni a tutte. In caso contrario, usare le identità gestite assegnate dal sistema.

  • Configurare i privilegi minimi. Usare Azure RBAC per concedere solo le autorizzazioni critiche per le operazioni, come le azioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) nei database o per accedere ai segreti. Le autorizzazioni di identità del carico di lavoro sono persistenti, quindi non è possibile fornire autorizzazioni JIT o a breve termine per le identità del carico di lavoro. Se il controllo degli accessi in base al ruolo di Azure non copre uno scenario specifico, integra il controllo degli accessi in base al ruolo di Azure con i criteri di accesso a livello di servizio di Azure.

  • Garantire la sicurezza per i segreti rimanenti. Archiviare tutti i segreti rimanenti in Key Vault. Caricare i segreti da Key Vault all'avvio dell'applicazione anziché durante ogni richiesta HTTP. L'accesso ad alta frequenza all'interno delle richieste HTTP può superare i limiti delle transazioni di Key Vault. Archiviare le configurazioni dell'applicazione in Configurazione app.

Ottimizzare gli ambienti

Usare i livelli di prestazioni (SKU) dei servizi di Azure che soddisfano le esigenze di ogni ambiente senza superarli. Per ottimizzare i vostri ambienti, eseguire le azioni seguenti:

  • Stimare i costi. Usare il calcolatore prezzi di Azure per stimare il costo di ogni ambiente.

  • Ottimizzare gli ambienti di produzione. Gli ambienti di produzione necessitano di SKU che soddisfano il contratto di servizio, le funzionalità e la scalabilità necessari per la produzione. Monitorare continuamente l'utilizzo delle risorse e regolare gli SKU per allinearsi alle esigenze di prestazioni effettive.

  • Ottimizzare gli ambienti di preproduzione.Gli ambienti di preproduzione devono usare risorse a basso costo e sfruttare gli sconti, ad esempio il piano di Azure per i prezzi di sviluppo/test. In questi ambienti disabilitare i servizi non necessari. Assicurarsi anche che gli ambienti di preproduzione siano sufficientemente simili agli ambienti di produzione per evitare di introdurre rischi. Mantenere questo equilibrio per garantire che i test rimangano efficaci senza incorrere in costi non necessari.

  • Usare IaC per definire gli SKU. Implementare IaC per selezionare e distribuire dinamicamente gli SKU corretti in base all'ambiente. Questo approccio migliora la coerenza e semplifica la gestione.

Ad esempio, l'implementazione di riferimento ha un parametro facoltativo che specifica lo SKU da distribuire. Un parametro di ambiente specifica che il modello Terraform deve distribuire SKU di sviluppo:

azd env set APP_ENVIRONMENT prod

Implementare la scalabilità automatica

La scalabilità automatica consente di garantire che un'app Web rimanga resiliente, reattiva e in grado di gestire in modo efficiente i carichi di lavoro dinamici. Per implementare la scalabilità automatica, seguire queste indicazioni:

  • Automatizzare la scalabilità orizzontale. Usare la scalabilità automatica di Azure per automatizzare la scalabilità orizzontale negli ambienti di produzione. Configurare le regole di scalabilità automatica per effettuare lo scaling in base alle metriche delle prestazioni chiave, in modo che l'applicazione possa gestire i carichi variabili.

  • Perfezionare i trigger di ridimensionamento. Usare l'utilizzo della CPU come trigger di ridimensionamento iniziale se non si ha familiarità con i requisiti di ridimensionamento dell'applicazione. Perfezionare i trigger di ridimensionamento per includere altre metriche, ad esempio RAM, velocità effettiva di rete e input/output del disco (I/O). L'obiettivo è corrispondere al comportamento dell'applicazione Web per ottenere prestazioni migliori.

  • Fornire un buffer di scalabilità orizzontale. Impostare le soglie di ridimensionamento per avviare il ridimensionamento prima che venga raggiunta la capacità massima. Ad esempio, configurare il ridimensionamento in modo che si verifichi a 85% utilizzo della CPU anziché attendere fino a raggiungere 100%. Questo approccio proattivo consente di mantenere le prestazioni ed evitare potenziali colli di bottiglia.

Automatizzare la distribuzione delle risorse

Usare l'automazione per distribuire e aggiornare le risorse e il codice di Azure in tutti gli ambienti. Seguire queste raccomandazioni:

  • Utilizzare IaC. Distribuire IaC usando pipeline di integrazione continua e recapito continuo (CI/CD). Azure offre modelli Bicep predefiniti, modelli di Azure Resource Manager (modelli ARM) JSON e modelli Terraform per ogni risorsa di Azure.

  • Usare una pipeline CI/CD. Usare una pipeline CI/CD per distribuire il codice dal controllo del codice sorgente ai vari ambienti, ad esempio test, gestione temporanea e produzione. Utilizzare Azure Pipelines se si lavora con Azure DevOps. Usare GitHub Actions per i progetti GitHub.

  • Integrare il test unitario. Classificare in ordine di priorità l'esecuzione e la convalida di tutti gli unit test all'interno della pipeline prima della distribuzione nel servizio app. Incorporare strumenti di qualità del codice e copertura come SonarQube per ottenere una copertura completa dei test.

  • Adottare framework di mock. Per i test che coinvolgono endpoint esterni, usare framework fittizi. Questi framework consentono di creare endpoint simulati. Eliminano la necessità di configurare endpoint esterni reali e garantire condizioni di test uniformi in ambienti diversi.

  • Eseguire analisi di sicurezza. Usare test di sicurezza delle applicazioni statici (SAST) per individuare i difetti di sicurezza e gli errori di codifica nel codice sorgente. Eseguire l'analisi della composizione software (SCA) per esaminare librerie e componenti non Microsoft per individuare i rischi per la sicurezza. Integrare gli strumenti per queste analisi sia in GitHub che in Azure DevOps.

Configurare il monitoraggio

Implementare il monitoraggio delle applicazioni e della piattaforma per migliorare l'eccellenza operativa e l'efficienza delle prestazioni dell'app Web. Per implementare il monitoraggio, seguire queste raccomandazioni:

  • Raccogliere i dati di telemetria dell'applicazione. Usare l'strumentazione automatica in Application Insights per raccogliere dati di telemetria dell'applicazione, ad esempio velocità effettiva delle richieste, durata media delle richieste, errori e monitoraggio delle dipendenze. Non è necessario modificare il codice per usare questi dati di telemetria. Spring Boot registra diverse metriche di base in Application Insights, ad esempio java virtual machine (JVM), CPU e Tomcat. Application Insights raccoglie automaticamente da framework di registrazione come Log4j e Logback.

    L'implementazione di riferimento abilita Application Insights tramite Terraform nella configurazione del app_settings servizio app:

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

    Per altre informazioni, vedere gli articoli seguenti:

  • Creare metriche dell'applicazione personalizzate. Implementare la strumentazione basata su codice per acquisire dati di telemetria dell'applicazione personalizzati aggiungendo Application Insights SDK e usando la relativa API.

  • Monitorare la piattaforma. Abilitare la diagnostica per tutti i servizi supportati. Invia la diagnostica alla stessa destinazione dei log dell'applicazione per la correlazione. I servizi di Azure creano automaticamente i log della piattaforma, ma li archivia solo quando si abilita la diagnostica. Abilitare le impostazioni di diagnostica per ogni servizio che supporta la diagnostica.

    L'implementazione di riferimento usa Terraform per abilitare la diagnostica di Azure nei servizi supportati. Il codice Terraform seguente configura le impostazioni di diagnostica per il servizio app:

    # 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
  }
}

Distribuire l'implementazione di riferimento

L'implementazione di riferimento illustra la migrazione simulata di Contoso Fiber di un'applicazione Java locale ad Azure. Vengono inoltre evidenziate le modifiche necessarie durante la fase di adozione iniziale.

L'architettura seguente rappresenta lo stato finale dell'implementazione del modello Reliable Web App di Contoso Fiber in base ai propri obiettivi.

Diagramma che mostra l'architettura dell'implementazione di riferimento.

Scaricare un file di Visio di questa architettura.

Passo successivo

  • Last updated on