Javascript e Promise

Con Javascript è possibile utilizzare il concetto di Promise, un particolare costrutto che consente di gestire i processi asincroni. Sono disponibili a partire da ECMAScript 2015, e permettono di scrivere codice semplice e quindi mantenibile. Fino a qualche anno fa, l’utilizzo delle promise era possibile solo utilizzando alcune librerie esterne, complicandone di fatto l’utilizzo.

Continua a leggere Javascript e Promise

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.