Con microservizi si intende uno stile architetturale lo sviluppo di applicazioni. I microservizi consentono di eseguire scomposti in componenti indipendenti, ognuno dei quali ha una propria regno della 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 in modo corretto può raggiungere 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à molto adatte per un'applicazione basata su microservizi. Questa pagina illustra le best practice da utilizzare. quando esegui il deployment della tua applicazione come applicazione basata su microservizi su Google in 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 dispongono di un isolamento completo del codice, l'unico per eseguire il codice in questi servizi è tramite una chiamata HTTP, come come richiesta dell'utente o una chiamata API RESTful. Il codice di un servizio non può chiamare direttamente il codice di un altro servizio. È possibile eseguire il deployment del codice nei servizi in modo indipendente servizi diversi possono essere scritti in linguaggi diversi, come Python, Java, Go e PHP. Scalabilità automatica, bilanciamento del carico e tipo di istanza della macchina sono tutti e gestire i servizi in modo indipendente.
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 è la versione di pubblicazione predefinita, è possibile accedere direttamente a qualsiasi versione di cui è stato eseguito il deployment di un servizio di ogni servizio ha un proprio indirizzo. Questa struttura offre una miriade di possibilitá, tra cui test di verifica di una nuova versione, test A/B tra diverse versioni e operazioni di roll-forward e rollback semplificate. App Il framework del motore fornisce meccanismi per supportare la maggior parte di questi elementi. Analizzeremo questi meccanismi in maggiore dettaglio 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 le code di attività sono tutte risorse condivise tra i servizi in un progetto App Engine. Sebbene questa condivisione abbia alcuni vantaggi, per un'applicazione basata su microservizi, è importante mantenere e l'isolamento dei dati tra microservizi. Esistono modelli di architettura che limitare le condivisioni indesiderate. 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'utilizzare i progetti anziché i servizi e devi e bilanciare i compromessi a seconda della situazione. A meno che tu non abbia una specifica uno dei vantaggi offerti dall'utilizzo di più progetti, è meglio iniziare a utilizzare più servizi all'interno di un singolo progetto perché migliorerà e i costi amministrativi saranno ridotti al minimo. Naturalmente, puoi anche scegliere un approccio ibrido.
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 dati |
Cloud Datastore e Memcache sono condivisi tra servizi e versioni, tuttavia
spazi dei nomi
può essere utilizzato come pattern per sviluppatori 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 (insieme al servizio e alla versione di ogni progetto) ha , sebbene tutti i log di un determinato progetto possano 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, quindi la latenza quando si chiama un servizio da un altro tramite HTTP è 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 operatore | Un operatore ha la capacità di eseguire il deployment del codice, il rollback eseguire 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 | Utilizzo Google Cloud Trace puoi visualizzare una richiesta e le risultanti richieste di microservizi per i servizi nello stesso progetto di 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 all'interno della stessa organizzazione. |
Passaggi successivi
- Scopri come creare e assegnare un nome agli ambienti di sviluppo, test, QA, temporaneo e di produzione con microservizi in App Engine.
- Scopri le best practice per la progettazione di API in modo da comunicare 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.
- Comprendi 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.