Architettura dei microservizi su Google App Engine

I microservizi rappresentano uno stile architetturale per lo sviluppo di applicazioni. I microservizi consentono di scomporre le applicazioni di grandi dimensioni in parti indipendenti, ognuna delle quali avrà un proprio ambito di responsabilità. Per gestire una singola richiesta utente o API, un'applicazione basata su microservizi può coinvolgere molti microservizi interni per scrivere la sua risposta.

Un'applicazione basata su microservizi implementata correttamente può raggiungere i seguenti obiettivi:

  • Stabilire contratti solidi tra i vari microservizi.
  • Consentire cicli di deployment indipendenti, incluso il rollback.
  • Agevolare i test di release A/B in contemporanea nei sottosistemi.
  • Ridurre al minimo l'overhead di automazione dei test e controllo qualità.
  • Aumentare la chiarezza del logging e del monitoraggio.
  • Fornire una contabilizzazione dei costi dettagliata.
  • Aumentare la scalabilità e l'affidabilità complessive dell'applicazione.

Google App Engine offre una serie di funzionalità molto adatte per un'applicazione basata su microservizi. Questa pagina illustra le best practice da utilizzare quando esegui il deployment dell'applicazione come applicazione basata su microservizi su Google App Engine.

Servizi App Engine come microservizi

In un progetto App Engine, puoi eseguire il deployment di più microservizi come servizi distinti, precedentemente noti come moduli in App Engine. Questi servizi hanno un isolamento completo del codice. L'unico modo per eseguire codice in questi servizi è tramite una chiamata HTTP, ad esempio una richiesta utente o una chiamata all'API RESTful. Il codice in un servizio non può chiamare direttamente il codice in un altro servizio. Il codice può essere implementato nei servizi in modo indipendente e i diversi servizi possono essere scritti in linguaggi diversi, come Python, Java, Go e PHP. La scalabilità automatica, il bilanciamento del carico e i tipi di istanze macchina vengono gestiti in modo indipendente per i servizi.

Un progetto App Engine ottiene la separazione utilizzando i servizi.

Versioni all'interno dei servizi

Inoltre, ogni servizio può avere più versioni di cui viene eseguito il deployment contemporaneamente. Per ogni servizio, una di queste versioni è la versione di pubblicazione predefinita, anche se è possibile accedere direttamente a qualsiasi versione di un servizio di cui è stato eseguito il deployment, poiché ogni versione di ogni servizio ha il proprio indirizzo. Questa struttura offre una miriade di possibili , tra cui test di verifica di una nuova versione, test A/B tra versioni diverse e operazioni di roll-forward e rollback semplificate. Il framework App Engine fornisce meccanismi per la maggior parte di questi elementi. Analizzeremo questi meccanismi in maggiore dettaglio nelle sezioni successive.

Un progetto App Engine può avere servizi e versioni.

Isolamento dei servizi

Sebbene siano per lo più isolati, i servizi condividono alcune risorse di App Engine. Ad esempio, Cloud Datastore, Memcache e le code di attività sono tutte risorse condivise tra i servizi in un progetto App Engine. Sebbene questa condivisione abbia alcuni vantaggi, è importante per un'applicazione basata su microservizi mantenere l'isolamento del codice e degli dati tra i microservizi. Esistono pattern di architettura che aiutano a mitigare la condivisione indesiderata. Descriveremo questi pattern più avanti in questo articolo.

I progetti App Engine condividono i servizi.

Isolamento del progetto

Se non vuoi fare affidamento su questi pattern per ottenere l'isolamento e vuoi una applicazione più formale della separazione, puoi utilizzare più progetti App Engine. Esistono pro e contro nell'utilizzo di progetti anziché servizi e devi bilanciare i compromessi a seconda della tua situazione. A meno che tu non abbia un bisogno specifico di uno dei vantaggi offerti dall'utilizzo di più progetti, è meglio iniziare utilizzando più servizi all'interno di un singolo progetto, perché le prestazioni saranno migliori e il sovraccarico amministrativo verrà ridotto al minimo. Naturalmente, puoi anche scegliere un approccio ibrido dei due.

Confronto tra isolamento dei servizi e isolamento dei progetti

La tabella seguente offre un confronto tra l'utilizzo di più servizi e di più progetti in un'architettura di microservizi:

Più servizi Più progetti
Isolamento del codice Il codice di cui è stato eseguito il deployment è completamente indipendente tra servizi e versioni. Il codice di cui è stato eseguito il deployment è completamente indipendente tra i progetti, nonché tra i servizi e le versioni di ciascun progetto.
Isolamento dei dati Cloud Datastore e Memcache sono condivisi tra servizi e versioni, ma i spazi dei nomi possono essere utilizzati come pattern di sviluppatore per isolare i dati. Per l'isolamento della coda di attività, è possibile utilizzare una convenzione di denominazione delle code per gli sviluppatori, ad esempio user-service-queue-1. Cloud Datastore, Memcache e le code di attività sono completamente indipendenti tra i progetti.
Isolamento dei log Ogni servizio (e versione) ha log indipendenti, anche se possono essere visualizzati insieme. Ogni progetto (e servizio e versione di ogni progetto) ha log indipendenti, anche se tutti i log di un determinato progetto possono essere visualizzati insieme. I log di più progetti non possono essere visualizzati insieme.
Overhead delle prestazioni I servizi dello stesso progetto vengono di solito implementati nello stesso data center, pertanto la latenza nell'uso di HTTP per chiamare un servizio da un altro è molto bassa. I progetti potrebbero essere implementati in data center diversi, pertanto le latenze HTTP potrebbero essere più elevate, anche se comunque piuttosto basse perché la rete di Google è di livello mondiale.
Contabilità dei costi I costi per ora di istanza (CPU e memoria per l'esecuzione del codice) non sono separati per i servizi; tutte le ore di istanza per un intero progetto vengono raggruppate. I costi per progetti diversi sono suddivisi, il che rende molto facile vedere il costo dei diversi microservizi.
Autorizzazioni dell'operatore Un operatore ha la possibilità di eseguire il deployment del codice, eseguire il roll forward e il rollback delle versioni e visualizzare i log di tutti i servizi di un progetto. Non è possibile limitare l'accesso a servizi specifici. L'accesso dell'operatore può essere controllato separatamente in progetti distinti.
Monitoraggio delle richieste Con Google Cloud Trace, puoi visualizzare una richiesta e le richieste di microservizi risultanti per i servizi nello stesso progetto come una singola traccia composta. Questa funzionalità può contribuire a semplificare l'ottimizzazione del rendimento. Le chiamate di Cloud Trace possono essere visualizzate nei progetti Google Cloud se si trovano nella stessa organizzazione.

Passaggi successivi