Questa guida fornisce un'introduzione all'ambiente flessibile per coloro hanno familiarità con l'ambiente standard. Spiega le somiglianze e le differenze chiave tra gli ambienti e fornisce anche un'architettura generale per le applicazioni che utilizzano entrambi gli ambienti.
Per una mappatura dei servizi disponibili nell'ambiente standard rispetto ai relativi analoghi nell'ambiente flessibile, vedi Migrazione dei servizi dall'ambiente standard all'ambiente flessibile.
Somiglianze e differenze principali
Entrambi gli ambienti offrono le funzionalità di deployment, gestione e scalabilità di App Engine dell'infrastruttura. Le differenze principali sono il modo in cui l'ambiente esegue il modo in cui l'applicazione accede a servizi esterni, il modo in cui in locale e sulla scalabilità della tua applicazione. 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 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 Compute Engine tipo di macchina per le tue istanze, in modo che l'applicazione abbia accesso di memoria e CPU.
Accesso a servizi esterni
Nell'ambiente standard, l'applicazione in genere accede a servizi come come Datastore tramite le API google.appengine integrate. Tuttavia, nell'ambiente flessibile, queste API non sono più disponibili. Utilizza invece Librerie client di Google Cloud. Questi client funzionano ovunque, il che significa che la tua applicazione è più portabile. Se necessario, le applicazioni eseguite nell'ambiente flessibile solitamente possono essere eseguite Google Kubernetes Engine oppure Compute Engine senza modifiche significative.
Sviluppo locale
Nell'ambiente standard, in genere esegui l'applicazione in locale utilizzando
con l'SDK di App Engine. L'SDK gestisce l'esecuzione dell'applicazione ed emula il
dai servizi App Engine. Nell'ambiente flessibile, l'SDK non è più utilizzato
per eseguire l'applicazione. Le applicazioni scritte per l'ambiente flessibile
devono essere scritte come applicazioni web standard che possono essere eseguite ovunque. Come
l'ambiente flessibile esegue semplicemente l'applicazione
containerizzato. Ciò significa che per testare l'applicazione in locale, è sufficiente eseguire
un'applicazione. Ad esempio, per eseguire un'applicazione Python utilizzando Django,
eseguirebbe semplicemente python manage.py runserver.
Un'altra differenza fondamentale è che le applicazioni con ambiente flessibile vengono eseguite localmente utilizzare servizi 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 fino a migliaia di istanze in tempi rapidissimi. 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 e supportare tutte le opzioni di scalabilità automatica disponibili in Compute Engine. App Engine rispetta tutte le prenotazioni di VM di Compute Engine in una regione corrispondente alla tua configurazione. Avere una VM aumenta la probabilità che riceverai un'allocazione delle risorse durante un temporanea carenza di risorse.
Gli sviluppatori dovrebbero testare il comportamento della loro applicazione in una serie di conditions. Ad esempio, devi verificare come risponde la scalabilità automatica quando L'applicazione legata alla CPU diventa I/O-bound durante i periodi in cui le chiamate al server 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. Dovresti assicurati che l'applicazione non superi i controlli di integrità durante il sovraccarico.
Per Java, le app Java che utilizzano il Il runtime Jetty può configurare Filtro qualità del servizio per implementare il sovraccarico. Puoi impostare l'offerta massima di richieste in parallelo gestite dalle app e per quanto tempo verranno messe in coda utilizzando questa funzione.
Dimensioni istanza
Le istanze di ambiente flessibile possono avere CPU e memoria più elevate rispetto a quanto consentito dalle istanze dell'ambiente standard. Ciò consente Istanze flessibili per l'esecuzione di applicazioni che offrono più memoria e CPU in modo intensivo. Tuttavia, può aumentare la probabilità di bug di contemporaneità dovuti a: 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 questo comando:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Timeout massimo della richiesta
Sebbene l'ambiente standard il timeout della richiesta 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 tutti i 60 minuti e di consumare potenzialmente tutti i thread sul server web:
Specifica un timeout quando effettui chiamate a servizi esterni.
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 prima di Java 8 potevano usare solo thread che vengono create utilizzando l'SDK dell'ambiente standard di App Engine. Sviluppatori che portano un'applicazione da una prima generazione di Java dal runtime dell'ambiente standard all'ambiente flessibile deve passare all'utilizzo librerie di thread. 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 nell'ambiente standard sono in casa singola, il che significa che tutte le istanze dell'applicazione risiedono in un'unica zona di disponibilità. In caso di errore in quella zona, l'applicazione avvia nuove istanze in una zona diversa nella 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 in ambiente flessibile usano istanza gestita a livello di regione Gruppi, il che significa che le istanze sono distribuite tra più zone di disponibilità all'interno 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 per eseguire le istanze vedrai un breve periodo di sovraccarico prima della scalabilità automatica crea altre istanze.
Confronti dei costi
Nel confronto dei costi tra carichi di lavoro in esecuzione sono coinvolti molti fattori in ambienti standard e flessibili. 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 carico di lavoro su ogni completamente gestita. In un ambiente flessibile, puoi utilizzare QPS per core come proxy 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 questo meccanismo per ottenere metriche in tempo reale sull'efficienza in termini di costi un'applicazione. Devi apportare una modifica e attendere che il ciclo di fatturazione giornaliero completato.
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 fare lo scale up di una versione esistente in modalità rispetto al deployment di una nuova versione, perché la programmazione di rete per di solito è il polo lungo nel deployment di un ambiente flessibile. Uno. la strategia per eseguire rapidi rollback in un ambiente flessibile è mantenere nota buona, fatto lo scale down 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 un piccolo App Engine e servizi che usano l'ambiente flessibile per gestire solo quelle parti. Il tuo 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, come 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.