Architetture realtime
Dal polling REST a una piattaforma realtime per dispositivi industriali
Le scelte architetturali di una transizione da REST a MQTT: persistenza prima della pubblicazione, riconciliazione dello stato e ingestione separata di conferme e telemetria.
Il punto di partenza
Obiettivo e vincoli
Passare da chiamate REST a messaggi MQTT cambia il modo in cui si osserva un comando. Il backend può aver salvato il nuovo valore mentre il dispositivo è ancora offline o in attesa di applicarlo. L’architettura distingue queste condizioni e mantiene separati stato desiderato, stato riportato e misure di campo.
- Obiettivo
- Abilitare comunicazioni realtime affidabili senza spezzare i processi esistenti.
- Vincolo
- Convivenza tra legacy REST, rollout selettivi e backend già operativo.
- Output
- Una piattaforma capace di propagare comandi, ricevere conferme e osservare lo stato del sistema.
Dal comando al feedback
Flusso operativo del sistema
1. Ingresso del comando
Il backend salva il desired; l’interfaccia può già mostrare la nuova richiesta come pendente.
2. Propagazione realtime
Il desired viene pubblicato sui canali del dispositivo e sul layer applicativo, con consumer e responsabilità distinti.
3. Feedback operativo
Reported e telemetria entrano in servizi dedicati: il primo riconcilia lo stato, la seconda porta misure ed eventi.
4. Osservabilità
Backlog, errori e freschezza dei dati consentono di localizzare ritardi tra broker, worker e backend.
01 / Approfondimento
Il limite delle chiamate sincrone
Nel percorso legacy, richiesta, risposta e aggiornamento del dato sono strettamente accoppiati. Con dispositivi intermittenti e dati continui, aspettare la risposta del campo complica sia il backend sia il frontend. Il layer MQTT introduce una propagazione asincrona, conservando le API REST dove continuano a servire.
02 / Approfondimento
Salvare l’intenzione prima di propagarla
Il backend mantiene il desired come dato applicativo. Per esempio, una modifica di configurazione può comparire subito nell’interfaccia come richiesta pendente. Solo il reported del dispositivo permette di confrontarla con lo stato dichiarato dal campo. Un publish o un acknowledgement del trasporto non equivalgono a quel confronto.
03 / Approfondimento
Separare conferme e misure
I worker di ingestione trattano reported e telemetria con responsabilità diverse. Il reported aggiorna la riconciliazione; la telemetria alimenta misure e storico. I messaggi non validi seguono un percorso di errore osservabile, invece di confondersi con i dati accettati.
04 / Approfondimento
Esporre al frontend uno stato elaborato
Le interfacce web e mobile ricevono un modello derivato dal backend: richiesta pendente, stato riportato e ultimo aggiornamento disponibile. Questo contratto evita che ogni frontend debba interpretare direttamente topic, payload e tempi dei dispositivi, e mantiene autorizzazioni e audit nel sistema applicativo.
05 / Approfondimento
Osservare i passaggi e introdurre il nuovo flusso
Backlog, dead letter queue e freschezza dei dati aiutano a distinguere un messaggio fermo nel broker da un errore di ingestione o da un dispositivo non sincronizzato. L’attivazione su gruppi selezionati consente di osservare questi punti, verificare le versioni e conservare il percorso legacy durante la transizione.
Architettura / Figure di ricerca
Gli schemi dell’architettura.
Le figure si adattano allo schermo. Apri lo schema originale per leggere i dettagli.
Figura 01
Dal polling al realtime
Convivenza con il legacy, backend come fonte affidabile e introduzione selettiva dei canali realtime.
Figura 02
Schema architetturale di alto livello
Separazione tra layer device, backbone event-driven, worker di integrazione e canali applicativi dedicati al frontend.
Figura 03
Vista di controllo e supervisione
Il sistema distingue il piano dei comandi, quello della telemetria e quello dell'osservabilità, riducendo l'accoppiamento tra servizi.
Da portare nel progetto
Le scelte principali.
- Migrazione graduale da REST legacy a backbone MQTT
- Canali distinti per desired, reported e telemetria applicativa
- Monitoraggio end-to-end con broker, queue e servizi backend
- Stato applicativo derivato per le interfacce web e mobile