Come creare un sistema di notifica in Azure

Question

Come creare un sistema di notifica in Azure

#1 da (0 voti)

4

Ho un sistema in esecuzione in Azure che accetta messaggi tramite un endpoint REST. Il cliente ha un certo numero di dispositivi che inviano alcuni dati ad esempio la temperatura e presentiamo questi dati in un'interfaccia web. La parte del sistema che accetta i messaggi è separata dal sito Web (microservizi!) Ma accede allo stesso database (non così microservizi?). Sto creando una nuova funzionalità che consente al cliente di impostare le notifiche. Ad esempio, il cliente definisce che se uno qualsiasi dei suoi dispositivi invia una temperatura superiore a 50 ° C, deve essere inviata un'e-mail. Le notifiche possono essere istantanee (o di periodo relativamente breve) o aggregate (giornaliera, mensile, ecc.).

Il modo in cui avevo costruito queste cose in passato su premessa consisteva nell'impostare un servizio Windows che esegue il polling del database che periodicamente ottiene le definizioni di notifica, ottiene i messaggi corrispondenti e invia le e-mail corrette sia istantanee che aggregate. Tuttavia qualcosa mi dice che in questo modo non è affatto nuvoloso. Dovrei usare una coda di messaggi, un bus di servizio o qualcos'altro? Se sì quale? Che dire delle notifiche aggregate? In caso contrario, qual è l'equivalente migliore di un servizio Windows in Azure oggi per il mio caso d'uso? Devo ancora usare un ruolo di lavoratore?

Si noti inoltre che in futuro i messaggi potrebbero essere estratti dal database relazionale e inserire una soluzione NoSQL e in pratica sono molto più complessi di un numero (l'endpoint REST esegue qualche elaborazione prima di memorizzarli nel DB) . L'endpoint REST ha accesso alle definizioni di notifica e potrebbe potenzialmente elaborare le notifiche in sé, ma vorrei evitarlo perché mi piace la netta separazione e la semplicità dei servizi separati che attualmente ho. Anche l'elaborazione del messaggio quando ricevuto non risolve il problema di aggregazione. Se è importante, ci aspettiamo un numero relativamente piccolo di utenti, ma un gran numero di messaggi e, si spera, un gran numero di dispositivi che inviano messaggi. Nel caso in cui non sia chiaro ci sono più utenti che ricevono ciascuno notifica per i propri dati.

architecture rest asp.net azure notifications

posta Stilgar 19.02.2016 - 08:29

fonte

1 risposta

Leggi altre domande sui tag architecture rest asp.net azure notifications

Gestione errori paradigmi [chiuso] Overflow Exception Checking Problem

score 0 · Accepted Answer

Abbiamo finito per implementare lo scenario "Servizio Windows" sapendo che non sarebbe stato scalabile, ma intendendo costruire una soluzione scalabile quando necessario. Con l'implementazione corrente, un processo Web esegue un'applicazione console che interroga il DB per tutte le definizioni di notifica, esegue query appropriate e invia e-mail. È facile da testare (basta eseguire l'app della console) e facile da implementare (i lavori Web vengono distribuiti con il sito Web). La parte migliore è che se optiamo per la soluzione scalabile, possiamo semplicemente rimuovere questa parte senza influire su alcun altro codice, poiché l'interfaccia utente e l'interfaccia del database di notifica non dipendono dal metodo di invio effettivo.

Abbiamo deciso di prendere in considerazione Stream Analytics perché Stream Analytics non è molto utile per le query in continua evoluzione. La modifica della query richiede il riavvio del lavoro di Stream Analytics. Mettere le definizioni di notifica nel lavoro è difficile. C'è qualcosa chiamato dati di addestramento che può essere usato ma non è molto adatto per questo caso.

Dopo aver implementato la soluzione, Microsoft ha lanciato le funzioni di Azure che a prima vista sembrano una buona idea. Non ho fatto una ricerca dettagliata perché a quel punto avevamo già una soluzione funzionante. Tendo a non gradire come le Funzioni separate tendano ad essere dal resto della base di codice e mi preoccupo della distribuzione. Immagino che ci siano soluzioni a questi problemi ma non erano nelle demo.

La soluzione scalabile che avevamo in mente e che valuterà di nuovo se avremo bisogno di ridimensionare funzionerebbe come segue: la parte di elaborazione dei messaggi manda ogni singolo messaggio in una coda azzurra. Un consumatore riceve i messaggi uno a uno e controlla se il messaggio è idoneo per qualsiasi notifica. In tal caso, viene inserito nell'elenco di bucket DocumentDB o Azure Tables accessibile in base agli ID di notifica. Un altro consumatore controlla periodicamente i bucket di notifica e invia tutti i messaggi ed elimina l'elenco dei bucket. La soluzione sembra scalabile perché possiamo aggiungere qualsiasi numero di consumatori di cui abbiamo bisogno e le code azzurre sono costruite per essere scalabili. Sembra che non ci sia una parte del collo di bottiglia. Ora, con le funzioni di Azure, possiamo sostituire parti di questo sistema con se risultano più adatte all'attività.

Naturalmente sono ancora aperto a critiche e altre idee.