Viaggio nell’universo dei microservizi: come e perché rivoluzionano i cardini dell’informatica?

Di solito inizio a studiare una nuova tecnologia digitando nella barra di ricerca “How to start with “, seguito dall’argomento dello studio. Tentai il medesimo approccio scrivendo la temeraria frase: “How to start with microservice architecture“.

Pagine zeppe di nuove nozioni si pararono di fronte a me!

Approfondendo le singole voci rimasi però colpito dal significato nascosto dietro alcune, le quali riscrivono i cardini dell’informatica passata, in particolare in ambito consistenza del dato.

Vorrei condividere con voi i traguardi del mio studio ripercorrendo insieme la mia personale corsa alla conoscenza della consistenza in ambito microservizi.

Ai posti… 3, 2, 1… via!

Evito di ribadire quanto “meravigliosi”siano i microservizi e i pro di utilizzare una siffatta architettura, andiamo dritti al sodo.

API gateway, dove ci porta?

L‘API gateway è il modulo software che, come il nome suggerisce, agisce da punto di entrata nel sistema a microservizi: ogni client che utilizza il sistema utilizza un protocollo diverso per comunicare e l’API gateway uniforma la risposta per tutti.

Interessante, ma andiamo oltre per il momento.

L’API gateway ha il compito di scovare la location e gli indirizzi dei microservizi, i quali cambiano perché cambia il numero di istanze e disponibilità degli stessi.

Va bene, comprendo questa necessità, ma soffermiamoci un attimo su un aspetto.

Fin dall’inizio della mia lettura l’API gateway sembrava somigliare a un modulo centralizzato che inoltra richieste a microservizi, valida la richiesta dell’utente e aggrega i dati. E’ davvero questo il suo compito?

No, è più complicato! Chi lo avrebbe immaginato?!

Infatti, in un sito di e-commerce, un “conto” è incrociare nell’API gateway i dati provenienti dal micro servizio che si occupa della gestione dell’anagrafica con quello che si occupa della gestione degli ordini di un utente; un altro è gestire tutta la logica di business relativa a un ordine e quindi lasciare al gateway il compito di ricavare il prezzo di un prodotto, aggiornare il magazzino e aggiungere un ordine.

Non è forse il caso di creare un micro servizio che appositamente aggreghi e finalizzi gli ordini?

Sì, colto nel segno!

In linea di massima le operazioni non associate a logica di business possono essere delegate all’API gateway, le restanti no. Ecco perché l’API gateway può aggregare dati non di interesse per il business e gestire autenticazione, accesso per ruoli e sicurezza.

Andiamo avanti… Anzi, un attimo!

Il medesimo API gateway può essere utilizzato in sistemi diversi? In fin dei conti, tipo di risposta, autenticazione, ruoli, sicurezza trasmissione sono caratteristiche di tutti i sistemi software!

Appunto per il futuro: argomento da riprendere!

Aggregatori

Ci stiamo avvicinando…

Cosa sono gli aggregatori in ambito microservizi? L’aggregatore è un componente che, come la parola ci suggerisce, aggrega i dati. Nei casi più semplici un aggregatore è un micro servizio (per es. il micro servizio degli ordini aggregherà gli ordini ai prezzi di quest’ultimi).

Per fare ciò l’aggregatore dovrebbe richiedere a ogni micro servizio i dati necessari e magari salvarli localmente nel proprio DB, così da averne rapida disponibilità. Duplicazione dei dati si, ma è piuttosto ragionevole come compromesso.

Non è questo il nostro punto di arrivo: datemi un attimo per illustrare come alcuni microservizi possono aggregare efficientemente i dati.

Fatto ciò saremo in dirittura di arrivo!

Esempio

Classico sistema di e-commerce: abbiamo l’API gateway e due microservizi, il micro servizio Catalogo e il micro servizio Ordini. Ordini gestisce, appunto, gli ordini: necessita quindi di sapere il prezzo di quest’ultimi, gestiti dal micro servizio Catalogo, considerando che i prezzi possono cambiare continuamente. Ci sono varie strade per realizzare in modo efficiente una siffatta aggregazione e per brevità vi illustro una delle più efficienti.

