Che cos'è RabbitMQ?
In qualsiasi app nativa del cloud, i microservizi devono comunicare per ottenere tutte le informazioni necessarie per rispondere agli utenti. È necessario assicurarsi che questa messaggistica sia affidabile anche in caso di problemi di rete o errori tra le integrazioni. RabbitMQ è uno strumento che è possibile usare per aumentare l'affidabilità della messaggistica.
Con il rivenditore di attrezzature per esterni, si stanno facendo rapidi progressi con i microservizi. Tuttavia, nel test delle applicazioni alcune chiamate da un microservizio a un altro sembrano andate perse. Ci si vuole assicurare che il problema non si verifichi nell'ambiente di produzione in cui la reputazione dell'azienda è in gioco.
In questa unità si vedrà come RabbitMQ può creare una piattaforma di comunicazione flessibile e resiliente per i microservizi.
Perché usare un broker di messaggi in un'app nativa del cloud?
Le app native del cloud sono costituite da microservizi indipendenti, spesso creati da team separati e che usano tecnologie e linguaggi diversi. Ogni team ha i propri sprint di sviluppo e programmi di aggiornamento e può distribuire correzioni e nuove funzionalità in modo continuo. Tuttavia, quando la richiesta arriva da un utente, il microservizio che la riceve ha quasi sempre bisogno di chiamare altri microservizi e servizi di supporto e ricevere risposte da loro per formulare la risposta completa.
Ovviamente il formato e lo schema di queste richieste e risposte tra servizi devono essere concordati tra i team di sviluppo e cambiare raramente. In genere vengono implementati come API REST. È consigliabile implementare nuove funzionalità di ogni interfaccia senza modificare i metodi e i parametri esistenti. Tuttavia, se si sceglie di far comunicare direttamente i microservizi, possono verificarsi diversi problemi:
- Quando un microservizio di destinazione è offline o occupato, cosa succede ai messaggi inviati? Quali sono le conseguenze della perdita dei messaggi?
- Come si può inviare lo stesso messaggio a più di una destinazione?
- Se un microservizio è in esecuzione in più di un contenitore, a quale inviare i messaggi?
Il broker di messaggi è un middleware che risolve questi problemi. I servizi inviano messaggi al broker di messaggi anziché direttamente a una destinazione. Il broker li archivia in code nell'ordine in cui arrivano. I servizi di destinazione eseguono la sottoscrizione a queste code e prelevano i messaggi, uno alla volta, per l'elaborazione.
Se il servizio di destinazione non è disponibile, il microservizio di invio può comunque inserire i messaggi nella coda. Quando la destinazione viene riavviata, continua a raccogliere i messaggi dalla coda, dallo stesso punto. Nessun messaggio viene perso, anche se il mittente deve attendere più a lungo.
Poiché più di una destinazione può esegue la sottoscrizione una coda, un singolo messaggio può essere ricevuto da più di un microservizio. Inoltre, quando più contenitori ospitano istanze di un singolo microservizio, la prima istanza che diventa disponibile preleva il messaggio. Il broker distribuisce automaticamente i messaggi alle istanze per distribuire il carico.
Che cos'è RabbitMQ?
RabbitMQ è uno dei broker di messaggi più diffusi e offre molte funzionalità che lo rendono un candidato ideale per gestire le comunicazioni in un'app nativa del cloud. Comprende:
- Il server RabbitMQ, che ospita le code. Il server supporta il clustering e il failover per la disponibilità elevata e può essere eseguito in contenitori.
- Implementazioni di Advanced Message Queuing Protocol (AMQP), Simple Text Oriented Message Protocol (STOMP) e Message Queuing Telemetry Transport (MQTT).
- Librerie client AMQP che è possibile usare in. NET, Java ed Erlang.
Concetti di RabbitMQ
In termini RabbitMQ, i microservizi, che inviano e ricevono messaggi, sono client. I client che inviano messaggi sono producer di messaggi. I client che ricevono messaggi sono consumer di messaggi. Il servizio RabbitMQ è il broker di messaggi.
Come inviare messaggi
RabbitMQ è versatile e in grado di implementare molti modelli di accodamento diversi. Esaminiamo alcuni dei modelli più diffusi.
Se si dispone di un singolo producer e di un singolo consumer, si usa un'unica coda e tutti i messaggi raggiungono la stessa destinazione. Anche in questa semplice configurazione, si crea un sistema di messaggistica affidabile che gestisce le interruzioni senza problemi:
Invio di messaggi a consumer concorrenti
Nel modello consumer concorrente, un producer invia messaggi a una singola coda di lavoro. Due o più consumer recuperano messaggi dalla coda. I consumer competono per recuperare i messaggi perché ogni messaggio può essere recuperato solo da un singolo consumer.
Questo modello è utile nelle app native del cloud quando si dispone di un microservizio consumer ospitato in più contenitori per aumentare la capacità. Ogni messaggio raggiungerà solo un'istanza del consumer, quindi verrà elaborato solo una volta. Il lavoro non verrà duplicato.
Pubblicazione e sottoscrizione
Se si vuole inviare un singolo messaggio da un producer a più consumer, usare il modello di pubblicazione/sottoscrizione. Il producer invia messaggi a uno scambio. Ogni consumer esegue la sottoscrizione dei messaggi di tale scambio. Quando eseguono la sottoscrizione, RabbitMQ crea una nuova coda di lavoro per tale sottoscrizione. Ogni messaggio viene copiato in ogni coda per tale scambio e viene ricevuto da ogni consumer che ha eseguito la sottoscrizione. I consumer non competono per ogni messaggio. Ricevono invece una copia di ogni messaggio.
Il modello pubblicazione/sottoscrizione utilizza uno scambio fanout, che copia ogni messaggio in ogni coda di lavoro.
Questo modello è utile quando si vuole che ogni messaggio venga elaborato da più microservizi. Ad esempio, quando un cliente estrae un carrello, potrebbe essere necessario inviare un messaggio sul numero di ogni prodotto acquistato. Questo messaggio dovrebbe raggiungere sia il microservizio di spedizione, per indicare al magazzino di imballare il pacchetto, che il microservizio scorte, per ridurre i numeri di scorte ed eventualmente attivare ordini ai fornitori.
Routing di messaggi e argomenti
A volte si desidera distribuire singoli messaggi a più consumer ma, per ogni consumer, applicare un filtro. Questo modello viene chiamato router di messaggi. Come nel modello di pubblicazione/sottoscrizione, i consumer eseguono la sottoscrizione dello scambio per creare più code di lavoro. Tuttavia, invece di uno scambio fanout, il modello usa uno scambio diretto. Con questo scambio, ogni sottoscrizione ha una chiave di associazione. Solo i messaggi la cui chiave di routing corrisponde alla chiave di associazione vengono inviati a questa sottoscrizione. Altri vengono filtrati.
Questo modello è utile quando alcuni consumer devono elaborare solo un subset del flusso di messaggi. Si supponga, ad esempio, di avere un microservizio che invia messaggi quando si verificano errori. Tutti gli errori devono essere inviati al microservizio di registrazione. Gli errori critici devono essere inviati al microservizio di amministrazione che avvisa i tecnici per risolvere il problema.
Lo scambio diretto instrada i messaggi in base a un singolo criterio. Per rendere le cose ancora più flessibili, è possibile usare uno scambio di argomenti. Per ogni messaggio, è possibile usare una chiave di routing con più termini separati da punti. Nella chiave di associazione è possibile usare i caratteri jolly *, per sostituire esattamente una parola o # per sostituire zero o più parole.
Nota
Le alternative a RabbitMQ includono Apache Kafka e il bus di servizio di Azure. Entrambi questi broker di messaggi sono supportati da integrazioni dedicate in .NET Aspire. Verrà illustrato il bus di servizio di Azure in un modulo successivo in questo percorso di apprendimento.