Quando progetti un'applicazione web basata su un'architettura di microservizi, decidi come suddividere le funzionalità dell'applicazione in microservizi e come questi microservizi vengono chiamati come parte dell'applicazione. Per i servizi a lunga esecuzione, ti consigliamo di utilizzare le chiamate di servizio asincrone. Questa architettura di riferimento illustra come eseguire il deployment di un'applicazione containerizzata che richiama processi a lunga esecuzione in modo asincrono.
Questo documento sull'architettura di riferimento è destinato a sviluppatori e architetti che vogliono implementare microservizi in modo asincrono utilizzando tecnologie moderne, tra cui Google Kubernetes Engine (GKE) e Pub/Sub. Il documento presuppone che tu conosca i microservizi in generale e con Pub/Sub e GKE su Google Cloud.
Architettura
Il seguente diagramma illustra uno scenario di esempio in cui un'applicazione genera immagini in miniatura. La generazione di miniature può richiedere un gran numero di risorse e del tempo.
Figura 1. Architettura originale per l'elaborazione delle immagini basata sull'utilizzo delle VM.
Nel diagramma precedente, l'applicazione riceve file immagine dai client e quindi genera miniature. In questa architettura, l'applicazione viene implementata utilizzando istanze di macchine virtuali (VM) in Compute Engine e utilizzando l'archiviazione file di backend in Cloud Storage. L'applicazione archivia i metadati tramite Cloud Storage. Cloud Load Balancing distribuisce le richieste su più VM.
Per ridurre il sovraccarico operativo per la gestione delle VM, esegui la migrazione di questo sistema a una nuova architettura che non utilizza VM.
Il seguente diagramma mostra come è possibile implementare questo flusso utilizzando servizi gestiti che utilizzano notifiche e microservizi per implementare chiamate asincrone tra i componenti del sistema.
Figura 2. Nuova architettura per l'elaborazione delle immagini basata sull'uso di container e messaggistica asincrona.
Nella nuova architettura, il client invia un'immagine all'applicazione, che poi la carica in Cloud Storage. Le notifiche Pub/Sub inseriscono un messaggio nella coda dei messaggi Pub/Sub. Il messaggio chiama un microservizio che viene eseguito su GKE. Il microservizio recupera l'immagine da Cloud Storage, genera una miniatura e carica la miniatura in Cloud Storage.
Note sul layout
Le seguenti linee guida possono aiutarti a sviluppare un'architettura che soddisfi i requisiti della tua organizzazione in termini di efficienza operativa e prestazioni.
Efficienza operativa
La nuova architettura offre i seguenti vantaggi:
Scalabilità indipendente: nell'architettura originale, l'applicazione in esecuzione su Compute Engine risponde a due attività principali. Un'attività consiste nel ricevere file, l'altra nel generare una miniatura dall'immagine originale. La ricezione dei file caricati richiede una larghezza di banda di rete e la generazione delle miniature richiede un utilizzo intensivo della CPU. Le istanze di Compute Engine potrebbero esaurire le risorse della CPU per generare immagini, ma avere comunque risorse di rete sufficienti per ricevere i file. Nella nuova architettura, queste attività sono condivise da Cloud Storage e GKE, rendendole scalabili in modo indipendente.
Aggiungere nuove funzionalità facili: nell'architettura originale, se vuoi aggiungere funzionalità, devi eseguirne il deployment sulle stesse istanze di Compute Engine. Nella nuova architettura puoi sviluppare un'applicazione e aggiungerla in modo indipendente, ad esempio puoi aggiungere un'applicazione mittente di posta per ricevere una notifica quando viene generata una nuova miniatura. Pub/Sub può connettersi all'applicazione di generazione delle miniature e all'applicazione mittente di posta in modo asincrono senza modificare il codice originale eseguito su GKE.
Accoppiamento ridotto: nell'architettura originale, un problema comune è l'accoppiamento temporale. Se un server di inoltro della posta non è disponibile e l'applicazione tenta di inviare una notifica, la notifica ha esito negativo. Questi processi sono caratterizzati dall'alto accoppiamento e un client potrebbe non ottenere una risposta positiva dall'applicazione. Nella nuova architettura, il client ottiene una risposta positiva perché la generazione di una miniatura e l'invio di una notifica sono a basso accoppiamento.
Questa nuova architettura presenta i seguenti svantaggi:
Ulteriore sforzo per modernizzare l'applicazione: la containerizzazione di un'applicazione richiede tempo e fatica. La nuova architettura utilizza più servizi e richiede un approccio diverso all'osservabilità, che include modifiche al monitoraggio dell'applicazione, al processo di deployment e alla gestione delle risorse.
Requisito per gestire la duplicazione sul lato applicazione: Pub/Sub garantisce la consegna dei messaggi "at-least-once", il che significa che potrebbero essere inviati messaggi duplicati. L'applicazione deve gestire questa possibilità.
Prestazioni
La nuova architettura può garantire un utilizzo efficiente delle risorse: nell'architettura originale, lo scale out delle istanze di Compute Engine consuma più risorse per eseguire i sistemi operativi. Con GKE, puoi utilizzare in modo efficiente risorse server che eseguono più container su pochi server (bin packing). Puoi fare lo scale out e lo scale in rapidamente dei container, in modo che la nuova architettura sia in grado di gestire brevi burst di carichi elevati e di scalare rapidamente al termine delle attività.
Deployment
Per eseguire il deployment di un'applicazione di esempio che implementa questa architettura, consulta Eseguire il deployment di microservizi che utilizzano Pub/Sub e GKE.
Passaggi successivi
- Leggi ulteriori informazioni su DevOps e scopri di più sulle funzionalità di Architettura correlate a questa architettura di riferimento.
- Esegui il controllo rapido di DevOps per comprendere la tua posizione rispetto al resto del settore.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.