Un'architettura basata sugli eventi richiede che ogni attore possegga i suoi dati?

Naviga le tue risposte
1

Abbiamo avuto una discussione su questo argomento sul lavoro non molto tempo fa.

Abbiamo la seguente situazione:

  • Un database legacy che è attualmente la base per l'applicazione operativa principale nella nostra azienda.
  • Un nuovo sistema di gestione dei contenuti che dovrebbe ricevere informazioni sui dati master dal database citato. I dati master saranno sempre di proprietà del database precedente, ma è necessario nel CMS come base per costruire i propri dati. Potresti pensarlo come categorie o raggruppare i dati.
  • Un sistema di trigger nel database legacy che controlla determinate tabelle. Quando si verifica un inserimento / aggiornamento / eliminazione, inserisce una notifica in una coda di database.
  • Questa coda di database viene guardata da un (cosiddetto) servizio di caricamento , che riceve i dati e li inserisce in un argomento Kafka (Kafka viene utilizzato per un sacco di microservizi nei nostri sistemi).
  • A (ancora chiamato così) servizio di sincronizzazione che è sottoscritto all'argomento Kafka . Ogni volta che qualcosa viene pubblicato nell'argomento, il servizio lo consuma e lo invia al CMS.

Qui puoi vedere un diagramma che mostra l'architettura ad alto livello:

Per me questa è (una specie) un'architettura basata sugli eventi. Un evento si verifica nel DB legacy e altri servizi reagiscono ad esso.

Tuttavia, un mio collega ha insistito sul fatto che non poteva essere considerato un'architettura basata sugli eventi perché il proprietario dei dati principali che ha provocato l'evento era il database precedente . Fondamentalmente, l'argomento del mio collega era che ogni servizio dovrebbe possedere i propri dati e inviare messaggi di eventi ad altri servizi (tramite un mediatore), e che gli altri servizi dovrebbero reagire a questi eventi e costruire i propri dati in base alle proprie esigenze.

Ora, sono d'accordo sul fatto che ogni servizio dovrà utilizzare i dati dell'evento come sembra opportuno. Ma non sono d'accordo sul fatto che questo argomento significhi che l'architettura che ho spiegato non è guidata dagli eventi. Ho cercato su Internet e non ho trovato una dichiarazione chiara che indicasse che questo dato fosse un prerequisito per un'architettura da considerare come event-driven.

È veramente necessario in un'architettura guidata dagli eventi che ogni attore possegga i dati sui quali lavora? Vale a dire, ho davvero bisogno di non utilizzare i dati anagrafici di il database precedente nel CMS? E / o il CMS dovrebbe invece (idealmente) creare i propri dati e in qualche modo associarli ai dati del database precedente?

Alcuni chiarimenti:

  • So che l'architettura presentata potrebbe non essere la migliore che tu possa avere, ma lavorare con i sistemi legacy a volte ti costringe a modificare le cose.
  • So anche che questa architettura significa che i servizi sono accoppiati a livello di dati, ma è quello che abbiamo per ora, sempre a causa del sistema legacy.
posta Guillem Vicens 05.02.2018 - 19:30
fonte

2 risposte

1

Architettura guidata dagli eventi

Proprietà:

  • Qualche stato da qualche parte è cambiato.
  • L'evento rappresenta il fatto che questo stato è cambiato.
  • C'è qualcosa che aspetta, poi riceve e poi reagisce a un evento.

Se il sistema si adatta a questa descrizione è guidato dagli eventi. Potrebbero essere altre cose, ma gli eventi stanno guidando (almeno in parte).

Attore

Non hai approfondito questo argomento nel tuo corpo di domande, ma lo vedo in agguato nel titolo delle tue domande. Sento che probabilmente è da dove viene il tuo collega.

Proprietà:

  • Può ricevere messaggi
  • Può inviare messaggi
  • Impossibile modificare lo stato che non possiede.
  • Impossibile leggere lo stato che non possiede.
  • lo stato in cui è proprietario non può essere letto da terzi.
  • lo stato in cui è proprietario non può essere modificato da terzi.

Se ha queste proprietà è un attore.

Penso che il tuo collega stia pensando in questi termini, ma ha due malintesi:

  1. Ciò che costituisce lo stato di un attore.
    • Un database per definizione è un attore separato. Riceve una sorta di messaggio simile a SQL, gestisce il proprio stato, invia i risultati e forse genera altri messaggi (eventi).
    • Un attore può naturalmente contenere internamente un attore Database, ma deve farlo completamente, altrimenti lo stato è condiviso e un attore non può leggere / modificare lo stato non associato, o dichiarare che una terza parte può modificare.
  2. Come gli attori inviano e ricevono messaggi.
    • Il tuo collega sembra credere che ciò sia possibile solo grazie a qualche forma di co-coordinatore. Questa non è una cattiva soluzione per gli attori vagamente accoppiati. Ma non è l'unico modo per organizzare la comunicazione.
    • I messaggi possono provenire da diversi flussi di messaggi come Rete, GUI, Database. Ognuno ha un diverso protocollo di messaggi, sottoscrizione e mezzi di cancellazione.
    • Un attore può avere più di un indirizzo su un determinato flusso di messaggi che gli consente di ricevere duplicati o persino di ricevere diversi set di eventi.
    • Il passaggio dei messaggi può essere realizzato con molti mezzi, inclusi i supporti senza perdita e perdita (TCP vs UDP)
    • È persino possibile utilizzare un buffer circolare Reader / Writer. Sebbene sia una struttura condivisa, tutti gli stati sono chiaramente di proprietà di uno e di un solo attore alla volta.
risposta data 02.01.2019 - 05:31
fonte
0

È difficile, ma posso vedere i tuoi colleghi.

Se consideri che un 'evento' di inserimento è entrato nel sistema da qualche input dell'utente, sembra effettivamente un sistema basato su eventi. Dove l'evento Input causa un'azione su db e cms. Ma in realtà il proprietario di quei dati potrebbe essere considerato l'utente. Quindi entrambi i sistemi possiedono i propri dati.

Ma se consideriamo un aggiornamento, effettuiamo un sottoinsieme di colonne su una singola riga, o forse molte righe. L'evento stesso dipende dai dati esistenti nel DB. Non è possibile aggiungere un altro consumatore che non ha ricevuto tutti gli eventi precedenti.

A mio avviso, la configurazione è più simile alla replica di un sistema basato su eventi.

Inoltre infastidisci ulteriormente le acque utilizzando Kafka, un database di streaming, piuttosto che una coda di messaggi.

Ovviamente non importa ciò che chiami, c'è qualche aspetto dei sistemi basati su eventi che desideri che il tuo sistema abbia?

    
risposta data 05.02.2018 - 20:09
fonte

Leggi altre domande sui tag

Dati di aggiornamento in background da redis a DB Come posso assicurarmi che un ramo venga duplicato nel mio sviluppo e nelle filiali principali in TFVC?