Il mio team sta discutendo dell'uso di RabbitMQ per microservizi alla comunicazione con microservizi (tra le altre cose). Stiamo anche supportando un backend di SAP che ci spinge i dati in un metodo indeciso in questo momento (probabilmente tramite Boomi o Idocs). Sappiamo quasi nulla su RabbitMQ, ad eccezione dei concetti generali di una coda di messaggi e di ciò che siamo stati in grado di determinare da un'analisi di alto livello della loro documentazione. Il modello generale sembra essere un utente abbonato a una o più code, e Rabbit spinge verso quelle code in base a regole altamente configurabili, ma i messaggi su una singola coda vengono letti completamente "una volta" prima di essere rimossi (questo è un generalizzazione, poiché ci sono molte opzioni intorno alle conferme e roba del genere).
Questa è un'immagine molto semplice di una configurazione in cui ogni consumatore si preoccupa solo di argomenti distinti per loro:
Mentrequestoèpiùcomplesso,incuiunsingoloargomentovienedivisoinpiùcode.Tuttavia,quandoconfiguriamolecode,dobbiamosaperedoveinviaregliargomentieabbiamoancorabisognodiunacodaperutentediquelmessaggio
Quellochestoimmaginandoèinveceunagigantescapipelinedimessaggichetuttiimessaggiattraversano,conisingoliabbonaticheleggonoimessaggiadessipertinenti.Qualcosadipiùvicinoaquestoconcetto:
Il mio obiettivo è quello di mantenere tutto il più liberamente possibile. Con i disegni 1 o 2, dobbiamo aggiornare il sistema di accodamento o scambiare ogni volta che viene aggiunto un nuovo consumatore. Con il terzo design, il sistema di accodamento è agevole per ciò che sta consumando, e invece sa solo che è necessario inviare messaggi. I consumatori possono quindi solo leggere la coda, afferrando le copie dei messaggi pertinenti a loro.
Questo progetto ha senso? Non possiamo essere i primi a desiderare un sistema come questo, poiché dovrebbe essere un'esigenza abbastanza comune (i cambiamenti si verificano in un sistema e più utenti devono intervenire su di essi).