pattern di aggregazione dei dati per microservizi: feed giornaliero

Question

pattern di aggregazione dei dati per microservizi: feed giornaliero

#1 da (3 voti)
#2 da (0 voti)

2

Supponiamo che tu abbia la seguente applicazione: utenti possono far parte di diverse organizzazioni . Utenti diversi possono creare attività e progetti all'interno di un'organizzazione. In un'architettura di microservizi, ci sono tre servizi separati che gestiscono rispettivamente le attività, i progetti e le organizzazioni.

Ora, supponiamo di voler inviare una email giornaliera a tutti gli utenti che contengono tutte le attività nuove e completate e tutti i progetti nuovi e completati all'interno di un'organizzazione, una sorta di feed giornaliero.

Qual è l'approccio migliore per sviluppare questa funzionalità? Ritengo che l'utilizzo dell'API pubblica non si riduca bene, soprattutto perché le e-mail vengono generate tutte in una volta, e potrebbero potenzialmente essere un sacco di richieste, in linea con il numero di utenti e organizzazioni. Un altro approccio consiste nell'assegnare il servizio "email giornaliera" all'attività e agli eventi del progetto, archiviarli nel db e quindi svuotare il db quando viene inviata l'email (questo può essere facilmente ridisegnato lungo la linea). C'è uno svantaggio in questo? Ci sono altri modelli comuni?

rest microservices

posta Giacomo Tagliabue 04.08.2016 - 10:33

fonte

2 risposte

Leggi altre domande sui tag rest microservices

C'è qualche motivo tecnico per digitare typedef void? [chiuso] Diagramma di sequenza - destinatario sconosciuto di un messaggio

score 3 · Answer 1

What's the best approach to build out this feature? I feel that using the public apis won't scale well, especially because the emails are generated all at once, and it could potentially be a lot of requests

Una cosa a cui prestare attenzione è che non ci sono molte richieste , ma molte query , vale a dire letture. In un caso d'uso come questo, dove hai molto interesse per gli stessi dati, le cache possono essere molto efficaci.

Another approach is to have the "daily email" service subscribe to the task and project events, store them in its db and then flush the db when the email is sent (this can be easily mapreduced down the line).

Nelle cqrs , è comune pubblicare le letture da pre-compilate " proiezioni". Il vantaggio principale che ottieni da qualcosa di pre-costruito è la latenza migliorata, piuttosto che il ridimensionamento.

Una considerazione è se gli eventi del tuo dominio dovrebbero contenere o meno informazioni sufficienti per costruire le tue proiezioni. Udi Dahan parla di servizi come autorità tecnica ; tra l'altro, si ottiene un migliore disaccoppiamento tra i servizi se non si lascia che la perdita di stato "privata" attraversi il limite del microservizio.

Quindi, se stai pensando al tuo editore di posta elettronica come microservizio discreto dal tuo servizio progetti / attività, allora gli eventi pubblicati includeranno il tipo di evento e gli identificatori per le entità coinvolte, ma non tutti i dati interni.

<TaskCompleted id="12345"/>

Questo approccio comprende la composizione in modo leggermente diverso - il microservizio sottoscritto delega la presentazione dei dati a l'autorità tecnica, piuttosto che duplicazione dei dati aziendali grezzi tra due diversi servizi.

D'altra parte, se l'editore della posta elettronica fa parte dello stesso servizio della gestione delle attività, allora quella restrizione non può essere applicata.

score 0 · Answer 2

Another approach is to have the "daily email" service subscribe to the task and project events, store them in its db and then flush the db when the email is sent

Il mio primo pensiero è stato quello di interrogare i tuoi servizi tramite la loro API. Tuttavia quanto sopra sembra buono se si hanno tali eventi. Non è necessario estendere i servizi per supportare o ottimizzare le query in particolare per un report, non caricare ulteriore carico sui microservizi esistenti ed è possibile estendere il modello sopra a più report.

Come tale sembra un approccio molto adatto.

Forse non vuoi svuotare quel db, a proposito. Forse vuoi trattenere queste informazioni per un determinato periodo di tempo, per provvedere a controlli, interruzioni, ecc.?

Forse la mia unica preoccupazione per questi modelli è l'accoppiamento molto lento (ad esempio, stai ascoltando eventi e cosa succede quando i tuoi servizi perdono eventi a causa di errori di configurazione o simili?). È possibile attenuarlo con un'adeguata verifica, monitoraggio e gestione della configurazione (ad esempio, distribuendo tutti i servizi con lo stesso set di configurazione in modo tale che non sia possibile configurare il servizio A in modo diverso dal servizio B).