I componenti dell'architettura di un'applicazione possono essere classificati frontend o backend. In alcuni scenari, questi componenti possono essere ospitati operare da diversi ambienti di elaborazione. Nell'ambito del pattern di architettura ibrida a più livelli, gli ambienti di calcolo si trovano in un ambiente di calcolo privato on-premise e in Google Cloud.
I componenti dell'applicazione frontend sono esposti direttamente agli utenti finali o ai dispositivi. Come Di conseguenza, queste applicazioni sono spesso sensibili alle prestazioni. Per sviluppare nuovi e miglioramenti, gli aggiornamenti software possono essere frequenti. Poiché le applicazioni frontend solitamente si basano su applicazioni di backend per archiviare e gestire i dati, nonché eventualmente la logica aziendale e l'elaborazione degli input utente, spesso sono senza stato o gestiscono solo volumi limitati di dati.
Per essere accessibili e utilizzabili, puoi creare le tue applicazioni frontend con con una varietà di framework e tecnologie. Alcuni fattori chiave per il successo di un frontend includono prestazioni dell'applicazione, velocità di risposta e la compatibilità.
I componenti dell'applicazione di backend in genere si concentrano sull'archiviazione e sulla gestione dei dati. Nella alcune architetture, la logica di business potrebbe essere incorporata di strumento di authoring. Le nuove release delle applicazioni di backend tendono a essere meno frequenti le release per le applicazioni di frontend. Le applicazioni di backend devono gestire le seguenti sfide:
- Gestione di un elevato volume di richieste
- Gestione di un volume elevato di dati
- Protezione dei dati
- Mantenere dati attuali e aggiornati in tutte le repliche di sistema
La architettura dell'applicazione a tre livelli è una delle implementazioni più popolari per lo sviluppo di soluzioni come i siti web di e-commerce contenenti diverse applicazioni componenti. Questa architettura include i seguenti livelli. Ogni livello è operativo in modo indipendente, ma sono strettamente collegati e funzionano tutti insieme.
- Frontend web e livello di presentazione
- Livello di applicazione
- Accesso ai dati o livello di backend
Inserire questi livelli in contenitori separa le relative esigenze tecniche, come i requisiti di scalabilità, e aiuta a eseguirne la migrazione in modo graduale. Inoltre, consente di eseguirne il deployment su servizi cloud indipendenti dalla piattaforma portabilità in più ambienti, utilizza la gestione automatizzata e scala con il cloud di Google Cloud, come la versione Cloud Run o Google Kubernetes Engine (GKE) Enterprise. Inoltre, i database gestiti da Google Cloud come Cloud SQL contribuiscono a fornire il backend come livello di database.
Il pattern di architettura ibrida a più livelli si concentra sul deployment dei componenti dell'applicazione frontend esistenti nel cloud pubblico. In questo pattern, mantieni tutti i componenti dell'applicazione di backend esistenti nel loro ambiente di calcolo privato. A seconda delle dimensioni e della progettazione specifica dell'applicazione, è possibile migrare i componenti delle applicazioni frontend caso per caso. Per maggiori informazioni le informazioni, vedi Eseguire la migrazione a Google Cloud.
Se hai un'applicazione esistente con componenti backend e frontend ospitati nel tuo ambiente on-premise, considera i limiti della tua dell'architettura. Ad esempio, man mano che l'applicazione si espande e le richieste relative alle sue prestazioni e affidabilità aumentano, devi iniziare a valutare se parti dell'applicazione devono essere sottoposte a refactoring o spostate in un'architettura diversa e più ottimale. Il pattern di architettura ibrida a più livelli ti consente di spostare alcuni carichi di lavoro e componenti dell'applicazione sul cloud prima di eseguire una transizione completa. È inoltre essenziale considerare il costo, il tempo e il rischio associati ad esempio una migrazione.
Il seguente diagramma mostra un tipico pattern di architettura ibrida a più livelli.
Nel diagramma precedente, le richieste del client vengono inviate al frontend dell'applicazione in hosting su Google Cloud. A sua volta, il frontend dell'applicazione invia nuovamente i dati all'ambiente on-premise in cui è ospitato il backend dell'applicazione (idealmente tramite un API gateway).
Con il pattern di architettura ibrida a più livelli, puoi sfruttare l'infrastruttura e i servizi globali di Google Cloud, come mostrato nell'architettura di esempio nel seguente diagramma. Il frontend dell'applicazione è accessibile tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando la scalabilità automatica per rispondere in modo dinamico ed efficiente alla domanda in crescita senza sovraprovisioning dell'infrastruttura. Esistono diverse architetture che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ogni architettura presenta vantaggi e svantaggi per requisiti diversi.
Per saperne di più, guarda il video Tre modi per eseguire app web scalabili su Google Cloud su YouTube. Per scoprire di più sui diversi modi per modernizzare la tua piattaforma di e-commerce su Google Cloud, consulta Come creare una piattaforma di commercio digitale su Google Cloud.
Nel diagramma precedente, il frontend dell'applicazione è ospitato su Google Cloud per offrire un'esperienza utente ottimizzata a livello globale e multiregionale che utilizza il bilanciamento del carico, l'autoscaling e la protezione DDoS tramite Google Cloud Armor.
Nel tempo, il numero di applicazioni di cui esegui il deployment nel cloud pubblico al punto in cui potresti prendere in considerazione lo spostamento dell'applicazione di backend al cloud pubblico. Se prevedi di gestire un traffico elevato, optare per i servizi gestiti sul cloud potrebbe aiutarti a risparmiare sui costi di progettazione per la gestione della tua infrastruttura. Prendi in considerazione questa opzione a meno che non si applichino vincoli o requisiti di hosting dei componenti dell'applicazione di backend on-premise. Ad esempio, se dei dati di backend sono soggetti a restrizioni normative, per i dati on-premise. Ove applicabile e conforme, tuttavia, Protezione dei dati sensibili come tecniche di anonimizzazione, può aiutarti a spostare i dati quando necessario.
Nel pattern di architettura ibrida a più livelli, puoi anche utilizzare Google Distributed Cloud in alcuni scenari. Distributed Cloud ti consente di eseguire i cluster Google Kubernetes Engine su hardware dedicato fornito e gestito da Google e separato dal data center Google Cloud. Per assicurarti che Distributed Cloud soddisfi i tuoi requisiti attuali e futuri, tieni presente le limitazioni di Distributed Cloud rispetto a una zona GKE basata su cloud convenzionale.
Vantaggi
Concentrarsi prima sulle applicazioni frontend ha diversi vantaggi, tra cui seguenti:
- I componenti del frontend dipendono dalle risorse di backend e talvolta gli altri componenti frontend.
- I componenti di backend non dipendono dai componenti di frontend. Pertanto, l'isolamento e la migrazione delle applicazioni frontend tendono a essere meno complessi rispetto alla migrazione delle applicazioni di backend.
- Poiché le applicazioni frontend spesso non hanno stato o non gestiscono i dati da sole, la migrazione è tendenzialmente meno complessa rispetto ai backend.
- I componenti frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare un'architettura stateless. Per saperne di più, guarda Come eseguire il porting di app web con stato in Cloud Run su YouTube.
Deployment di applicazioni frontend esistenti o di recente sviluppo nel cloud pubblico offre diversi vantaggi:
- Molte applicazioni frontend sono soggette a modifiche frequenti. Esecuzione nel cloud pubblico, semplifica la configurazione di un'infrastruttura il processo di integrazione e deployment continuo (CI/CD). Puoi utilizzare CI/CD per inviare aggiornamenti in modo efficiente e automatico. Per ulteriori informazioni, consulta CI/CD su Google Cloud.
- I frontend sensibili alle prestazioni con un carico di traffico variabile possono trarre sostanziali vantaggi dal bilanciamento del carico, dai deployment multiregionali, dal caching di Cloud CDN, dalle funzionalità serverless e di scalabilità automatica abilitati da un deployment basato su cloud (idealmente con un'architettura stateless).
L'adozione di microservizi con container utilizzando una piattaforma gestita sul cloud, come GKE, consente di utilizzare architetture moderne come i microfrontend, che estendono i microservizi ai componenti frontend.
L'estensione dei microservizi è comunemente utilizzata con i frontend che coinvolgono più team che collaborano alla stessa applicazione. Questo tipo di struttura del team richiede un approccio iterativo e una manutenzione continua. Ecco alcuni dei vantaggi dell'utilizzo dei microfrontend:
- Può essere trasformato in moduli di microservizi indipendenti sviluppo, test e deployment.
- Offre una separazione in cui i singoli team di sviluppo possono selezionare le tecnologie e il codice che preferiscono.
- Può favorire cicli rapidi di sviluppo e deployment senza influire sul resto dei componenti frontend che potrebbero essere gestiti da altri team.
Che implementino interfacce utente o API o gestiscano l'importazione di dati di internet of things (IoT), le applicazioni frontend possono trarre vantaggio dalle funzionalità dei servizi cloud come Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.
I proxy API gestiti su Cloud aiutano a:
- Disaccoppia l'API per le app dai tuoi servizi di backend, come i microservizi.
- Proteggi le app dalle modifiche al codice del backend.
- Supportare le architetture di frontend basate su API esistenti, come backend per frontend (BFF), microfrontend e altri.
- Esponi le tue API su Google Cloud o in altri ambienti implementando proxy API su Apigee.
Puoi anche applicare il pattern ibrido a più livelli in modo inverso, eseguendo il deployment dei backend nel cloud e mantenendo i frontend in ambienti di calcolo privati. Sebbene sia meno comune, questo approccio è preferibile quando si ha a che fare con un frontend monolitico e di grandi dimensioni. In questi casi, potrebbe essere più facile di estrarre iterativamente le funzionalità di backend ed eseguire il deployment di nel cloud.
La terza parte di questa serie illustra i possibili modelli di rete per abilitare una tale architettura. Apigee hybrid è una piattaforma per la creazione e la gestione di proxy API in un modello di deployment ibrido. Per ulteriori informazioni, vedi Architettura a basso accoppiamento, tra cui architetture monolitiche e a microservizi a più livelli.
Best practice
Utilizza le informazioni in questa sezione per pianificare l'architettura ibrida a più livelli.
Best practice per ridurre la complessità
Quando applichi il modello di architettura ibrida a più livelli, considera la classe seguendo le best practice che possono aiutare a ridurre il deployment complessivo complessità operativa:
- In base alla valutazione dei modelli di comunicazione delle applicazioni identificate, seleziona la soluzione di comunicazione più efficiente ed efficace per queste applicazioni.
Poiché la maggior parte delle interazioni utente coinvolge sistemi che si connettono su più ambienti di calcolo, è importante una connettività veloce e a bassa latenza tra questi sistemi. Per soddisfare le aspettative di disponibilità e prestazioni, devi progettare per garantire un'alta disponibilità, una bassa latenza e livelli di throughput appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllato. Idealmente, devi esporre i componenti dell'applicazione utilizzando API sicure. Per ulteriori informazioni, vedi Traffico in uscita con accesso limitato.
- Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona una regione Google Cloud vicina geograficamente all'ambiente di calcolo privato in cui sono ospitati i componenti di backend dell'applicazione. Per saperne di più, consulta Best practice per la scelta delle regioni Compute Engine.
- Riduci al minimo le dipendenze elevate tra sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento dei dati in uscita.
- Con il modello di architettura ibrida a più livelli, potresti avere dimensioni i volumi di traffico in entrata dagli ambienti on-premise in entrata rispetto al traffico in uscita da Google Cloud. Tuttavia, devi conoscere il volume previsto di trasferimenti di dati in uscita che esce da Google Cloud. Se prevedi di utilizzare questa architettura a lungo termine con volumi di trasferimento di dati in uscita elevati, valuta la possibilità e Cloud Interconnect. Cloud Interconnect può aiutarti a ottimizzare le prestazioni di connettività e potrebbero ridurre i costi per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, vedi Prezzi di Cloud Interconnect.
- Per proteggere le informazioni sensibili, ti consigliamo di crittografare tutti comunicazioni in transito. Se la crittografia è richiesta a livello di connettività, puoi utilizzare i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.
Per superare le incoerenze in protocolli, API e meccanismi di autenticazione su diversi backend, ti consigliamo, ove applicabile, di eseguire il deployment di un gateway o un proxy API come facciata unificante. Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti misure:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice del backend.
- Facilita le procedure di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
- Agisce come
livello di comunicazione intermedio
tra i servizi legacy e modernizzati.
- Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello enterprise in ambienti on-premise, edge, altri cloud e Google Cloud.
Per facilitare l'implementazione di configurazioni ibride, utilizza il bilanciamento del carico Cloud con connettività ibrida. Ciò significa che puoi estendere i vantaggi del bilanciamento del carico del cloud ai servizi in hosting sul tuo ambiente di computing on-premise. Questo approccio consente di migrazioni dei carichi di lavoro a Google Cloud con un servizio minimo o nullo un'interruzione del servizio, garantendo una transizione senza problemi per i servizi distribuiti. Per maggiori informazioni, consulta la panoramica dei gruppi di endpoint di rete con connettività ibrida.
A volte, l'utilizzo di un gateway API o di un proxy Un bilanciatore del carico delle applicazioni insieme, possono fornire una soluzione più solida per la gestione, proteggere e distribuire il traffico delle API su larga scala. Utilizzo di Cloud Load Balancing con i gateway API ti consente di:
- Fornisci API ad alte prestazioni con Apigee e Cloud CDN, per ridurre la latenza, ospitare le API a livello globale e aumentare la disponibilità nelle stagioni di picco di traffico. Per ulteriori informazioni, guarda API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
- Implementa una gestione avanzata del traffico.
- Utilizzare Google Cloud Armor come protezione dagli attacchi DDoS e sicurezza della rete per proteggere le API.
- Gestisci un bilanciamento del carico efficiente tra gateway in più regioni. Per ulteriori informazioni, guarda Protezione delle API ed implementazione del failover multiregione con Private Service Connect e Apigee su YouTube.
Utilizza la gestione delle API e il mesh di servizi per proteggere e controllare la comunicazione e l'esposizione dei servizi con l'architettura di microservizi.
- Utilizza Cloud Service Mesh per consentire la comunicazione tra servizi, che mantiene la qualità del servizio in un sistema composto da servizi distribuiti in cui puoi gestire l'autenticazione, l'autorizzazione e la crittografia tra i servizi.
- Usa una piattaforma di gestione delle API come Apigee, consente alla tua organizzazione e alle entità esterne di utilizzare questi servizi e mostrarle come API.
Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini degli ambienti.
Esegui il deployment di sistemi di gestione delle configurazioni e CI/CD nel cloud pubblico. Per ulteriori informazioni, vedi Pattern dell'architettura di networking speculare.
Per aumentare l'efficienza operativa, usa strumenti coerenti e pipeline CI/CD in diversi ambienti.
Best practice per le architetture dei singoli carichi di lavoro e delle applicazioni
- Anche se in questo pattern l'attenzione si concentra sulle applicazioni frontend, consapevoli della necessità di modernizzare le applicazioni di backend. Se di sviluppo delle applicazioni di backend è notevolmente più lento rispetto a delle applicazioni frontend, la differenza può causare una maggiore complessità.
- Trattare le API come interfacce di backend semplifica le integrazioni, il frontend lo sviluppo e le interazioni con i servizi nascondendo le complessità del sistema di backend. Per affrontare queste sfide, Apigee facilita lo sviluppo e la gestione di gateway/proxy API per ambienti ibridi e deployment multi-cloud.
- Scegli il tipo approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici dinamica), il rendimento dell'ottimizzazione per i motori di ricerca e le aspettative sulle velocità di caricamento delle pagine.
- Al momento di scegliere un'architettura per applicazioni web basate sui contenuti, sono disponibili varie opzioni: monolitico, serverless, basate su eventi e microservizi. Per selezionare il modello più adatto dell'architettura, valutate attentamente queste opzioni rispetto alla vostra i futuri requisiti dell'applicazione. Per aiutarti a prendere una decisione relativa all'architettura in linea con i tuoi obiettivi commerciali e tecnici, consulta Confronto di diverse architetture per i backend di applicazioni web basati sui contenuti, e Considerazioni principali per i backend web.
Con un'architettura di microservizi, puoi utilizzare applicazioni containerizzate con Kubernetes come livello di runtime comune. Con il modello ibrido a più livelli , puoi eseguirla in uno dei seguenti scenari:
In entrambi gli ambienti (Google Cloud e i tuoi ambienti on-premise).
- Quando utilizzi container e Kubernetes in diversi ambienti, hai la flessibilità di modernizzare i carichi di lavoro e poi eseguire la migrazione a Google Cloud in momenti diversi. Questo aiuta quando un carico di lavoro dipende fortemente da un altro e non è possibile eseguirne la migrazione. singolarmente o la portabilità dei carichi di lavoro ibridi le migliori risorse disponibili in ogni ambiente. In ogni caso, GKE Enterprise può essere una tecnologia abilitante chiave. Per ulteriori informazioni, vedi Ambiente ibrido di GKE Enterprise.
In un ambiente Google Cloud per i componenti dell'applicazione sottoposti a migrazione e modernizzazione.
- Utilizza questo approccio con backend legacy on-premise che non supportano la containerizzazione o che richiedono risorse e tempo significativi per modernizzarsi nel breve periodo.
Scopri di più sulla progettazione e il refactoring di un'app monolitica un'architettura di microservizi per modernizzare l'architettura delle applicazioni web, vedi Introduzione ai microservizi.
Puoi combinare le tecnologie di archiviazione dei dati a seconda delle esigenze le tue applicazioni web. L'utilizzo di Cloud SQL per i dati strutturati e di Cloud Storage per i file multimediali è un approccio comune per soddisfare diverse esigenze di archiviazione dei dati. Detto questo, la scelta dipende molto dal caso d'uso specifico. Per scopri di più sulle opzioni di archiviazione dei dati per l'applicazione basata sui contenuti e le modalità efficaci, Opzioni di archiviazione dei dati per le app web basate sui contenuti. Consulta anche Le opzioni di database Google Cloud, spiegate