Architettura del sistema di avviso


10

Vorrei creare un sistema che gestisca i messaggi di avviso di vari programmi e che possa elaborare tali avvisi per i clienti deboli via e-mail. Tutto ciò sarebbe contenuto su un'unica rete interna.

Penso che voglio che l'architettura di base assomigli a qualcosa del genere:inserisci qui la descrizione dell'immagine

La preoccupazione principale che ho attualmente è il bit "Gestore messaggi", che sarà quello che sarà il mio "tipo di API". Voglio che tutti i componenti di questo sistema inviino dati all'API, che gestisce tutte le scritture nel database. Penso che questo approccio sia più semplice perché semplifica la sicurezza e mi consente di contenere molte delle query DB più complicate in un singolo programma.

La preoccupazione è che io voglia che questo sia agnostico sul linguaggio - nel senso che qualsiasi codice dovrebbe essere in grado di inviare messaggi al mio gestore - che li interpreterà. Spero di farlo tramite file flat JSON o tramite chiamate REST al programma (dando flessibilità alle applicazioni down-stream).

La mia domanda è-

Dovrei preoccuparmi del gestore dei messaggi - o aggiungerebbe semplicità per consentire l'accesso diretto al database alle applicazioni down-stream, nonché agli altri due componenti (Management Console e Gestione avvisi)?

In questo modo, possono inserire qualsiasi avviso desiderino, purché INSERT nella tabella o nelle tabelle DB sia valido.

Non sono un progettista di software commerciale quindi mi scusi - Voglio solo un progetto da realizzare nel mio tempo libero.

Risposte:


4

Hai esaminato AMQP (Advanced Message Queuing Protocol: https://www.rabbitmq.com/protocol.html )?

RabbitMQ è uno strumento fantastico per qualcosa del genere, penso (ce ne sono anche altri, MSMQ, servizi Azure / AWS, ecc.). Non solo ottieni un gestore di messaggi agnostico in una lingua (semplice "invia il messaggio al server dei messaggi con dati json"), ma rimuovi l'elaborazione dei messaggi a valle e lo rendi ben isolato. Esegui un servizio di messaggi che elabora i messaggi in arrivo dalle code necessarie e sputa le tue notifiche.

Uno dei motivi per cui mi piace davvero usare AMQP è che inizi come sei ora con una soluzione fatta in casa, ma ti rendi conto dopo che devi gestire i messaggi in modo leggermente diverso a seconda del tipo, a chi deve andare, ecc. , quindi alla fine essenzialmente costruendo la propria implementazione AMQP comunque.

Cosa fai se un messaggio deve andare a 5 destinatari diversi? Che cosa succede se si dispone di un messaggio che deve essere ruotato attraverso un numero di processori (pensare ad attività a lungo termine e con un numero X di processori simultanei, in cui è possibile eseguire il round robin di messaggi di un tipo specifico). Cosa succede se il messaggio deve essere indirizzato a una persona, ma se non è disponibile / online, dovrebbe essere indirizzato a un'altra? AMQP gestisce già tutto questo (abbastanza bene!), Con una categorizzazione molto bella, code, canali, persistenza duratura, ogni sorta di funzionalità.

Ecco una panoramica di base degli scenari che può gestire (nota che questo non è specifico di RabbitMQ: è una cosa AMQP, ma RabbitMQ sembra spiegarlo bene) - https://www.rabbitmq.com/getstarted.html


Ho già visto RabbitMQ implementato per altri software - mi è sempre sembrato interessante (se non un po 'complicato). Ci darò un'occhiata! Penso di essermi sfuggito all'inizio perché volevo molta flessibilità per offrire ai mittenti di dati. Quindi, se sarebbe difficile implementare una chiamata REST su un Powershell o Javascript esistente, o il cielo proibirebbe un'app VB6, di solito possono essere emessi su un file flat abbastanza facilmente. Ma essere in grado di sostituire solo un sacco di gestione dei messaggi ridurrebbe il tempo e lo sforzo di sicuro!
Christopher

2
Ero un po 'intimidito quando sono entrato per la prima volta in RabbitMQ, ma dopo un fine settimana di studio è stato come wow, questo è davvero molto bello, e ora che capisco quello che sto guardando, è davvero molto semplice
jleach

Mi piace l'idea di AMQP, ma il modo in cui RabbitMQ gestisce le API del client per ogni tipo di lingua sconfigge l'intero scopo dell'uso di un protocollo indipendente dalla lingua. Cosa succede se ho un client che esegue una lingua per la quale non è stata scritta un'API supportata? Alcune di queste funzioni sono davvero belle ... ma eccessivo quando tutto quello che devo fare è ottenere 1 messaggio dal punto A al punto B, senza nulla in mezzo.
Christopher

Stavo pensando di dare uno schiaffo a un'API di riposo rapido su di essa, che avrebbe coperto la tua preoccupazione agnostica, ma ho concordato che se non avessi mai bisogno di nessuna delle funzionalità offerte da AMQP, sarebbe eccessivo (scuse se ti avessi fatto correre selvaggio inseguimento d'oca ...)
jleach

Sì, un'API REST veloce per coprirla funzionerebbe .. ma poi potrei anche creare un'API REST tutta per me. E non sono necessarie scuse: è un'ottima tecnologia e l'apprendimento è essenziale per progredire :) se non ora, sono sicuro che tornerà utile in futuro.
Christopher

3

Domanda ben inquadrata!

Quindi, tutte le decisioni sull'architettura comportano compromessi. Se sei curioso di discutere di compromessi, modifica la tua domanda in quella direzione. Invece, poiché la domanda richiede solo una posizione, mi schierò dalla parte della discussione a favore di MessageHandler. Farò un ulteriore passo per suggerire di NON includere un database, almeno non un database SQL, almeno per non iniziare. Chiedi a MessageHandler di salvare JSON nel file system, pronuncia una directory all'ora degli avvisi ricevuti (a seconda del volume, ovviamente) e fai in modo che l'API, quando interrogata da Alert Manager, attraversi le ultime 2 directory di avvisi per decidere quali e-mail consegnare (a seconda della priorità, ovviamente).

C'è un sacco di cose buone da masticare in questo problema, e tenere un database fuori dall'immagine nelle prime fasi rimuoverà molto rumore accidentale e risoluzione di problemi inutili. Naturalmente, forse hai un amore nascosto per la creazione di modelli di dati relazionali e sogni di scrivere SQL. In tal caso, questa risposta è totalmente sbagliata. Ma in generale anche i database più agili sono terribili piattaforme applicative e vengono inclusi nei sistemi solo perché sono specialisti in termini di durabilità e query indicizzate.

In bocca al lupo!


1
Mi piace solo la capacità di controllare gruppi di e-mail, membri e varie altre cose interessanti sull'uso di un database relazionale. Il design del database è davvero quello che ho iniziato nel progetto, quindi non ho nemmeno pensato di rimuoverlo. Grazie per quel contributo e punto di vista !!
Christopher

Lo sapevo! :) Capire cosa stai davvero cercando di uscire da qualcosa è la cosa più importante. Saluti!
Jonah Benton,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.