Microservizi si riferisce 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à 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 in modo corretto può raggiungere i seguenti obiettivi:
- Definisci 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à adatte a un'applicazione basata sui microservizi. Questa pagina descrive le best practice da utilizzare quando esegui il deployment della tua 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 separati, precedentemente noti come moduli in App Engine. Questi servizi hanno un isolamento completo del codice; l'unico modo per eseguire il codice in questi servizi è tramite una chiamata HTTP, ad esempio una richiesta utente o una chiamata 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 sono tutti gestiti in modo indipendente per i servizi.
Versioni all'interno dei servizi
Inoltre, ogni servizio può avere più versioni di cui è stato 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, in quanto ogni versione di ogni servizio ha il proprio indirizzo. Questa struttura offre una miriade di possibilità, tra cui il test smoke di una nuova versione, il test A/B tra versioni diverse e operazioni di roll forward e rollback semplificate. Il framework App Engine fornisce meccanismi per assistere nella maggior parte di questi elementi. Analizzeremo questi meccanismi in modo più dettagliato nelle sezioni successive.
Isolamento dei servizi
Sebbene per lo più isolati, i servizi condividono alcune risorse di App Engine. Ad esempio, Cloud Datastore, Memcache e Task Queues 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 del codice e dei 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 separazione più formale, puoi utilizzare più progetti App Engine. L'utilizzo dei progetti anziché dei servizi presenta vantaggi e svantaggi e devi valutare i compromessi in base alla tua situazione. A meno che tu non abbia un'esigenza specifica per 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 sarà ridotto al minimo. Naturalmente, puoi anche scegliere una combinazione dei due approcci.
Confronto tra l'isolamento dei servizi e l'isolamento dei progetti
La tabella seguente fornisce un confronto tra l'utilizzo di più servizi e 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 ciascun progetto. |
| Isolamento dei dati |
Cloud Datastore e Memcache sono condivisi tra servizi e versioni, ma
i namespace
possono essere utilizzati come pattern per sviluppatori per isolare i dati.
Per l'isolamento della coda di attività, è possibile utilizzare una convenzione di denominazione degli sviluppatori per le code, ad esempio user-service-queue-1.
|
Cloud Datastore, Memcache e code di attività sono completamente indipendenti tra i progetti. |
| Isolamento dei log | Ogni servizio (e versione) ha log indipendenti, anche se possono essere 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 implementati nello stesso data center, quindi la latenza nella chiamata di un servizio da un altro tramite HTTP è molto bassa. | I progetti potrebbero essere implementati in data center diversi, quindi 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 le ore 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 sono raggruppate. | I costi per i diversi progetti sono suddivisi, il che rende molto facile visualizzare il costo dei diversi microservizi. |
| Autorizzazioni operatore | Un operatore ha la possibilità di eseguire il deployment del codice, eseguire il rollback e l'avanzamento 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 su progetti distinti. |
| Richiedi tracciamento | Utilizzando 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ò aiutarti a semplificare l'ottimizzazione del rendimento. | Le chiamate Cloud Trace possono essere visualizzate nei progetti Google Cloud se si trovano nella stessa organizzazione. |
Passaggi successivi
- Scopri come creare e denominare ambienti di sviluppo, test, controllo qualità, gestione temporanea e di 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.
- Valuta se i microservizi sono la soluzione ideale per la tua situazione. Nel suo blog personale, Preston Holmes, Google Solution Architect, ha pubblicato un post su alcuni degli svantaggi che vede nei microservizi.