Gestione dei casi in cui la coda dei messaggi non è raggiungibile

Question

Gestione dei casi in cui la coda dei messaggi non è raggiungibile

#1 da (1 voti)
#2 da (0 voti)

6

Usiamo Apache Camel con ActiveMQ in un'architettura di microservizi in un crescente sistema di soluzioni di integrazione. Mi chiedevo come ogni servizio dovrebbe reagire quando non sono in grado di connettersi alla coda dei messaggi, o se questo dovrebbe essere gestito a tutti.

Poiché il sistema è in questo momento ogni servizio registra un'eccezione per ogni tentativo di riconnessione se il broker della coda dei messaggi non è raggiungibile. Questo sembra molto sub-ottimale. Esistono soluzioni già implementate o altri suggerimenti intelligenti in grado di gestirli? Eseguiamo un broker non cluster su localhost, quindi se il broker è irraggiungibile, è probabilmente causato dal servizio che contiene il broker che si è arrestato in modo anomalo e non funzionerà fino a quando qualcuno riavvierà manualmente l'intero contenitore servlet (in questo caso il molo) , che molto probabilmente richiederebbe almeno minuti. E quando qualcuno riavvia il sistema, i file di registro avranno innumerevoli eccezioni di connessione JMS.

java microservices message-queue

posta haraldfw 27.07.2016 - 12:26

fonte

2 risposte

Leggi altre domande sui tag java microservices message-queue

Il modo migliore per accedere a un logger su un'applicazione / sito web in PHP Gli emettitori di eventi possono essere funzionali?

score 1 · Answer 1

I contenitori Java EE e Spring Framework gestiscono le connessioni JMS, come esempi. La mia esperienza con loro è stata la registrazione di un errore e il tentativo di riconnettersi 3 o 5 secondi dopo. Poiché c'è un ritardo tra i tentativi di riconnessione, il numero di voci di registro non dovrebbe essere ridicolo per un periodo di tempo ragionevole.

score 0 · Answer 2

Ci sono molte variabili qui. Idealmente, occorrerebbe una maggiore comprensione dei limiti di tempo e della natura dei servizi forniti.

Ma nel caso generale vorrei consigliare quanto segue: In primo luogo, dovresti considerare la probabilità dei diversi casi di errore. Non aggiungere la logica per gestire un errore che è improbabile che accada, perché ogni aggiunta aggiunge anche nuovi casi di errore. Hai già un broker locale che (se ho capito bene) memorizzerà i messaggi nel caso in cui il sistema remoto non funzioni. Questo suona come un principio decente che potrebbe salvarti da alcuni problemi di rete. Se prevedi questi problemi, bene. In caso contrario, salterò il broker.

Se hai il broker, suona già come il tuo piano di backup, quindi non proverei a continuare con garbo se si abbassa. Cerca di renderlo il più affidabile possibile, invece, trovando un sistema di messaggistica che sia robusto. Si potrebbe desiderare di avere un timeout abbastanza lungo da consentire un rapido riavvio del broker nel caso in cui si blocchi. Ma un tempo di avvio di diversi minuti rende questo suono quasi impossibile, quindi potresti voler riconsiderare la tua soluzione all'avvio del broker.

Se hai un sistema con un carico elevato, il buffering (con un broker locale o meno) non ti salverà mai a lungo termine. Quindi potresti voler riconsiderare e inviare invece l'errore upstream. Questo approccio è stato recentemente promosso da il manifesto reattivo ed è più o meno necessario non deprimere il sistema durante i problemi temporanei. Restituisci i codici di errore quando il tuo sistema si trova in uno stato di errore e costringi i client a ritentare le loro richieste.