Questa architettura di riferimento descrive come eseguire carichi di lavoro Java Spring Boot in Azure Spring Apps. La progettazione usa la ridondanza della zona per ottenere una disponibilità elevata. Implementare questa progettazione per impedire che un'applicazione non riesca se si verifica un'interruzione in tutti i data center in una zona.
Questa architettura consente di:
- Aumentare la disponibilità dell'applicazione in una distribuzione a singola zona.
- Aumentare la resilienza complessiva e l'obiettivo del livello di servizio (SLO) dell'applicazione.
Questa soluzione presenta una strategia di base per la distribuzione di App Azure Spring. Per altre soluzioni basate su questa architettura, vedere Distribuire Azure Spring Apps in più aree e App Azure Spring integrate con le zone di destinazione.
Suggerimento
Vedere un esempio di implementazione che illustra alcune delle scelte di progettazione di questa architettura. Considerare questa implementazione come primo passo verso la produzione.
Architettura
Il diagramma seguente illustra l'architettura per questo approccio:
Scaricare un file di Visio di questa architettura.
Workflow
Questo flusso di lavoro corrisponde al diagramma precedente:
L'utente accede all'applicazione usando il nome host HTTP dell'applicazione, ad esempio
www.contoso.com. DNS di Azure viene usato per risolvere la richiesta di questo nome host nell'endpoint pubblico del gateway di app Azure lication.gateway applicazione viene usato per controllare la richiesta. Viene usato anche per inoltrare il traffico consentito all'indirizzo IP del servizio di bilanciamento del carico nell'istanza di Azure Spring Apps di cui è stato effettuato il provisioning. gateway applicazione è integrato con Web application firewall di Azure.
Il servizio di bilanciamento del carico interno viene usato per instradare il traffico ai servizi back-end.
Durante l'elaborazione della richiesta, l'applicazione comunica con altri servizi di Azure all'interno della rete virtuale. Ad esempio, l'applicazione potrebbe ricevere segreti da Azure Key Vault o dallo stato di archiviazione dal database.
Componenti
I servizi di Azure seguenti sono i componenti di questa architettura:
La versione standard di Azure Spring Apps viene usata per ospitare un'applicazione Java Spring Boot di esempio implementata come microservizi.
La versione standard v2 di gateway applicazione viene usata per gestire il traffico verso le applicazioni. Funge da proxy inverso locale nell'area in cui viene eseguita l'applicazione.
Questo SKU include web application firewall integrato per proteggere le applicazioni Web da exploit e vulnerabilità. Web Application Firewall in gateway applicazione tiene traccia degli exploit OWASP (Open Web Application Security Project).
DNS di Azure viene usato per risolvere le richieste inviate al nome host dell'applicazione. Risolve tali richieste all'endpoint pubblico gateway applicazione. Le zone private DNS di Azure vengono usate per risolvere le richieste agli endpoint privati che accedono alle risorse di collegamento privato di Azure denominate.
Database di Azure per MySQL viene usato per archiviare lo stato in un database relazionale back-end.
Key Vault viene usato per archiviare segreti e certificati dell'applicazione. I microservizi eseguiti in Azure Spring Apps usano i segreti dell'applicazione. Azure Spring Apps e gateway applicazione usare i certificati per la conservazione dei nomi host.
Alternative
Database di Azure per MySQL non è l'unica opzione per un database. È anche possibile usare:
Ridondanza
Creare ridondanza nel carico di lavoro per ridurre al minimo singoli punti di errore. In questa architettura i componenti vengono replicati tra zone all'interno di un'area. Nell'architettura assicurarsi di usare le zone di disponibilità per tutti i componenti della configurazione.
I servizi di Azure non sono supportati in tutte le aree e non in tutte le aree supportano le zone. Prima di selezionare un'area, verificare il supporto a livello di area e zona.
I servizi con ridondanza della zona replicano o distribuiscono automaticamente le risorse tra le zone. I servizi sempre disponibili sono sempre disponibili in tutte le aree geografiche di Azure e sono resilienti alle interruzioni a livello di zona e a livello di area.
La tabella seguente illustra i tipi di resilienza per i servizi in questa architettura:
| Service | Resilienza |
|---|---|
| DNS Azure | Sempre disponibile |
| Gateway applicazione | Con ridondanza della zona |
| Azure Spring Apps | Con ridondanza della zona |
| Database di Azure per MySQL | Con ridondanza della zona |
| Insieme di credenziali delle chiavi di | Con ridondanza della zona |
| Rete virtuale di Azure | Con ridondanza della zona |
| Endpoint privati di Azure | Con ridondanza della zona |
Azure Spring Apps supporta la ridondanza della zona. Con la ridondanza della zona, tutta l'infrastruttura sottostante del servizio viene distribuita in più zone di disponibilità, che offre una maggiore disponibilità per l'applicazione. Le applicazioni vengono ridimensionate orizzontalmente senza modifiche al codice. Una rete ad alte prestazioni connette le zone di disponibilità di Azure. La connessione ha una latenza di round trip inferiore a 2 millisecondi (ms). Non è necessario basarsi sulla replica asincrona per i carichi di lavoro di dati, che spesso presenta problemi di progettazione.
Sono configurate più zone di disponibilità per gateway applicazione, incluso l'indirizzo IP pubblico usato gateway applicazione. Gli indirizzi IP pubblici con uno SKU standard supportano le zone di disponibilità.
Questa architettura usa Database di Azure per MySQL con l'opzione di distribuzione Server flessibile per supportare la disponibilità elevata con failover automatico. A seconda dei requisiti di latenza, scegliere disponibilità elevata con ridondanza della zona o disponibilità elevata della stessa zona. Con una configurazione a disponibilità elevata, l'opzione Server flessibile effettua automaticamente il provisioning e gestisce una replica di standby. Se si verifica un'interruzione, i dati di cui è stato eseguito il commit non andranno persi.
Key Vault è automaticamente ridondante nella zona in qualsiasi area in cui sono disponibili le zone di disponibilità. L'istanza di Key Vault usata in questa architettura viene distribuita per archiviare i segreti per i servizi back-end.
Scalabilità
La scalabilità indica la capacità del carico di lavoro di soddisfare in modo efficiente le richieste che gli utenti lo pongono. L'approccio multi-zona è migliore per la scalabilità rispetto a una distribuzione a zona singola perché distribuisce il carico tra le zone di disponibilità.
Questa architettura include diversi componenti che possono essere ridimensionati automaticamente in base alle metriche:
gateway applicazione supporta il ridimensionamento automatico. Per altre informazioni, vedere Ridimensionare gateway applicazione v2 e Web Application Firewall v2.
Azure Spring Apps supporta la scalabilità automatica. Per altre informazioni, vedere Configurare la scalabilità automatica per le applicazioni.
A seconda della configurazione del database, è possibile che si verifichi una latenza aggiuntiva quando è necessario sincronizzare i dati tra le zone.
Sicurezza di rete
Proteggere l'applicazione da accessi non autorizzati da Internet, sistemi in reti private, altri servizi di Azure e dipendenze strettamente associate.
Rete virtuale è il blocco predefinito fondamentale per una rete privata in Azure. Questa architettura usa una rete virtuale per l'area della distribuzione. Posizionare i componenti nelle subnet per creare un ulteriore isolamento. Azure Spring Apps richiede una subnet dedicata per il runtime del servizio e una subnet separata per le applicazioni Java Spring Boot.
Proteggere le reti virtuali con Protezione DDoS di Azure. Combinare la protezione DDoS (Distributed Denial of Service) con le procedure consigliate per la progettazione delle applicazioni per fornire mitigazioni avanzate per difendersi dagli attacchi DDoS.
La progettazione dell'architettura incorpora diverse soluzioni PaaS (Platform as a Service) che consentono di elaborare una richiesta utente. Posizionare controlli di rete rigorosi su tali servizi per assicurarsi che l'applicazione non sia interessata.
Connettività privata
Usare endpoint privati o integrazione di rete per fornire comunicazioni da Azure Spring Apps ai servizi di supporto, ad esempio Key Vault e Database di Azure per MySQL.
Usare endpoint privati per controllare l'accesso. Le interfacce di rete usano indirizzi IP privati per trasferire i servizi nella rete virtuale. Questa architettura usa i servizi di Azure che configurano automaticamente gli endpoint privati.
Distribuire Azure Spring Apps nella rete tramite il processo di inserimento della rete virtuale. L'accesso all'applicazione viene eseguito raggiungendo l'indirizzo IP privato.
Il database segue un modello simile. La modalità di distribuzione server flessibile di Database di Azure per MySQL supporta l'integrazione della rete virtuale tramite una subnet dedicata.
Altri servizi, ad esempio Key Vault, sono connessi alla rete virtuale tramite collegamento privato. Per collegamento privato, è necessario abilitare un endpoint privato per disabilitare l'accesso alla rete pubblica. Per altre informazioni, vedere Integrare Key Vault con collegamento privato.
Gli endpoint privati non richiedono una subnet dedicata, ma è consigliabile inserirli in una subnet separata. Gli indirizzi IP privati agli endpoint privati vengono assegnati da tale subnet.
L'endpoint privato e le connessioni integrate nella rete usano una zona privata DNS di Azure.
Controlli sul flusso di traffico
Con questa architettura, le richieste in ingresso sono consentite solo tramite l'endpoint pubblico esposto da gateway applicazione. Il traffico deve comunque essere controllato per bloccare exploit e vulnerabilità. Web Application Firewall nel gateway applicazione tiene traccia delle vulnerabilità OWASP. Il traffico in ingresso viene controllato in base alle regole configurate con un'azione da seguire.
L'istanza di Azure Spring Apps dispone di un servizio di bilanciamento del carico interno che instrada e distribuisce il traffico ai servizi back-end. Il servizio di bilanciamento del carico è configurato per accettare il traffico solo da gateway applicazione.
L'applicazione potrebbe dover connettersi ad altri endpoint tramite La rete Internet pubblica. Per limitare il flusso, è consigliabile posizionare Firewall di Azure nel percorso in uscita.
Configurazione del proxy inverso
Questa soluzione usa gateway applicazione come proxy inverso. Tuttavia, è possibile usare proxy inversi diversi davanti ad Azure Spring Apps. È possibile combinare gateway applicazione con Frontdoor di Azure oppure usare Frontdoor di Azure anziché gateway applicazione.
Per informazioni sugli scenari di proxy inverso, su come configurarli e sulle relative considerazioni sulla sicurezza, vedere Esporre Azure Spring Apps tramite un proxy inverso.
Gestione delle identità e dell'accesso
Oltre a usare i controlli di rete, rafforzare il comportamento di sicurezza usando l'identità come perimetro.
L'applicazione deve eseguire l'autenticazione quando si connette ai servizi back-end, ad esempio se l'applicazione recupera i segreti da Key Vault. Nell'applicazione, l'approccio consigliato consiste nell'abilitare le identità gestite di Microsoft Entra per le risorse di Azure. Questo metodo di configurazione assegna un'identità all'applicazione in modo da poter ottenere token ID Microsoft Entra, riducendo così il sovraccarico della gestione delle credenziali.
Questa architettura usa le identità gestite assegnate dal sistema per diverse interazioni.
I servizi back-end devono consentire l'accesso all'entità servizio allocata all'identità gestita. Il servizio deve definire criteri di accesso minimi per determinate azioni. In questa architettura, Key Vault viene usato per concedere all'applicazione l'accesso ai segreti, ai certificati e alle chiavi.
Gestione dei segreti
Questa architettura archivia i segreti e i certificati dell'applicazione in un singolo insieme di credenziali delle chiavi. I segreti dell'applicazione e i certificati per la conservazione dei nomi host sono problematiche diverse, pertanto è consigliabile archiviare questi elementi in insiemi di credenziali delle chiavi separati. Questo approccio alternativo aggiunge un altro insieme di credenziali delle chiavi all'architettura.
Monitoraggio
Monitoraggio di Azure è una soluzione di monitoraggio per la raccolta, l'analisi e la risposta ai dati di monitoraggio dagli ambienti cloud e locali.
Aggiungere strumentazione all'applicazione per generare log e metriche a livello di codice. Valutare la possibilità di abilitare la traccia distribuita per garantire l'osservabilità tra i servizi all'interno dell'istanza di Azure Spring Apps. Usare uno strumento di gestione delle prestazioni delle applicazioni (APM) per raccogliere i log e i dati delle metriche. L'agente Java di Application Insights per Monitoraggio di Azure è una buona scelta per lo strumento APM.
Usare la diagnostica della piattaforma per ottenere log e metriche da tutti i servizi di Azure, ad esempio Database di Azure per MySQL. Integrare tutti i dati con i log di Monitoraggio di Azure per fornire informazioni end-to-end sull'applicazione e sui servizi della piattaforma.
L'area di lavoro Log Analytics di Azure è il sink di dati di monitoraggio che raccoglie log e metriche dalle risorse di Azure e Da Application Insights. Questa soluzione di registrazione offre visibilità, che consente ai processi di automazione di ridimensionare i componenti in tempo reale. L'analisi dei dati di log può anche rivelare inefficienze nel codice dell'applicazione che è possibile affrontare per migliorare i costi e le prestazioni.
Per indicazioni sul monitoraggio specifiche di Spring App, vedere Monitorare le applicazioni end-to-end e Monitor con Dynatrace Java OneAgent.
Distribuzione automatica
Automatizzare la distribuzione dell'infrastruttura e le distribuzioni del codice dell'applicazione il più possibile.
L'automazione delle distribuzioni dell'infrastruttura garantisce che la configurazione dell'infrastruttura sia identica, che consente di evitare la deviazione della configurazione, potenzialmente tra gli ambienti. È anche possibile usare l'automazione dell'infrastruttura per testare le operazioni di failover.
È possibile usare una strategia di distribuzione blu-verde o canary per le applicazioni.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Le considerazioni seguenti forniscono indicazioni per l'implementazione dei pilastri di Azure Well-Architected Framework nel contesto di questa architettura.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Implementare i suggerimenti seguenti per creare un'applicazione più affidabile:
Usare una distribuzione blu-verde per semplificare il rollback a uno stato integro precedente se si verificano problemi critici.
Configurare la scalabilità automatica per le applicazioni per migliorare le prestazioni dell'applicazione quando cambia la domanda.
Abilitare l'arresto normale del Web Spring Boot e configurare la terminazione normale di Azure Spring Apps per arrestare forzatamente i processi eseguiti nell'istanza dell'app.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Implementare i suggerimenti seguenti per creare un'applicazione più sicura:
Usare soluzioni di gestione delle identità e degli accessi (IAM) mature, ad esempio Microsoft Entra ID. Abilitare l'autenticazione a più fattori. Per altre informazioni, vedi:
Evitare di usare le password quando possibile. Per altre informazioni, vedi:
Per consigli su come proteggere l'app Azure Spring, vedere Baseline di sicurezza di Azure per Azure Spring Apps.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Per questa architettura, prevedere costi più elevati perché si distribuiscono componenti in più zone. Anziché un'istanza di Azure Spring Apps, è possibile eseguire due o persino tre istanze. Non sono tuttavia previsti costi aggiuntivi per abilitare la ridondanza della zona nel servizio. Per altre informazioni, vedere Prezzi di Azure Spring Apps.
Prendere in considerazione le opzioni di implementazione seguenti per gestire i costi:
È possibile distribuire applicazioni e tipi di applicazioni diversi in una singola istanza di Azure Spring Apps. Quando si distribuiscono più applicazioni, il costo dell'infrastruttura sottostante viene condiviso tra le applicazioni.
Azure Spring Apps supporta la scalabilità automatica delle applicazioni attivata da metriche o pianificazioni, che possono migliorare l'utilizzo e l'efficienza dei costi.
È possibile usare Application Insights in Monitoraggio di Azure per ridurre i costi operativi. Il monitoraggio continuo consente di risolvere i problemi più rapidamente e migliorare i costi e le prestazioni.
Scegliere il piano tariffario migliore in base ai requisiti:
Usare la scalabilità automatica per le applicazioni per aumentare e ridurre le prestazioni in base alla domanda.
Per un costo stimato dei servizi per questa architettura, vedere il calcolatore dei prezzi di Azure. Questa stima usa valori predefiniti ragionevoli per un'applicazione su scala ridotta. È possibile aggiornare la stima in base ai valori di velocità effettiva previsti per l'applicazione.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.
Oltre alle indicazioni di monitoraggio illustrate in precedenza, implementare i suggerimenti seguenti per distribuire e monitorare l'applicazione.
Automatizzare le distribuzioni di applicazioni usando Azure DevOps o GitHub Actions.
Monitorare le app di Azure Spring Apps usando log, metriche e traccia.
Monitorare le metriche in Database di Azure per PostgreSQL usando il server flessibile.
Usare Grafana gestito di Azure per visualizzare e analizzare i dati di telemetria dell'applicazione e dell'infrastruttura in tempo reale.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.
Implementare i suggerimenti seguenti per creare un'applicazione più efficiente:
Ridimensionare le app manualmente o automaticamente.
Ridimensionare le operazioni usando il server flessibile.
Distribuire lo scenario
Per distribuire questa architettura, seguire le istruzioni dettagliate nell'architettura di riferimento a più zone di Azure Spring Apps. La distribuzione usa i modelli Terraform.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Gitte Vermeiren | FastTrack per tecnico di Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Guida introduttiva: Distribuire la prima applicazione Web in Azure Spring Apps
- Cosa sono le identità gestite per le risorse di Azure?
Risorse correlate
- App Spring di Azure integrate con le zone di destinazione
- Distribuire App Azure Spring in più aree
- Esporre Azure Spring Apps tramite un proxy inverso
- Distribuzioni blu-verde a disponibilità elevata per le applicazioni
- Gestione delle identità e degli accessi per App Spring di Azure nelle zone di destinazione