Come gestire i messaggi in errore in DDD?

5

Abbiamo un set di micro-servizi tutti costruiti secondo il Domain Driven Design (DDD). I microservizi comunicano tra loro tramite Eventi di dominio ( OrderSubmittedEvent , CustomerBilledEvent , ...). Abbiamo implementato tutto con Spring Boot e utilizzato JMS con ActiveMQ come broker dei messaggi. Tutti gli eventi sono pubblicati su un argomento e ogni micro-servizio può implementare un listener JMS per un evento di interesse.

Ma per la gestione degli errori, ci affidiamo molto ad ActiveMQ. Come ho detto, tutti gli eventi vengono inviati a un argomento. Tuttavia, abbiamo configurato ActiveMQ per utilizzare argomenti virtuali per i listener, il che significa che ActiveMQ creerà una coda separata per ciascun listener e copierà il messaggio dall'argomento alla coda. Se un listener fallisce, il messaggio viene inviato a una Dead Letter Queue (DLQ). Questo ci aiuta, perché possiamo monitorare il DLQ, vedere gli errori, correggerli e rimettere il messaggio nella coda del listener che ha fallito per un altro tentativo.

Abbiamo un paio di problemi con questo:

  • Finiamo con un sacco di code, dato che ogni ascoltatore avrà la sua coda.
  • Non possiamo cambiare il broker dei messaggi poiché ci affidiamo agli Argomenti virtuali di ActiveMQ.
  • Non possiamo usare ActiveMQ subito dopo averlo configurato sempre. Il nostro cliente per il quale sviluppiamo il software esegue manualmente la configurazione nel suo sistema. Dato che abbiamo così tante code e piccole insidie, è molto ingombrante per lui.

Bene, non abbiamo un'idea migliore, ecco perché ti sto contattando. Come possiamo gestire i messaggi falliti? Qual è il tuo modo?

    
posta Thomas Uhrig 27.12.2017 - 17:34
fonte

1 risposta

5

Un modo per affrontarlo consiste nell'utilizzare listener basati su pull invece di push-based. Ogni ascoltatore tiene traccia del suo ultimo messaggio letto e può richiedere "messaggi da X". È possibile utilizzare il polling o una notifica quando arriva un nuovo evento o entrambi per attivare le richieste di messaggi. Niente più code, ma il listener dovrà memorizzare l'ultimo ID messaggio elaborato. È inoltre necessario archiviare gli eventi in modo da preservare l'ordine per supportare le richieste di ascolto.

Ogni volta che un listener non riesce a elaborare un evento, può registrare l'errore in qualsiasi infrastruttura di logging installata. Quindi si osserverà o verrà notificato l'errore dall'infrastruttura di monitoraggio. Una volta risolto quel particolare listener e ridistribuendolo, il listener riprenderà da dove era stato interrotto.

    
risposta data 27.12.2017 - 18:14
fonte

Leggi altre domande sui tag