I microservizi sono uno stile di architettura per lo sviluppo delle applicazioni. I microservizi consentono di scomporre un'applicazione di grandi dimensioni in parti indipendenti, ciascuna delle quali ha un proprio regno di responsabilità. Per gestire una singola richiesta utente o API, un'applicazione basata su microservizi può chiamare molti microservizi interni per comporre la sua risposta.
Un'applicazione basata su microservizi implementata correttamente può raggiungere i seguenti obiettivi:
- Definire contratti solidi tra i vari microservizi.
- Consenti cicli di deployment indipendenti, incluso il rollback.
- Facilitare i test delle release A/B in parallelo sui sottosistemi.
- Riduci al minimo l'overhead per l'automazione dei test e il controllo qualità.
- Migliora la chiarezza del logging e del monitoraggio.
- Fornire una contabilità dei costi granulare.
- Aumentare la scalabilità e l'affidabilità complessive dell'applicazione.
Google App Engine offre una serie di funzionalità particolarmente adatte a un'applicazione basata su microservizi. Questa pagina descrive le best practice da utilizzare per eseguire il deployment dell'applicazione come applicazione basata su microservizi in Google App Engine.
I servizi App Engine come microservizi
In un progetto App Engine, puoi eseguire il deployment di più microservizi come servizi separati, precedentemente noti come moduli in App Engine. Questi servizi dispongono di un isolamento completo del codice. L'unico modo per eseguire il codice in questi servizi è tramite una chiamata HTTP, come una richiesta utente o una chiamata API RESTful. Il codice in un servizio non può chiamare direttamente il codice in un altro. È possibile eseguire il deployment del codice nei servizi in modo indipendente e è possibile scrivere diversi servizi in linguaggi diversi, come Python, Java, Go e PHP. Scalabilità automatica, bilanciamento del carico e tipi di istanze delle macchine sono gestiti in modo indipendente per i servizi.
Versioni all'interno dei servizi
Inoltre, ogni servizio può avere più versions di cui è stato eseguito il deployment contemporaneamente. Per ogni servizio, una di queste versioni è quella di pubblicazione predefinita, anche se è possibile accedere direttamente a qualsiasi versione di cui è stato eseguito il deployment di un servizio poiché ogni versione di ciascun servizio ha un proprio indirizzo. Questa struttura apre una miriade di possibilità, tra cui test del fumo di una nuova versione, test A/B tra versioni diverse e operazioni semplificate di roll-forward e rollback. Il framework App Engine fornisce meccanismi per la maggior parte di questi elementi. Parleremo di questi meccanismi più dettagliatamente nelle prossime sezioni.
Isolamento dei servizi
Sebbene siano per lo più isolati, i servizi condividono alcune risorse di App Engine. Ad esempio, Cloud Datastore, Memcache e code di attività sono tutte risorse condivise tra i servizi in un progetto App Engine. Sebbene questa condivisione offra alcuni vantaggi, è importante che un'applicazione basata su microservizi mantenga l'isolamento del codice e dei dati tra i microservizi. Esistono modelli di architettura che aiutano a ridurre le condivisioni indesiderate. Descriveremo questi modelli più avanti in questo articolo.
Isolamento dei progetti
Se non vuoi fare affidamento su questi pattern per ottenere l'isolamento e vuoi un'applicazione più formale della separazione, puoi utilizzare più progetti App Engine. L'utilizzo di progetti anziché dei servizi comporta vantaggi e svantaggi e devi bilanciare i compromessi a seconda della situazione. A meno che tu non abbia esigenze specifiche di uno dei vantaggi offerti dall'utilizzo di più progetti, è preferibile 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 tra i due approcci.
Confronto tra isolamento dei servizi e dei progetti
La seguente tabella 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 i servizi e le versioni. | Il codice di cui è stato eseguito il deployment è completamente indipendente tra i progetti e tra i servizi e le versioni di ogni progetto. |
| Isolamento dei dati |
Cloud Datastore e Memcache sono condivisi tra i servizi e le versioni, tuttavia gli spazi dei nomi possono essere utilizzati come pattern di sviluppo per isolare i dati.
Per l'isolamento delle code di attività, è possibile utilizzare una convenzione per gli sviluppatori relativa ai nomi delle code, ad esempio user-service-queue-1.
|
Le code di Cloud Datastore, Memcache e di attività sono completamente indipendenti tra i progetti. |
| Isolamento dei log | Ogni servizio (e versione) dispone di log indipendenti, che però possono essere visualizzati insieme. | Ogni progetto (nonché servizio e versione di ciascun progetto) dispone di 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 per le prestazioni | Il deployment dei servizi dello stesso progetto viene eseguito nello stesso data center, pertanto la latenza nelle chiamate di un servizio dall'altro tramite HTTP è molto bassa. | Il deployment dei progetti potrebbe essere eseguito in data center diversi, quindi le latenze HTTP potrebbero essere più elevate, anche se comunque piuttosto basse, perché la rete di Google è di altissimo livello. |
| Contabilità dei costi | I costi per ore istanza (la CPU e la memoria per l'esecuzione del codice) non sono separati per i servizi; tutte le ore istanza per un intero progetto sono raggruppate. | I costi per progetti diversi sono suddivisi, in modo da poter vedere molto facilmente il costo dei vari microservizi. |
| Autorizzazioni operatore | Un operatore ha la possibilità di eseguire il deployment del codice, eseguire il rollback e il rollback delle versioni e visualizzare i log per tutti i servizi di un progetto. Non è possibile limitare l'accesso a servizi specifici. | L'accesso dell'operatore può essere controllato separatamente in progetti separati. |
| Richiedi tracciamento | Con Google Cloud Trace, puoi visualizzare una richiesta e le richieste di microservizi risultanti per i servizi nello stesso progetto di una singola traccia composta. Questa funzionalità può aiutare a semplificare l'ottimizzazione delle prestazioni. | Le chiamate di Cloud Trace possono essere visualizzate in tutti i progetti Google Cloud se si trovano all'interno della stessa organizzazione. |
Passaggi successivi
- Scopri come creare e denominare ambienti di sviluppo, test, qa, gestione temporanea e produzione con microservizi in App Engine.
- Scopri le best practice per la progettazione di API per la comunicazione tra microservizi.
- Scopri le best practice per le prestazioni dei microservizi.
- Scopri come eseguire la migrazione di un'applicazione monolitica esistente a una con microservizi.
- Scopri se i microservizi sono ideali per la tua situazione. Sul suo blog personale, il Solution Architect di Google Preston Holmes ha pubblicato un post su alcuni degli inconvenienti che vede nei microservizi.