Questa guida fornisce un'introduzione all'ambiente flessibile per coloro hanno familiarità con l'ambiente standard. Spiega le somiglianze e le differenze principali tra gli ambienti e fornisce anche consigli di architettura generale per le applicazioni che utilizzano entrambi gli ambienti.
Per una mappatura dei servizi disponibili nell'ambiente standard ai relativi analoghi nell'ambiente flessibile, consulta Eseguire la migrazione dei servizi dall'ambiente standard all'ambiente flessibile.
Somiglianze e differenze principali
Entrambi gli ambienti forniscono l'infrastruttura di deployment, pubblicazione e scalabilità di App Engine. Le differenze principali riguardano il modo in cui l'ambiente esegue l'applicazione, il modo in cui l'applicazione accede ai servizi esterni, il modo in cui esegui l'applicazione localmente e il modo in cui l'applicazione viene scalata. Puoi anche fare riferimento la scelta di un ambiente per un riepilogo generale di queste differenze.
Esecuzione dell'applicazione
Nell'ambiente standard, l'applicazione viene eseguita su un'istanza leggera all'interno di una sandbox. Questa sandbox limita ciò che la tua applicazione può fare. Per Ad esempio, la sandbox consente alla tua app di usare solo un insieme limitato di librerie e la tua app non può scrivere su disco. L'ambiente standard limita inoltre le opzioni di CPU e memoria disponibili per l'applicazione. A causa di queste restrizioni, la maggior parte delle applicazioni standard di App Engine tende a essere stateless applicazioni web che rispondono rapidamente alle richieste HTTP.
Al contrario, l'ambiente flessibile esegue l'applicazione nei container Docker sulle macchine virtuali (VM) Google Compute Engine, con meno restrizioni. Ad esempio, puoi utilizzare qualsiasi linguaggio di programmazione che preferisci, puoi scrivere su disco, utilizzare le librerie che desideri e persino eseguire i processi di machine learning. L'ambiente flessibile ti consente anche di scegliere qualsiasi tipo di macchina Compute Engine per le tue istanze in modo che la tua applicazione abbia accesso a più memoria e CPU.
Accesso a servizi esterni
Nell'ambiente standard, l'applicazione in genere accede a servizi come Datastore tramite le API google.appengine integrate. Tuttavia, in nell'ambiente flessibile, queste API non sono più disponibili. Utilizza invece Librerie client di Google Cloud. Queste librerie client funzionano ovunque, il che significa che la tua applicazione è più portabile. Se necessario, le applicazioni in esecuzione nell'ambiente flessibile possono essere eseguite su Google Kubernetes Engine o Compute Engine senza modifiche sostanziali.
Sviluppo locale
Nell'ambiente standard, in genere esegui l'applicazione localmente utilizzando
l'SDK App Engine. L'SDK gestisce l'esecuzione dell'applicazione ed emula i servizi App Engine. Nell'ambiente flessibile, l'SDK non viene più utilizzato per eseguire l'applicazione. Le applicazioni scritte per l'ambiente flessibile devono invece essere scritte come applicazioni web standard che possono essere eseguite ovunque. Come accennato, l'ambiente flessibile esegue semplicemente l'applicazione in un container Docker. Ciò significa che per testare l'applicazione localmente, devi semplicemente eseguire direttamente l'applicazione. Ad esempio, per eseguire un'applicazione Python utilizzando Django, devi eseguire python manage.py runserver.
Un'altra differenza fondamentale è che le applicazioni per ambienti flessibili in esecuzione localmente utilizzano i servizi effettivi della piattaforma Cloud, come Datastore. Utilizza un file YAML per eseguire test in locale e, se disponibile, usa emulatori.
Caratteristiche di scalabilità
Sebbene entrambi gli ambienti utilizzino l'infrastruttura di scalabilità automatica di App Engine, il modo in cui scalano è diverso. L'ambiente standard può scalare da zero a migliaia di istanze molto rapidamente. Al contrario, il modello flessibile deve avere almeno un'istanza in esecuzione per ogni versione attiva lo scale out in risposta al traffico può richiedere più tempo.
L'ambiente standard utilizza un algoritmo di scalabilità automatica progettato su misura. Flessibili utilizza l'ambiente Compute Engine Gestore della scalabilità automatica. Tieni presente che l'ambiente flessibile non supporta tutte le opzioni di scalabilità automatica disponibili per Compute Engine. App Engine rispetta le prenotazioni di VM Compute Engine che hai già in una regione e che corrispondono alla tua configurazione. Avere una prenotazione VM aumenta la probabilità di ricevere un'allocazione di risorse durante una carenza temporanea di risorse.
Gli sviluppatori dovrebbero testare il comportamento della loro applicazione in una serie di le condizioni di traffico. Ad esempio, devi verificare come risponde la scalabilità automatica quando un'applicazione vincolata alla CPU diventa vincolata all'I/O durante i periodi in cui le chiamate ai servizi remoti hanno una latenza elevata.
Controlli di integrità
L'ambiente standard non utilizza i controlli di integrità per determinare se per inviare traffico a un'istanza. L'ambiente flessibile consente agli sviluppatori di applicazioni scrivere i propri gestori del controllo di integrità che verranno utilizzati dal bilanciatore del carico per determinare se inviare o meno il traffico a un'istanza la riparazione automatica. Gli sviluppatori devono fare attenzione quando aggiungono la logica all'integrità controlli. Ad esempio, se il controllo di integrità effettua una chiamata a un servizio esterno un errore temporaneo del servizio può causare l'arresto di tutte le istanze non è integro e potrebbe causare un errore a cascata.
Eliminazione delle richieste in caso di sovraccarico
Le applicazioni possono ignorare le richieste in caso di sovraccarico nell'ambito di una strategia per evitare a cascata. Questa funzionalità è integrata nel livello di routing del traffico dell'ambiente standard. Consigliamo agli sviluppatori con QPS molto elevate nell'ambiente flessibile creano questa capacità per eliminare il sovraccarico, il traffico verso le loro applicazioni limitando il numero di richieste in parallelo.
Puoi verificare che la tua applicazione nell'ambiente flessibile non sia soggetta a di questo tipo di errore creando una versione con un limite al numero massimo di Compute Engine. Quindi aumenta costantemente il traffico finché le richieste non vengono eliminate. Devi assicurarti che la tua applicazione non non superi i controlli di integrità durante il sovraccarico.
Per Java, le app Java che utilizzano il runtime Jetty possono configurare il filtro Qualità del servizio per implementare il sovraccarico di drop. Puoi impostare l'offerta massima di richieste in parallelo gestite dalle app e per quanto tempo verranno messe in coda utilizzando questa funzione.
Dimensioni delle istanze
Le istanze dell'ambiente flessibile possono avere limiti di CPU e memoria superiori a quelli possibili con le istanze dell'ambiente standard. In questo modo, le istanze flessibili possono eseguire applicazioni che richiedono una maggiore quantità di memoria e CPU. Tuttavia, può aumentare la probabilità di bug di contemporaneità a causa di l'aumento dei thread all'interno di una singola istanza.
Gli sviluppatori possono accedere tramite SSH a un ambiente flessibile Istanza e ottenere un dump del thread per risolvere questo tipo di problema.
Ad esempio, se utilizzi il runtime Java, puoi eseguire quanto segue:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Timeout massimo della richiesta
Anche se il timeout delle richieste dell'ambiente standard varia in base al tipo di scalabilità selezionato, l'ambiente flessibile impone sempre un timeout di 60 minuti. Per evitare di lasciare le richieste aperte per l'intera durata di 60 minuti e di utilizzare potenzialmente tutti i thread sul server web:
Quando effettui chiamate a servizi esterni, specifica un timeout.
Implementare un filtro servlet per arrestare le richieste che richiedono un tempo inaccettabile ad esempio 60 secondi. Assicurati che la tua app possa tornare a uno stato coerente dopo se il filtro interrompe una richiesta.
Gestione dei thread
I runtime Java dell'ambiente standard precedenti a Java 8 potevano utilizzare solo thread creati utilizzando l'SDK dell'ambiente standard di App Engine. Gli sviluppatori che eseguono il porting di un'applicazione da un ambiente di runtime Java standard di prima generazione a un ambiente flessibile devono passare all'utilizzo di librerie di thread native. Le applicazioni che richiedono un numero molto elevato di thread possono è più efficiente con i pool di thread rispetto alla creazione esplicita di thread.
Migrazione del traffico
L'ambiente standard offre una funzionalità di migrazione del traffico che si sposta gradualmente a una nuova versione per ridurre al minimo i picchi di latenza. Consulta la sezione sulla migrazione del traffico assistenza per trovare modi per assicurati di evitare picchi di latenza quando passi il traffico a una nuova versione.
Errori a zona singola
Le applicazioni con ambiente standard sono monohome, il che significa che tutte le istanze dell'applicazione si trovano in un'unica zona di disponibilità. In caso di errore in quella zona, l'applicazione avvia nuove istanze in un'altra zona della stessa regione e il bilanciatore del carico instrada il traffico alle nuove istanze. Potrai un picco di latenza dovuto al caricamento delle richieste e uno svuotamento di Memcache.
Le applicazioni per ambienti flessibili utilizzano i gruppi di istanze gestite a livello di regione, il che significa che le istanze sono distribuite tra più zone di disponibilità all'interno di una regione. In caso di errore di una singola zona, il bilanciatore del carico interrompe il routing a quella zona. Se hai impostato la scalabilità automatica in modo da eseguire le istanze il più attivamente possibile, vedrai un breve periodo di sovraccarico prima che la scalabilità automatica crei altre istanze.
Confronti dei costi
Un confronto dei costi tra i carichi di lavoro eseguiti in ambienti standard e flessibili coinvolge molti fattori. Queste includono:
- Prezzo pagato per MCycle.
- Funzionalità della piattaforma CPU, che incidono sul lavoro eseguibile per MCycle
- Tempi di esecuzione delle istanze su ogni piattaforma.
- Costo dei deployment, che può variare a seconda della piattaforma e può essere e significativo se utilizzi il deployment continuo per la tua applicazione.
- Overhead di runtime.
Dovrai eseguire esperimenti per determinare il costo del tuo carico di lavoro su ogni piattaforma. In un ambiente flessibile, puoi utilizzare le richieste al secondo per core come sostituto dell'efficienza in termini di costi della tua applicazione quando esegui esperimenti per determinare se una modifica ha un impatto sui costi. L'ambiente standard non fornisce un simile meccanismo per ottenere metriche in tempo reale sull'efficienza in termini di costi della tua applicazione. Devi apportare una modifica e attendere il completamento del ciclo di fatturazione giornaliero.
Microservizi
L'ambiente standard consente l'autenticazione sicura tra le applicazioni utilizzando
X-Appengine-Inbound-Appid
l'intestazione della richiesta. L'ambiente flessibile non dispone di una funzionalità di questo tipo. La
l'approccio consigliato per l'autenticazione sicura tra le applicazioni è usare
OAuth.
Deployment
I deployment nell'ambiente standard sono generalmente più veloci di quelli nell'ambiente standard un ambiente flessibile. È più veloce eseguire l'upgrade di una versione esistente in un ambiente flessibile rispetto al deployment di una nuova versione, perché la programmazione di rete per una nuova versione è in genere la parte più lunga del deployment in un ambiente flessibile. Una strategia per eseguire rollback rapidi in un ambiente flessibile è mantenere una versione nota buona scalata a una singola istanza. Puoi quindi fare lo scale up e poi instradarvi tutto il traffico utilizzando la suddivisione del traffico.
Quando utilizzare l'ambiente flessibile
L'ambiente flessibile è pensato per essere complementare allo standard completamente gestito di Google Cloud. Se hai un'applicazione esistente in esecuzione nello standard di solito non è necessario eseguire la migrazione dell'intera applicazione un ambiente flessibile. Identifica invece le parti dell'applicazione che richiedono più CPU, più RAM, una libreria o un programma specializzato di terze parti oppure eseguire azioni che non sono possibili nell'ambiente standard. Una volta identificate queste parti dell'applicazione, crea piccoli servizi App Engine che utilizzano l'ambiente flessibile per gestire solo queste parti. Il servizio esistente in esecuzione nell'ambiente standard può chiamare gli altri servizi utilizzando HTTP, Cloud Tasks o Cloud Pub/Sub.
Ad esempio, se hai un'applicazione web esistente in esecuzione nel e vuoi aggiungere una nuova funzionalità per convertire i file in PDF, puoi scrivere un microservizio separato che viene eseguito nell'ambiente flessibile gestisce la conversione in PDF. Questo microservizio può essere un semplice programma che consiste in uno o due gestori di richieste. Questo microservizio può installare e utilizzare qualsiasi programma Linux disponibile per facilitare la conversione, ad esempio unoconv.
L'applicazione principale rimane nell'ambiente standard e può chiamarla microservizio direttamente tramite HTTP o se prevedi che la conversione richiederà da molto tempo, l'applicazione può utilizzare Cloud Tasks o Pub/Sub per mettere in coda le richieste.