Event Driven Microservice Architecture & Dealing con i sistemi vicini esterni sincroni

1

Diciamo che ho un sistema di microservizi basato su eventi - un cluster di microservizi - che accetta ordini e lavora con loro. Gli ordini vengono effettuati da un sistema adiacente esterno che funziona in modo sincrono tramite un endpoint REST fornito da uno dei miei microservizi. Questo servizio funge da facciata per mantenere tutte le cose sincrone all'esterno del mio cluster poiché ogni comunicazione all'interno è basata sui messaggi (asincrona). Gli ordini in arrivo verranno archiviati in un database da un altro dei miei microservizi che reagisce a un messaggio di evento inviato dal microservice della facciata.

Ora, supponiamo che vi sia un obbligo di gestire la cancellazione in entrata per gli ordini e che tali cancellazioni avvengano anche tramite REST. Per le cancellazioni valide è stato inserito un ordine prima e quindi è memorizzato nel database del mio cluster.

Se non provassi a progettare eventi guidati, penserei a qualcosa di simile: Se si verifica una cancellazione tramite REST, sincro controllo se un ordine corrispondente per tale cancellazione è nel mio database. In tal caso, la mia risposta sincrona alla chiamata REST sarebbe 200 se tutto è OK e in caso contrario, rifiuterei l'annullamento non valido.

Ma dal momento che sto cercando di progettare un sistema basato su eventi, non so come gestirlo. Penso che forse avrei un altro microservizio di facciata che fornirebbe l'endpoint REST per la cancellazione. E alla ricezione di una cancellazione dovrebbe anche inviare un messaggio in una specifica coda / argomento per iniziare a lavorare in modo asincrono da lì. Ma come posso gestire il fatto che ho bisogno di informazioni dal database per verificare se una cancellazione non è valida e questo nuovo servizio di facciata non ha accesso al mio database di cluster? Devo accettare sempre le cancellazioni e dire al mondo esterno che tutto va bene, anche se non so se è vero? E se l'altro sistema ha bisogno di sapere di cancellazioni non valide, devo dare loro l'accesso in modo che possano ascoltare uno dei miei argomenti / code, in modo che possano quindi reagire a un messaggio di evento che viaggia attraverso il mio cluster contenente le informazioni se una cancellazione era valida? O devo creare un altro servizio in cui il mondo esterno può chiedere se una cancellazione era valida? E se non riesco a parlare con i manutentori del sistema straniero o non vogliono cambiare i loro sistemi API? O devo dare al mio database l'accesso a microservice un endpoint REST accessibile internamente al quale accedo dal mio microservizio di facciata in modo sincrono?

Come faccio a progettarlo mantenendo i miei microservizi scalabili, resilienti, liberamente accoppiati, ecc.?

Spero di aver fatto la mia domanda in modo comprensibile. Forse sto pensando completamente nel modo sbagliato e / o mi manca qualcosa sull'architettura guidata dagli eventi?

Spero che qualcuno qui possa darmi una soluzione, un'idea o un suggerimento nella giusta direzione.

Molte grazie in anticipo!

    
posta fosb 01.08.2018 - 07:39
fonte

1 risposta

0

Le chiamate sincrone sono solo un problema quando il lavoro richiesto è lento.

Poiché devi solo controllare un db, puoi avere una coda per le richieste di convalida della cancellazione con una coda di restituzione in stile RPC e chiamarla dal tuo servizio REST, mantenendo la richiesta in arrivo in attesa.

Dove potresti finire con problemi è quando il messaggio di ordine è ancora in coda per essere processato e ricevi un annullamento per questo. Tuttavia, non sembra irrisolvibile.

Se l'elaborazione della richiesta di annullamento era lenta, allora sì, non avresti altra scelta che adattare il tuo flusso di lavoro a uno asincrono.

Il mio consiglio generale sarebbe: Se stai usando code di messaggi, rendi i tuoi microservizi un po 'più grandi di quanto faresti diversamente. Solo per mantenere il numero di tipi di messaggi interni a un livello gestibile.

Probabilmente vorrei avere il resto del servizio controllare direttamente il db. Se hai bisogno di un messaggio per attivare altre cose, puoi sempre licenziare un CancellationRequestProccessed o qualcosa nello stesso momento in cui svolgi il lavoro vero e proprio.

    
risposta data 01.08.2018 - 09:38
fonte

Leggi altre domande sui tag