Con microservizi si fa riferimento a 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à il proprio ambito di responsabilità. Per gestire una singola richiesta utente o API, un'applicazione basata su microservizi può chiamare molti microservizi interni per scrivere la sua risposta.
Un'applicazione basata su microservizi implementata in modo corretto 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.
- Riduci al minimo l'overhead di automazione dei test e garanzia di 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à adatte a un'applicazione basata su microservizi. Questa pagina illustra le best practice da utilizzare durante il deployment della tua applicazione come applicazione basata su microservizi in Google App Engine.
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 hanno l'isolamento completo del codice. L'unico modo per eseguire il codice in questi servizi è tramite una chiamata HTTP, come una richiesta dell'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 servizi diversi possono essere scritti in linguaggi diversi, come Python, Java, Go e PHP. Tutti i tipi di scalabilità automatica, bilanciamento del carico e istanze macchina sono gestiti in modo indipendente per i servizi.
Versioni all'interno dei servizi
Inoltre, in ogni servizio è possibile eseguire il deployment di più versions contemporaneamente. Per ogni servizio, una di queste è la versione di servizio predefinita, sebbene sia 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 offre una miriade di possibilità, tra cui il test del fumo di una nuova versione, i test A/B tra diverse versioni e operazioni semplificate di rollback e rollback. Il framework di App Engine fornisce meccanismi per supportare la maggior parte di questi elementi. Tratteremo questi meccanismi in maggiore dettaglio nelle prossime sezioni.
Isolamento dei servizi
Sebbene 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 che un'applicazione basata su microservizi mantenga l'isolamento di codice e dati tra i microservizi. Alcuni modelli di architettura aiutano a mitigare la condivisione indesiderata. Descriveremo questi modelli più avanti in questo articolo.
Isolamento dei progetti
Se non vuoi fare affidamento su questi pattern per raggiungere l'isolamento e vuoi un'applicazione più formale della separazione, puoi utilizzare più progetti App Engine. L'uso di progetti anziché servizi presenta pro e contro ed è necessario bilanciare i compromessi a seconda della situazione. A meno che tu non abbia un'esigenza specifica per uno dei vantaggi offerti dall'utilizzo di più progetti, ti consigliamo di iniziare con l'utilizzo di più servizi all'interno di un singolo progetto perché le prestazioni saranno migliori e l'overhead amministrativo sarà ridotto al minimo. Naturalmente, puoi anche scegliere un approccio ibrido dei due approcci.
Confronto tra isolamento di servizi e isolamento di progetti
La tabella seguente mette a confronto l'uso 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 e tra i servizi e le versioni di ogni progetto. |
| Isolamento dati |
Cloud Datastore e Memcache sono condivisi tra servizi e versioni, tuttavia è possibile utilizzare gli spazi dei nomi come pattern per sviluppatori per isolare i dati.
Per l'isolamento delle code di attività, è possibile utilizzare una convenzione di sviluppo dei nomi di coda, 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 (insieme al servizio e alla versione di ogni 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 delle prestazioni | Il deployment dei servizi dello stesso progetto viene eseguito nello stesso data center, perciò la latenza quando si chiama un servizio da un altro tramite HTTP è molto bassa. | Il deployment dei progetti potrebbe avvenire in data center diversi, quindi le latenze HTTP potrebbero essere superiori, anche se ancora piuttosto basse, perché la rete di Google è di altissimo livello. |
| Contabilità dei costi | I costi per le 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 insieme. | I costi di progetti diversi sono suddivisi in modo che sia molto facile vedere 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. |
| Tracciamento delle richieste | Con Google Cloud Trace puoi visualizzare una richiesta e le richieste di microservizi risultanti per i servizi nello stesso progetto come un'unica traccia composta. Questa funzionalità può aiutare a semplificare l'ottimizzazione delle prestazioni. | Le chiamate Cloud Trace possono essere visualizzate nei 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 un'applicazione con microservizi.
- Scopri se i microservizi sono ideali per la tua situazione. Nel suo blog personale, Preston Holmes, Solution Architect di Google, ha pubblicato un post su alcuni degli svantaggi che vede nei microservizi.