Applicazione distribuita utilizzando RabbitMQ

5

Sono sulla mia strada per creare un'applicazione con 4 contesti limitati usando CQRS & sourcing di eventi.

Per fare in modo che questi contesti limitati parlassero tra loro stavo pensando di usare Rabbit MQ.

I miei requisiti sono i seguenti:

  • Il contesto limitato non deve conoscersi l'un l'altro
  • Il contesto limitato non deve essere ostacolato se l'altro contesto limitato è inattivo o se rabbitMQ è inattivo
  • Se un contesto limitato non è disponibile i messaggi, che dovrebbe ricevere, devono attendere pazientemente il suo ritorno cioè: ogni evento pubblicato deve essere inoltrato almeno una volta a tutti i bc interessati.

Pertanto, stavo pensando di fare in modo che ognuno di essi facesse riferimento a una coda: BandMasterQueue e lo crea se non lo è.

Quando si produce un evento, l'archivio eventi lo memorizza e la sua spedizione consiste di due passaggi:

  1. proietta su se stesso questo evento per ogni piccola proiezione. Ogni proiezione ha una piccola serie di eventi già proiettati per garantire l'idempotenza per un certo periodo di tempo.
  2. pubblica questo evento sulla coda BandMasterQueue

se fallirebbe nel passaggio 2 a causa della mancanza di un conigliomq, allora mi aspetto che il mio negozio di eventi riproverà a inviare il messaggio al RabbitMQ dopo qualche tempo (non proprio però proprio su questa parte, devo dire ...)

Il "contesto limitato" di bandMaster è in grado di riconoscere ogni BC che si prende cura di lui. È lui che legge BandMasterQueue e decide quali eventi sono pubblici e quali no. È anche responsabile della gestione delle "saghe" e può inviare azioni correttive a ogni bc.

Per fare ciò, comunicherà con ogni contesto limitato usando la coda dedicata del contesto limitato e lo creerà se non esce.

Ogni BC è legato a questa coda specifica e aggiunge l'evento proveniente dall'esterno nel proprio archivio eventi e successivamente lo proietta sulla propria proiezione.

Questa "architettura" dovrebbe funzionare o vedi qualche grosso difetto in essa?

    
posta Arthis 29.07.2012 - 09:44
fonte

2 risposte

3

Dai un'occhiata alla documentazione di ZeroMQs, in particolare la guida . Penso che vorrai qualcosa sulla falsariga della loro Figura 19 - Extended Request-reply. se no, c'è molta documentazione lì che dovrebbe darti quello che ti serve in alcune combinazioni.

Non sono sicuro di cosa intendi nel punto 3, ma il resto sembra che abbia bisogno di un'architettura che passa il messaggio disconnesso - tu spari i messaggi sulla rete, e se un BC è attivo e in ascolto, allora riceverà il messaggio processare.

Se hai bisogno di inviare un messaggio a un BC che è inattivo, allora hai bisogno di un broker che li legge e aspetta che il BC inizi a partire da dove lo invierà ad esso - tuttavia, ciò significa che il broker deve sapere i BC, per sapere se memorizzare i messaggi per uno.

    
risposta data 29.07.2012 - 16:01
fonte
0

Si potrebbe prendere in considerazione l'utilizzo di un meccanismo di pool di code per gestire le code RabbitMQ e anche per determinare le dimensioni del pool necessarie sotto carico. Qui è un tutorial sull'argomento.

    
risposta data 01.09.2015 - 14:58
fonte

Leggi altre domande sui tag