Microservizi: eventi ovunque

In teoria è bello avere tutti questi messaggi in giro ma in pratica ognuno richiede un livello di gestione degli errori oltre a una chiamata API sincrona. Non ha senso utilizzarli per le chiamate veloci all'interno dello stesso servizio.

Prima di tutto. se stai davvero facendo un sito di e-commerce dove aggiungere al carrello richiede una chiamata al server. Stop. Non scala. fai tutto il lato client. Controlla i livelli delle scorte quando si arriva a soddisfare l'ordine in magazzino.

È ancora peggio se ogni client ha una connessione websocket aperta. non andare lì.

Se è solo un esempio, puoi perdere alcuni messaggi, basta che il client invii l'add-to-basket, lo elabori in un servizio e rispedisca il messaggio di risposta. Quei messaggi interni potrebbero sembrare interessanti, ma a meno che non ci sia un vero motivo per cui stai solo facendo durare la vita.

Non riesco a parlare con gli altri flussi di lavoro, ma quello che hai descritto qui è un insieme di chiamate a procedure remote asincrone, coordinate dal servizio Basket Saga.

Consiglio vivamente di guardarli in questo modo e non, come implicito qui, con messaggi di richiesta e riconoscimento indipendenti.

Il motivo sono errori e timeout. Per mantenere la logica del flusso di lavoro trattabile, per qualcosa di più di un flusso banale, ti consigliamo di racchiudere i percorsi di successo, di errore e di timeout. Sotto le copertine è possibile eseguirli come messaggi che condividono, diciamo, richiedendo identificativi, ma estrapolandoli dalla logica del flusso di lavoro.

Mantenere gli RPC asincroni su una coda che si esegue il polling in un ciclo è un modo comune per implementare il servizio del flusso di lavoro.

Se hai flussi di lavoro che includono il fuoco e dimentichi le notifiche, usa assolutamente i messaggi non elaborati per quelli.

Inoltre, se si combinano i gateway in entrata e in uscita, è possibile eseguire un ciclo simile al servizio Basket Saga che mantiene solo gli RPC asincroni al servizio Basket Saga.