Come possiamo tenere traccia dei flussi aziendali nelle architetture basate su eventi?

Question

Come possiamo tenere traccia dei flussi aziendali nelle architetture basate su eventi?

#1 da (5 voti)
#2 da (1 voti)

5

Sto pianificando di configurare un'architettura basata sugli eventi utilizzando le app Spring Boot che pubblicano e leggono i messaggi da un broker Kafka.

Supponiamo che si trattasse di un'applicazione di e-commerce con i soliti eventi (ordine effettuato, pagamento elaborato / non riuscito, articolo riservato, nessuna disponibilità dell'inventario, spedizione dell'ordine e così via).

Nel mio contesto aziendale temo che ciò possa accadere:

The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system. This can make it hard to debug and modify such a flow. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. The pattern is still very useful, but you have to be careful of the trap.

Da l'articolo di Martin Fowler Cosa intendi per evento guidato

La domanda è: come posso mantenere una visione globale del flusso aziendale in un'architettura così disaccoppiata e ricca di eventi?

microservices distributed-computing event-sourcing event

posta codependent 03.10.2018 - 09:30

fonte

2 risposte

1

Puoi fare affidamento sulla mappa di contesto che ti offre una visione di alto livello dei contesti limitati e delle loro relazioni .

Quindi, all'interno di un contesto Bounded, puoi fare affidamento sul codice per darti una visione dettagliata di come dovrebbe funzionare il sistema. Qui hai Aggregati, che elaborano comandi ed emettono eventi. Poi hai Sagas / Process Manager che coordina i processi aziendali di livello superiore reagendo agli eventi e inviando comandi agli Aggregati.

Quindi è possibile avere una visualizzazione live di come i messaggi viaggiano attraverso il sistema. Ho fatto qualcosa come questo in passato.

risposta data 03.10.2018 - 09:50

fonte

Leggi altre domande sui tag microservices distributed-computing event-sourcing event

Come esporre i vincoli di campo usando HATEOAS? Esporre le variabili membro vs Aggiungere funzioni membro per modificarle

score 5 · Accepted Answer

The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system.

Ci sono due aspetti distinti: come centralizzare la logica di un flusso e come identificare i flussi durante il monitoraggio.

Per il monitoraggio di una possibile soluzione è l'uso di ID di correlazione e di causalità . Ogni evento è etichettato con un ID casuale e univoco. L'ID di correlazione di un flusso è l'ID univoco dell'evento di origine e viene copiato su un campo separato di ogni evento successivo che fa parte di quel flusso. L'ID di causalità è l'ID univoco dell'evento precedente nel flusso che ha portato direttamente nell'evento corrente, utile per determinare la relazione causativa tra gli eventi. Conveniente in questo è che non esiste un componente centrale che deve fare la contabilità dei flussi, in quanto solo l'aggregazione dei registri dopo che il fatto è necessario.

Percentralizzarelalogicadelflussounasoluzionestanell'usodi saghe e process manager . La saga è un flusso di lunga durata in un sistema evented che si estende su più parti e possibilmente su più contesti limitati. Il process manager è un software che collega le parti insieme. Non implementa essa stessa alcuna logica di business, ma semplicemente mappa gli eventi sui comandi ad altre parti del sistema.

Perinciso,cisonomoltipiùproblemineisistemieventisticirispettoall'identificazionedeiflussi.Unarisorsautileèil viaggio CQRS di Microsoft. Illustra attraverso un sistema reale cosa sono e come affrontarli.