Una tipica architettura reattiva ad alto carico è:
(Q significa coda)
E solitamente le frecce vanno dal cliente al DB a tali schizzi. La mia domanda è come sta andando la risposta? Le stesse code e altre cose?
(I collegamenti delle immagini alle presentazioni / ai video sono apprezzati)
In un sistema basato su messaggi asincroni (eventi), non vi è alcun concetto di "risposta" sincrona. Tuttavia, alcuni eventi potrebbero essere correlati. Molte code di messaggi consentono a un messaggio / evento di avere un ID di correlazione per determinare in che modo i messaggi sono correlati. Ad esempio:
Se l'evento "risposta" è pubblicato sulla stessa coda o su una coda messaggi diversa è un dettaglio di implementazione.
Mentre i sistemi basati su eventi sono molto flessibili, offrono poche garanzie. Ad esempio, in genere non possiamo garantire:
Ciò può rendere difficile l'interfacciamento di messaggi asincroni con protocolli sincroni come HTTP. Potrebbe quindi essere necessario rendere conto della natura asincrona a tutti i livelli del progetto.
Ad esempio, considera un evento che causerà un'azione esterna irrevocabile, come l'invio di un'email. A causa di limitazioni tecniche, lo stesso evento può essere ricevuto più volte, ma solo una email deve essere inviata per evento. Una possibile soluzione consiste nel memorizzare gli ID evento elaborati in un database transazionale. Gli eventi vengono scartati se erano già stati visti.
Ciò è ancora problematico se si suppone che il servizio di posta elettronica generi un evento di conferma, ma tale conferma viene persa. Quindi, inviare nuovamente la conferma ogni volta che l'evento originale viene nuovamente ricevuto potrebbe essere appropriato.
Come altro esempio, prendi in considerazione un sito Web che prepara alcuni contenuti scaricabili su richiesta, ma la generazione di questo contenuto richiede del tempo. Il server Web pubblica un evento che richiede di generare il download. Cosa dovrebbe fare il server web nel frattempo?
Una possibilità è aspettare, nella speranza che ci sarà un evento di risposta entro un certo timeout. Tuttavia, questa risposta non è garantita.
Un'altra alternativa consiste nell'esporre la natura asincrona al client e rispondere immediatamente dopo l'attivazione dell'elaborazione in background. (202 Accettato sarebbe un codice di stato appropriato). La risposta HTTP dovrebbe offrire un modo per monitorare lo stato della richiesta. Successivamente, il servizio di backend genera un evento di risposta. Questo potrebbe innescare un qualche tipo di notifica al client, sia che si tratti di un messaggio attraverso una websocket, una e-mail, o semplicemente la creazione di una risorsa che il client occasionalmente esegue il polling.
Leggi altre domande sui tag microservices architectural-patterns message-queue reactive load-balancing