(articolo redatto da Vito Carrozza)
Nel panorama tecnologico moderno, l’efficienza e l’affidabilità delle comunicazioni tra le varie componenti di un’architettura software sono cruciali. Un elemento chiave che facilita questa comunicazione è il Message Broker, uno strumento essenziale per garantire che i messaggi vengano trasferiti in modo sicuro e tempestivo tra applicazioni e servizi.
Definizione di Message Broker
Si considerino entità intente a comunicare.
Nel caso più semplice possibile, quando si vuole instaurare una comunicazione diretta con un ricevitore, le due entità devono essere in comunicazione attiva, ossia il ricevitore deve essere pronto a ricevere quando il trasmettitore trasmette. Questa tipologia di comunicazione viene chiamata in letteratura con il nome di comunicazione sincrona.
Tuttavia, se si utilizzasse questa tipologia di comunicazione:
- i due attori dovrebbero essere sempre attivi, funzionanti e pronti ad espletare le loro funzioni: il trasmettitore deve trasmettere e il ricevitore deve essere pronto a ricevere. Ciò implica che per instaurare una comunicazione efficace, ci deve essere uno scambio di informazioni preliminari che permettono la trasmissione (ad esempio, lo stato di attività dei due attori, il linguaggio parlato, la velocità di trasmissione della sorgente etc.).
Inoltre, una volta instaurata la connessione, in base alla complessità del messaggio la comunicazione può avvenire più o meno velocemente: messaggi più complessi impiegano tendenzialmente un tempo di trasmissione maggiore.
Tutte queste situazioni sfociano in dei tempi di processamento dell’intero iter di comunicazione molto lunghi. Durante questo tempo, l’attore ricevente non può abbandonare il suo ruolo e dedicarsi ad altre attività, riducendo così drasticamente il suo throughput. - nessun margine di tempo del sistema per assorbire un possibile tempo di processamento di una richiesta: quando una risorsa viene stimolata da più richiedenti e si ha un sovraccarico di quest’ultima e questa risorsa, magari, è complessa dal punto di vista della sua creazione oppure deve essere trasferita ad altri enti, si generano inevitabilmente dei tempi attesa che non vengono nascosti in caso di una comunicazione sincrona: l’utente resta in attesa senza sapere lo status di avanzamento della sua richiesta.
Per risolvere questi problemi, è stato introdotto un nuovo componente architetturale che prende il nome di Message Broker.
Un message broker è un intermediario software che facilita lo scambio di informazioni tra applicazioni, servizi o sistemi all’interno di un’architettura. Esso sfrutta una struttura dati a coda per memorizzare i messaggi provenienti da una sorgente (detta anche “produttore) e funziona come un punto di snodo in cui i messaggi vengono inviati dal produttore, trattenuti (buffering) e poi inoltrati al destinatario appropriato (detto anche “consumatore”) al momento opportuno. Questa architettura permette alle applicazioni di comunicare in modo asincrono, disaccoppiando il mittente e il destinatario, e migliorando i parametri di affidabilità del sistema.
Parametri di affidabilità
Dal punto di vista ingegneristico, il Message Broker implementa un design pattern chiamato “producer/consumer”.
In questo pattern, vi è un’entità detta “producer” che vuole comunicare con un’entità detta “consumer” e lo fa depositando i messaggi in un buffer condiviso di dimensione fissata dal quale il consumer li preleverà di volta in volta, quando lo riterrà opportuno.
Compito del producer è fare in modo che il buffer non si saturi mai, e quindi non generare messaggi se il buffer è pieno; il consumer, d’altra parte, non deve leggere dal buffer se quest’ultimo è vuoto.
Il buffer può essere implementato utilizzando qualsiasi struttura dati, ma la maggior parte delle implementazioni predilige l’utilizzo di una coda per la sua politica di accesso in modalità FIFO (first-in, first-out), dove il primo messaggio ad entrare nella coda è anche il primo ad uscire da quest’ultima.
Il pattern producer/consumer permette il disaccoppiamento totale del produttore dal consumatore. A causa di questa prerogativa, l’implementazione di questo pattern da parte del Message Broker permette di ottenere forti vantaggi in termini di performance, scalabilità e high availability (è possibile trovare i dettagli di questi parametri di affidabilità qui):
- performance:
- bassa latenza: i message broker sono ottimizzati per consegnare i messaggi con bassa latenza, garantendo che i consumatori ricevano e processino i messaggi rapidamente.
- throughput elevato: sono progettati per gestire un alto volume di messaggi al secondo.
- ottimizzazione delle risorse: i message broker permettono di bufferizzare i messaggi, rendendo possibile l’elaborazione batch e la gestione delle risorse in modo più efficiente. I consumatori possono recuperare più messaggi in un solo colpo, riducendo l’overhead di rete.
- affidabilità della consegna: offrono diverse modalità di consegna, come “at-least-once” o “exactly-once”, per garantire che i messaggi siano consegnati e processati correttamente, senza duplicazioni o perdite.
- scalabilità:
- scalabilità orizzontale:
- produttori/consumatori: è possibile aggiungere più istanze di produttori e/o consumatori senza influire direttamente sulle rispettive controparti.
- scalabilità a livello di nodo: molti message brokers supportano la scalabilità orizzontale, permettendo di aggiungere più nodi al cluster per gestire volumi di messaggi più elevati.
- high availability:
- ridondanza e failover: la maggior parte dei message brokers in commercio permettono di replicare i messaggi su più nodi per garantire che, in caso di guasto di uno di essi, i messaggi siano ancora disponibili su altri nodi. Inoltre, i messaggi possono essere persistiti, ossia memorizzati su disco, garantendo che non vengano persi anche in caso di guasto del sistema.
- minimizzazione dei tempi di inattività: in caso di guasto di un produttore o consumatore, il sistema può continuare a funzionare perché il message broker gestisce i messaggi in coda. Questo consente di riparare o sostituire le parti guaste senza interrompere l’intero sistema garantendo così la fruibilità continua dei servizi.
- bilanciamento del carico: il message broker può distribuire i messaggi in modo bilanciato tra i vari consumatori, migliorando l’efficienza e prevenendo sovraccarichi su singoli consumatori. In quest’ottica, il message broker funziona come se fosse un load balancer (i dettagli sul componente “load balancer” possono essere letti qui).
- scalabilità orizzontale:
Paradigmi di comunicazione
Nell’implementazione di un message broker è possibile adottare diversi paradigmi di comunicazione per soddisfare specifiche esigenze di architettura.
Publisher/Subscriber
Il paradigma publisher/subscriber è uno dei più comuni, in cui i mittenti (publisher) inviano messaggi su uno specifico buffer che accomuna tutti i messaggi inerenti a uno particolare aspetto dell’architettura. In questo caso, il buffer è identificato da un nome e viene chiamato “topic”. I destinatari (subscriber), attraverso un meccanismo di sottoscrizione, si iscrivono a questi topic per ricevere i messaggi. Questo modello è ideale per sistemi che richiedono un’ampia distribuzione delle informazioni a più destinatari.
Point-to-Point
Nel modello Point-to-Point, i messaggi sono inviati da un mittente a un singolo destinatario attraverso una coda di messaggi. Questo paradigma è utilizzato quando è necessario garantire che ogni messaggio venga elaborato da un solo consumatore, migliorando l’affidabilità delle operazioni critiche.
Protocolli di Comunicazione: MQTT
I message broker possono utilizzare vari protocolli di comunicazione per trasmettere i messaggi tra i componenti del sistema. Tra questi, MQTT (Message Queuing Telemetry Transport) è particolarmente rilevante per le sue caratteristiche di leggerezza ed efficienza.
MQTT è un protocollo di messaggistica leggero, ideale per dispositivi con risorse limitate e reti a larghezza di banda ridotta. Supporta il modello publisher/subscriber e offre tre livelli di qualità del servizio (QoS) per garantire la consegna affidabile dei messaggi:
- QoS 0: At most once – i messaggi sono consegnati una sola volta, senza garanzia di conferma.
- QoS 1: At least once – i messaggi sono consegnati almeno una volta, con conferma di ricezione.
- QoS 2: Exactly once – i messaggi sono consegnati esattamente una volta, evitando duplicati.
L’adozione di MQTT è particolarmente comune in applicazioni IoT, dove la minimizzazione del consumo di rete e l’affidabilità della comunicazione sono cruciali.
Message Brokers vs Queue e REST API
Per comprendere meglio il valore del Message Broker, è utile confrontare il suo funzionamento con altre tecnologie di comunicazione tra servizi di un architettura software, come le code di messaggi semplici e le API REST.
Message Brokers vs Queue
I servizi a code di messaggi semplici offrono una semplice coda con modalità di accesso FIFO (First In, First Out) per la gestione dei messaggi.
Sebbene questo strumento sia parte integrante di un message broker, questi ultimi aggiungono potenza alle semplici code offrendo funzionalità avanzate come il routing intelligente, il supporto per più protocolli di comunicazione e la gestione complessa degli topic, rendendoli più adatti per architetture complesse e scalabili.
Message Brokers vs REST API
Le API REST (le cui linee guida per la progettazione è possibile leggere qui) sono ideali per comunicazioni sincrone e interazioni semplici tra client e server. Tuttavia, per sistemi distribuiti che richiedono comunicazioni asincrone e disaccoppiate, i message brokers forniscono una soluzione più robusta fornendo una comunicazione asincrona, riducendo la dipendenza tra i componenti e migliorando la resilienza e la scalabilità.
Message Brokers open source
Esistono numerose soluzioni open source di message brokers. Tra le più note, si annoverano sicuramente Mosquitto, Apache Kafka e RabbitMQ.
Mosquitto
Mosquitto è un broker MQTT open source di casa Eclipse, leggero e facile da implementare. È particolarmente utilizzato in applicazioni IoT grazie alla sua efficienza e alla semplicità di configurazione.
Apache Kafka
Apache Kafka è un broker di messaggi distribuito progettato per la gestione di flussi di dati in tempo reale. I suoi punti vincenti sono i seguenti:
- Alto throughput e bassa latenza: Kafka è progettato per gestire milioni di messaggi al secondo con latenza molto bassa. Questo lo rende ideale per applicazioni che richiedono un elevato volume di dati e risposte rapide.
- Scalabilità orizzontale: Kafka può essere scalato orizzontalmente aggiungendo nuovi broker al cluster. Questo permette di gestire un aumento del carico senza interruzioni del servizio.
- Persistenza: Kafka assicura che i messaggi siano conservati su disco e replicati tra i broker, garantendo che i dati non vengano persi anche in caso di guasti hardware.
- Service-based: fornisce una serie di servizi di sistema a supporto dell’intero funzionamento del broker.
- Flessibilità di consumo: i consumer in Kafka possono leggere i messaggi a loro ritmo, permettendo a diversi consumatori di leggere dallo stesso topic indipendentemente l’uno dall’altro.
- Architettura distribuita e fault tolerance: Kafka è costruito per essere distribuito, con i dati replicati su più broker, per garantire la tolleranza ai guasti. Questo permette al sistema di continuare a funzionare anche in presenza di guasti hardware o di rete.
- Supporto all’evoluzione degli schemi: con il servizio Confluent Schema Registry, Kafka supporta la gestione e l’evoluzione degli schemi dei messaggi, garantendo retrocompatibilità tra produttori e consumatori e facilitando l’integrazione tra diversi sistemi.
- Semplicità di integrazione: Kafka offre connettori predefiniti per numerose tecnologie e sistemi tramite il servizio Kafka Connect, rendendo facile l’integrazione con database, sistemi di messaggistica, storage e altre sorgenti e destinazioni di dati.
- Sicurezza: supporta diverse funzionalità di sicurezza, tra cui autenticazione (via SSL e SASL), autorizzazione (ACL) e crittografia dei dati in transito, garantendo la protezione dei dati sensibili.
RabbitMQ
RabbitMQ è un broker di messaggi versatile che supporta vari protocolli di messaggistica, inclusi AMQP, MQTT e STOMP. È noto per la sua facilità d’uso e le sue capacità di routing avanzate, rendendolo adatto a una vasta gamma di applicazioni.
Message Brokers nei principali cloud providers
I principali cloud provider offrono soluzioni di message brokening integrate nei loro servizi, facilitando l’implementazione e la gestione delle architetture.
Pub/Sub di Google Cloud
Google Cloud offre Pub/Sub, un servizio di messaggistica globale e scalabile che supporta il pattern publisher/subscriber. È progettato per l’elaborazione di grandi volumi di dati e si integra facilmente con altri servizi di Google Cloud.
SQS e Amazon MQ di AWS
Amazon Simple Queue Service (SQS) e Amazon MQ sono le soluzioni di brokening di AWS. SQS è una coda di messaggi completamente gestita, mentre Amazon MQ supporta protocolli come AMQP, MQTT e STOMP, fornendo una soluzione flessibile per varie esigenze di messaggistica.
Il brokening di Microsoft Azure
Microsoft Azure, invece, offre diversi servizi per il message brokening. Qui si citano:
- Azure Service Bus, soluzione di messaggistica di Microsoft, che offre funzionalità avanzate come il supporto per il pattern publisher/subscriber, code di messaggi e routing avanzato.
- Azure Event Hubs, soluzione per la gestione di flussi di eventi in tempo reale.
- Azure Event Grid, stema di distribuzione di eventi affidabile e senza server su scala massiva. Utilizza il modello publisher/subscriber.
Conclusioni
I message broker rappresentano un elemento fondamentale nelle architetture software moderne, migliorando la comunicazione tra i componenti del sistema e garantendo affidabilità, scalabilità e high availability. Con una vasta gamma di opzioni open source e soluzioni cloud, è possibile scegliere il broker che meglio si adatta alle specifiche esigenze di un progetto. Comprendere i design patterns, i paradigmi di comunicazione e i protocolli utilizzati permette di sfruttare al meglio questi strumenti, costruendo architetture robuste e resilienti.
Se anche tu vuoi far parte del team di sviluppo Nexsoft,
dai un’occhiata alle nostre opportunità di lavoro e conosciamoci subito!
