Come evitare punti di errore critico?

Sfondo

Abbiamo un sacco di dispositivi GPS nei veicoli. Questi dispositivi devono comunicare con il nostro sistema. Per raggiungere questo obiettivo, dobbiamo analizzare i messaggi del dispositivo prima di procedere.

Quanto segue descrive la mia idea di architettura scalabile e resistente ai guasti.

Architettura

I dispositivi sono scatole nere che ci inviano buffer di dati via TCP ogni X secondi. Un tipico messaggio segue questa traiettoria:

1. Ogni dispositivo comunica con un server RabbitMQ (R1) con una coda persistente. In questo modo se qualcosa fallisce, nessun messaggio è perso.

2. R1 invia i messaggi al Parser Cluster dei messaggi (Cluster di criceti). Nome di fantasia per un gruppo di criceti che riceve un buffer di dati come input e genera un oggetto JSON che possiamo capire.

3. Hamster Cluster invia quindi i messaggi analizzati a un'altra coda persistente (R2), che ha le stesse proprietà di R1.

4. R2 quindi invia questi messaggi al Data Processing Cluster (Monkey Cluster) che fa il vero lavoro. Siamo dentro il nostro sistema ora. Il percorso termina.

Obiettivi

Gliobiettiviprincipaliquisonoavereunaarchitetturaconleseguentiproprietà:

1. scalabile.DobbiamoessereingradodireclutarealtriCricetieScimmiesequalcunodeinostriClusterstamorendo(anessunopiaccionoglianimalimorti!)

2. Failproof.Seunadatamacchinanelsistemafallisce,ilservizionondeveandaregiù.

Problemi/Domande

1. Comeprogettato,questosistemaha2punticriticidierrore:R1eR2.Sequestemacchinefalliscono,l'interosistemasiinterrompe.C'èunmodoperevitarediaverequestiduepunticriticidierrore?

2. ImieicolleghihannoargomentatoNGINX,chesupportaanche Connessioni TCP / UDP . Capisco che utilizzandolo, avremmo bilanciamento del carico tra le macchine di ciascun cluster. Tuttavia, sostituire i server Rabbit per i server NGINX avrebbe ancora 2 punti di errore critico. Questo potrebbe essere evitato?