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 dell'ibrido a più livelli di architettura, gli ambienti di computing si trovano in un ambiente nell'ambiente di computing privato 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é il frontend le applicazioni di solito si basano su applicazioni backend per archiviare e gestire i dati. la logica di business e l'elaborazione degli input utente, spesso sono richiesti stateless o gestire 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à.
In genere, i componenti delle applicazioni di backend sono incentrati sull'archiviazione e la gestione dei dati. Nel 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 hanno le seguenti caratteristiche sfide da gestire:
- Gestione di un grande volume di richieste
- Gestione di un grande volume 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
L'inserimento di questi strati in container separa le loro esigenze tecniche, requisiti di scalabilità e aiuta a eseguirne la migrazione in un approccio 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, Database gestiti da Google Cloud come Cloud SQL, aiutano a fornire il backend come livello di database.
Il modello di architettura ibrida a più livelli si concentra sul deployment di frontend esistenti le applicazioni cloud-native nel cloud pubblico. In questo schema, mantieni qualsiasi i componenti delle applicazioni di backend esistenti nel proprio ambiente di computing 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 la tua applicazione scala e le sue esigenze le prestazioni e l'affidabilità aumentano, dovresti iniziare a valutare se i componenti eseguire il refactoring della tua applicazione o spostarla un'architettura ottimale. Il pattern dell'architettura ibrida a più livelli ti consente di cambiare di alcuni carichi di lavoro e componenti dell'applicazione nel cloud prima di una transizione. È essenziale considerare anche il costo, il tempo e il rischio associati ad esempio una migrazione.
Il seguente diagramma mostra un tipico modello 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 i dati nell'ambiente on-premise in cui è ospitato il backend dell'applicazione (possibilmente tramite un gateway API).
Con il modello di architettura ibrida a più livelli, puoi sfruttare Infrastruttura Google Cloud e servizi globali, come mostrato nell'esempio nel diagramma seguente. Il frontend dell'applicazione è raggiungibile su Google Cloud. Può anche aggiungere elasticità al frontend utilizzando scalare automaticamente per rispondere in modo dinamico ed efficiente alla domanda di scalabilità senza rispetto al provisioning dell'infrastruttura. Esistono diverse architetture che che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ciascuna dell'architettura presenta vantaggi e svantaggi a seconda dei requisiti.
Per ulteriori informazioni, guarda 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 per Google Cloud, consulta Come creare una piattaforma per il commercio digitale su Google Cloud.
Nel diagramma precedente, il frontend dell'applicazione è ospitato Google Cloud per fornire un utente multiregionale e ottimizzato a livello globale che utilizza le applicazioni bilanciamento del carico, la scalabilità automatica e la protezione DDoS 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 pubblicare molto traffico, scegli gestiti nel cloud possono aiutarti a risparmiare sul lavoro tecnico durante la gestione la 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 Google Kubernetes Engine su hardware dedicato fornito e gestito da Google è separato dal data center Google Cloud. Per garantire che Distributed Cloud soddisfi le tue esigenze attuali e future i requisiti, conoscere i limiti di Distributed Cloud rispetto a una zona GKE convenzionale basata su cloud.
Vantaggi
Concentrarsi prima sulle applicazioni frontend presenta numerosi 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 frontend. Pertanto, isolare e migrare le applicazioni frontend tende a essere meno complesso durante la migrazione delle applicazioni backend.
- Perché le applicazioni frontend sono spesso stateless o non gestiscono dati
e tendono a essere meno difficili da migrare rispetto ai backend.
- I componenti di frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare stateless. Per ulteriori informazioni, guarda Come trasferire app web stateful 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 automatizzato. Per maggiori informazioni le informazioni, vedi CI/CD su Google Cloud.
- I frontend sensibili alle prestazioni con carico di traffico variabile possono essere vantaggiosi in modo sostanziale dal bilanciamento del carico, dai deployment multiregionali, Cloud CDN di memorizzazione nella cache, serverless e scalabilità automatica che consenta il deployment (idealmente architettura stateless).
Adozione di microservizi con container utilizzando una piattaforma gestita nel cloud, come GKE, consente di usare architetture moderne come microfrontend, che estendono i microservizi ai componenti del frontend.
L'estensione dei microservizi viene comunemente utilizzata con frontend che prevedono team che collaborano alla stessa applicazione. Quel tipo di team una struttura richiede un approccio iterativo e una manutenzione continua. Alcuni dei vantaggi utilizzando il microfrontend sono i seguenti:
- 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 implementazione senza influenzare gli altri componenti del frontend che potrebbero essere gestiti altre squadre.
Che si tratti di implementare interfacce utente o API oppure gestire Importazione dati Internet of Things (IoT), le applicazioni frontend possono trarne vantaggio dalle funzionalità dei servizi cloud Firebase Pub/Sub Apigee, Cloud CDN, App Engine, o Cloud Run.
proxy API gestiti nel cloud aiuto per:
- Disaccoppia l'API per le app dai tuoi servizi di backend, ad esempio di 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 l'implementazione di proxy API su Apigee.
Puoi anche applicare il pattern ibrido a più livelli al contrario, eseguendo il deployment i backend nel cloud mantenendo i frontend negli ambienti di computing privati. Sebbene sia meno comune, questo approccio viene applicato al meglio quando con un frontend pesante e monolitico. 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 pattern di networking per di questa architettura. Apigee ibrido è utile come piattaforma per creare e gestire proxy API in un deployment ibrido un modello di machine learning. 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 degli utenti identificati applicazioni, selezionare le opzioni di comunicazione più efficienti ed efficaci soluzione per queste applicazioni.
Poiché la maggior parte delle interazioni degli utenti coinvolge sistemi che ambienti di computing multipli, una connettività rapida e a bassa latenza sono importanti. Per soddisfare la disponibilità e le prestazioni le aspettative, dovresti progettare in modo da garantire disponibilità elevata, bassa latenza i livelli di velocità effettiva appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllato. Idealmente, dovresti esporre dell'applicazione mediante API sicure. Per ulteriori informazioni, vedi Traffico in uscita con accesso limitato.
- Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona un'opzione Regione Google Cloud geograficamente vicino all'ambiente di computing privato in cui sono ospitati i componenti di backend dell'applicazione. Per ulteriori informazioni, vedi Best practice per la selezione delle regioni di Compute Engine.
- Riduci al minimo le dipendenze elevate tra sistemi in esecuzione in diversi ambienti, in particolare quando le comunicazioni sono gestite in modo sincrono. Queste dipendenze possono rallentare le prestazioni, diminuire la disponibilità complessiva e potrebbero incorrere in costi aggiuntivi per il trasferimento di 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. Ciononostante, dovresti conoscere volume di trasferimento di dati in uscita abbandona 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ò aiutare 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 criptare tutte comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, puoi usare la VPN tunnel VPN ad alta disponibilità su Cloud Interconnect, e MACsec per Cloud Interconnect.
Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in backend diversi, consigliamo, ove applicabile, eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy agisce come punto di controllo centralizzato ed esegue misure correttive:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice del backend.
- facilita gli audit trail per la comunicazione tra tutti delle applicazioni cross-environment e dei relativi componenti disaccoppiati.
- Agisce come
livello di comunicazione intermedio
tra servizi legacy e moderni.
- Apigee e Apigee ibrido consente di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, perimetrali, in altri cloud ambienti Google Cloud.
Per facilitare l'implementazione di configurazioni ibride, utilizza Cloud Load Balancing 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 ulteriori informazioni, vedi 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 le funzionalità di Mesh di servizi e gestione delle API per proteggere e controllare la comunicazione e l'esposizione dei servizi con i microservizi dell'architettura.
- Utilizza le funzionalità di Cloud Service Mesh per consentire una 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 eseguire l'autenticazione sicura confini ambientali.
Esegui il deployment di sistemi di gestione delle configurazioni CI/CD e 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 per 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 ambienti on-premise).
- Quando utilizzi container e Kubernetes ambienti, hai la flessibilità necessaria per modernizzare i carichi di lavoro per 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 container dei componenti dell'applicazione modernizzati.
- 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. Usare Cloud SQL per i dati strutturati Cloud Storage per i file multimediali è un approccio comune per soddisfare dati diversificati le esigenze di archiviazione. 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. Inoltre, vedi Spiegazione delle opzioni di database di Google Cloud