Mircroservices - Ordinamento di eventi di integrazione

2

Attualmente sto imparando l'architettura basata sugli eventi e ho i seguenti 2 microservizi.

  • Servizio prodotto - Responsabile della gestione dei prodotti
  • Servizio ordini - Responsabile per l'elaborazione degli ordini

Il servizio del prodotto pubblica i seguenti eventi ogni volta che viene creato un prodotto

  • ProductedCreatedEvent
  • ProductedUpdatedEvent

Il Servizio ordini consuma questi messaggi e aggiorna il proprio archivio dati prodotto locale.

Domande

L'ordinamento degli eventi sembra abbastanza importante in quanto non desidero che il servizio di ordinazione consumi un ProductUpdatedEvent prima che il prodotto sia stato effettivamente creato.

Ho esaminato Azure Service Bus in quanto ciò può garantire l'ordine, tuttavia il loro ultimo prodotto, progettato per l'architettura basata su eventi, Azure Event Grid, non supporta l'ordine garantito.

Dovresti utilizzare solo un sistema di messaggistica che supporta FIFO in un'architettura di microservizi?

Se l'ordinamento non può essere garantito tramite il sistema di messaggi, in quali altri modi possiamo risolvere questo problema, se è davvero un problema.

    
posta fml 08.06.2018 - 15:27
fonte

1 risposta

4

Decidere se l'ordine è importante dipende da ciascun microservizio. Nel tuo caso, lo è sicuramente. Il tuo esempio sopra è in realtà facile da risolvere poiché se OrderService ottiene un evento UpdateProduct quando il prodotto non esiste, può riportare l'evento UpdateProduct sulla coda assumendo che ci sia un evento Create in arrivo. Tuttavia, due eventi di UpdateProduct che arrivano fuori ordine potrebbero causare problemi, quindi dobbiamo ancora risolvere il problema.

Ci sono modi per garantire l'ordine nell'editore e nell'abbonato, ma sono goffi. Se gli eventi di aggiornamento contengono l'intero nuovo stato del prodotto, è possibile aggiungere un timestamp e rifiutare di aggiornare la cache se il timestamp in entrata è precedente a quello persistente. Se gli eventi di aggiornamento inviano solo dati aggiornati, è possibile inserire un numero di versione incrementale nel proprio aggregato e se un evento in entrata è maggiore di 1 rispetto alla versione esistente, riaccodare l'evento presumendo che l'evento intermedio sia in arrivo. Come puoi vedere, questi sono maldestri. Stai molto meglio assicurandoti l'ordine in coda.

Puoi prendere in considerazione Hub eventi di Azure anziché Grid eventi di Azure. L'Event Hub garantirà l'ordine in una singola partizione, quindi una partizione saggia della tua app ti darà la garanzia dell'ordine che ti serve. L'Event Hub è più simile a Kafka che a una coda tradizionale in quanto fornisce una coda più la persistenza degli eventi per un numero limitato di giorni. Questo può essere vantaggioso se un sistema si arresta e deve essere ripristinato.

    
risposta data 09.06.2018 - 18:20
fonte

Leggi altre domande sui tag