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 di un servizio non può chiamare direttamente il codice di 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.
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.
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.
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 namespaces 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. |
| Richiedi il monitoraggio | 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
- Scopri come creare e assegnare un nome agli ambienti di sviluppo, test, QA, gestione temporanea e di produzione con microservizi in App Engine.
- Scopri le best practice per progettare API per la comunicazione tra microservizi.
- Scopri le best practice per il rendimento 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. Sul suo blog personale, il Solution Architect di Google Preston Holmes ha pubblicato un post su alcuni degli svantaggi che vede nei microservizi.