Architettura Microservice – Comunicazione

Per la comunicazione interna tra microservices ci sono diverse scuole di pensiero!

In un mondo ideale, ogni singolo servizio dovrebbe essere indipendente da ogni altro, ma ovviamente solo in un mondo ideale. Se si rende necessaria l’iterazione tra microservices per soddisfare una singola richiesta, non siamo in presenza di un problema di protocollo, bensì  di un problema di architettura.  In questo caso non è importante quale tipo di comunicazione si sia scelta (HTTP, AMQP, messaggi asincroni ecc…), ma il tempo con il quale verrà soddisfatta la richiesta e soprattutto l’affidabilità dei singoli servizi.

Nel caso in cui sia necessario creare un meccanismo di comunicazione, quest’ultimo dovrebbe essere asincrono.

In un comunicazione asincrona (Async I/O) le chiamate non sono bloccanti per il processo ( o il thread) che le hanno effettuate. In questo modello di comunicazione, la chiamata non risulta bloccante fino alla ricezione di una risposta da parte del servizio destinatario, ma è libera di procedere nel normale flusso di esecuzione. Per poter intercettare la risposta da parte del processo destinazione, è possibile utilizzare callback, promise e streams.

Non  è però sempre possibile evitare l’utilizzo di operazioni sincrone: basti ad esempio pensare all’iterazione con un database, che deve avvenire all’interno delle ciclo richiesta-risposta.

La necessità di strutturare le comunicazioni in modalità asicrona, si basa sul principio tale per cui i microservices debbano essere indipendenti l’uno dall’altro e soprattutto dovrebbero funzionare anche se gli altri servizi fossero temporaneamente non disponibili.

Alla base della comunicazione tra servizi, c’è sicuramente la necessità di ottenere risposte nel piu’ breve tempo possibile. In questo scenario, il protocollo HTTP è sicuramente il metodo piu’ semplice, e forse più affidabile, possibile. Inoltre consente di essere impiegato sia in scenari sincroni, sia in scenari asincroni.

L’ HTTP  è un protocollo sincrono: a seguito di una richiesta fatta dal client, si attende la risposta.

Volendo implementare una soluzione asincrona, il thread del client potrebbe non attendere, eseguire altro codice, e gestire le operazioni solo alla ricezione della risposta da parte del server.

Una soluzione possibile per disaccopiare i servizi è quella di effettuare una ridondanza dei dati: in questo modo vengono replicati nei vari servizi, con l’evidente vantaggio di delegare la responsabilità ad ogni singolo contesto locale. Ad esempio utilizzando sistemi indipendenti SCS (self-contained system).

Ma come ridondare? Ad esempio, utilizzando processi di polling monitorando richieste RESTFul. L’utilizzo di un’architettura basata su protocollo HTTP consente di utilizzare meccanismi di caching, senza dover implementare nuove astrazioni.

Altri metodi fanno uso di sistemi di messaggistica come Akka o Erlang che consentono di semplificare le funzioni di scambio dati tra servizi.

Pubblicato da

Andrea Merlin

Laureato in informatica, diversi corsi di specializzazione legati allo Sviluppo Software e alla Computer forensics. Appassionato di nuove tecnologie, amo la programmazione, la Business Intelligence e tematiche legate alla Privacy.Sempre alla ricerca di nuove idee, stimoli … e progetti da seguire!Amo trascorrere il tempo libero in Val Borbera, un piccolo angolo del Piemonte, in provincia di Alessandria.