Il micro servizio Ordini crea una tabella di sola lettura con i prezzi degli articoli e li utilizzerà per gestire gli ordini, così facendo aggregherà i dati. Fin qui abbiamo un modo interessante di gestire la consistenza e aggregazione del dato in un ambiente a microservizi.

Ho sempre trovato interessante in ambito informatico capire come un sistema reagisce al cambiamento e alle sollecitazioni.

Dato che il prezzo degli articoli può cambiare in ogni momento, come è gestita la consistenza del dato in questo caso?

Risposta:

Il micro servizio Catalogo, nel momento in cui il prezzo di un articolo cambia, emette un evento che viene inserito in una coda, dove è sottoscritto il micro servizio degli ordini. Quest’ultimo preleva il messaggio e lo utilizza per aggiornare la sua tabella, di sola lettura, che tiene conto del prezzo degli ordini. In questo modo ogni ordine avrà il prezzo aggiornato.

Il prezzo dell’articolo 11 passa a 70€, attraverso la gestione dell’evento la modifica viene inoltrata al secondo micro servizio.

Eventi, una diversa consistenza

Siamo vicinissimi alla mia conclusione, scopriamo insieme il punto focale dell’articolo!

Tutto parte dagli eventi appena accennati.

Gli eventi, in un sistema a microservizi, sono molto importanti. La consistenza del dato, come sappiamo, è qualcosa di delicato e labile, ma la consistenza degli eventi NO!

Mi spiego.

Le tabelle di un DB SQL o i documenti o record di un DB NoSQL possono non essere sincronizzate tra loro in un sistema a microservizi, quindi avremo il micro servizio degli ordini che non ha nella sua tabella il prezzo aggiornato del catalogo, ma lo storico degli eventi SI!!

Se, come nel caso seguente, venisse inserito nel sistema uno storage, gestito magari da un micro servizio che registra gli eventi accaduti in un sistema software, avremmo lo stato del DB inconsistente ma lo stato degli eventi sul sistema consistente.

Lavorare con i microservizi significa convivere e gestire gli errori, ma gli errori sono gestibili quando si ha lo storico completo di quello che è accaduto in un sistema e la lista degli eventi che hanno modificato le entità memorizzate nel DB di un sistema.

L’Event Storage in immagine, infatti, è una memoria persistente di eventi che agisce da broker dispensando eventi attraverso messaggi.

Qualsiasi evento, inserimento ordine e/o modifica prezzo, è registrato all’interno centralmente.

In ogni momento è possibile risalire alla stato corrente di un entità nel sistema.

Mica male!

Taglio del traguardo

Attraverso una configurazione del genere è possibile gestire qualsiasi tipo di fallimento o errore! E’ possibile comprendere quando è stato aggiornato un prezzo, verificare se l’aggiornamento è stato effettuato a livello di un dato micro servizio o meno, è possibile comprendere quando è stato aggiunto un ordine o risalire al prezzo utile con cui registrare quell’ordine.

In aggiunta, è possibile salvare in modo periodico lo stato dell’intero sistema software per un rapido accesso, quindi avere in qualsiasi momento lo stato corrente di un’entità, prima ancora che vengano salvati i dati caratteristici in un DB.

Tutto questo registrando gli eventi occorsi in un sistema.

In estrema sintesi, a fine corsa abbiamo compreso che: fin tanto che i microservizi gestiscono il proprio DB, sono sottoscritti a un sistema più o meno centralizzato che dispensa eventi, qualsiasi sollecitazione al sistema può essere affrontata senza problemi perché il sistema è consistente. Questo non lo si deduce dallo stato delle entità conservate da un application server, dal DB o cache, ma dalla stato degli eventi.

La corsa si conclude: i microservizi ci suggeriscono nuove forme di consistenza di un sistema software, in cui è il corso degli eventi e non la struttura di un singolo DB SQL o NoSQL a guidare la consistenza.