Usiamo una sorta di approccio microservizi nella nostra app (anche se non è di conseguenza rispettato).
Quando un servizio è inattivo o genera un'eccezione, l'approccio consiste nel metterlo in una coda (ActiveMQ) e riprovare quando il servizio è di nuovo attivo.
Questa è una soluzione "standard"? O dovrebbe essere evitato per qualche motivo?
O c'è una soluzione migliore o alternativa a questo problema?
Questo è un approccio sbagliato a mio avviso. dovresti
comunica sempre visualizza una coda: la tua applicazione non dovrebbe aspettarsi una risposta immediata e quindi il processo di lavoro non deve essere disponibile al 100%
Usa sempre le comunicazioni in stile RPC. Richieste di bilanciamento del carico tra più istanze di servizio: se un servizio è difettoso, un altro risponderà alla richiesta, in modo da avere il 100% di uptime
Avere il flusso, chiamare il servizio, ottenere errori, mettere in coda, ricordarsi di controllare la coda per le risposte ad alcuni dei miei messaggi ma non a tutti. è complicato.
modifica: troppo complicata in quanto devi programmare sia lo stile di sincronizzazione che quello di comunicazione asincrona piuttosto che uno solo o l'altro.
Supponendo di poter effettuare chiamate asincrone (non è necessario ricevere una risposta dal servizio per poter procedere), farlo spesso è una buona idea.
Consente al servizio di chiamata di continuare a funzionare senza il ritardo (o l'errore definitivo) causato dalla chiamata all'altro servizio. Ti consente di avere una logica di retry più complessa e di distribuire il carico in modo più uniforme nel tempo.
In molti casi, puoi ottenerne ancora di più abbandonando le garanzie di ordinazione fornite dalle code e passa a Kafka o un altro broker di messaggi asincroni. Hermes fornisce un'API REST più comoda su Kafka.
Leggi altre domande sui tag microservices message-queue