MQTT è un protocollo standard OASIS per le applicazioni dei dispositivi connessi che fornisce di messaggistica bidirezionale con un'architettura di broker pubblicazione e sottoscrizione. La Il protocollo MQTT è leggero per ridurre l'overhead di rete e i client MQTT sono molto piccole per ridurre al minimo l'uso di risorse sui dispositivi con vincoli. Una soluzione per le organizzazioni che vogliono supportare le applicazioni per dispositivi connessi su Google Cloud è eseguire un broker MQTT autonomo su Compute Engine o GKE. Per eseguire il deployment di un broker MQTT nella tua organizzazione, devi prendere diverse decisioni chiave che influiscono sull'architettura complessiva, in particolare sul bilanciamento del carico e sull'ambiente di deployment. Questo descrive un'architettura per il deployment di un broker MQTT, il nucleo in un deployment MQTT, su Google Cloud. Inoltre, descrive le decisioni che devi prendere durante il deployment di questo broker e il loro impatto sull'architettura.
Il presente documento fa parte di una serie di documenti che forniscono informazioni su IoT su Google Cloud. Gli altri documenti di questa serie includono quanto segue:
- Panoramica delle architetture di dispositivi connessi su Google Cloud
- Architettura autonoma del broker MQTT su Google Cloud (questo documento)
- Architettura del prodotto della piattaforma IoT su Google Cloud
- Best practice per l'esecuzione di un backend IoT su Google Cloud
- Dispositivo nell'architettura Pub/Sub a Google Cloud
- Best practice per il provisioning e la configurazione automatici di sistemi e server edge e bare metal
Il seguente diagramma mostra un'architettura di broker MQTT in esecuzione su Google Cloud.
L'architettura nell'immagine precedente è composta come segue:
- Il deployment del broker MQTT viene eseguito come cluster di tre istanze connesse al servizio Cloud Load Balancing. Per il bilanciatore del carico Cloud, puoi scegli da una di diversi prodotti di bilanciamento del carico, descritti più avanti in questo documento.
- Il cluster di broker include un archivio delle credenziali del dispositivo e un dispositivo di autenticazione e autorizzazione. Il cluster si connette e carichi di lavoro di backend tramite Dataflow o Pub/Sub.
- Sul lato client, i gateway perimetrali forniscono comunicazione bidirezionale tra dispositivi periferici e il cluster di broker MQTT tramite MQTT su TLS.
In genere, consigliamo di eseguire il deployment dell'applicazione di broker MQTT per questo in un cluster per la scalabilità. Fattori come la funzionalità di clustering, la gestione del cluster di scale-up e scale-down, la sincronizzazione dei dati e la gestione della partizione di rete vengono affrontati dalle implementazioni specifiche del broker (come HiveMQ, EMQX, VerneMQ, mosquito e altri).
Considerazioni e scelte dell'architettura
Le seguenti sezioni descrivono le diverse scelte architetturali e le considerazioni necessarie per un'architettura di broker MQTT autonoma; e l'impatto di queste scelte sull'architettura.
Dispositivi connessi
I dispositivi edge connessi a internet pubblicano i propri eventi di telemetria e altre informazioni al broker MQTT. Per implementare il broker MQTT autonomo: descritta in questo documento, il dispositivo deve disporre client MQTT, la chiave pubblica del certificato server per l'autenticazione TLS e necessarie per l'autenticazione con il broker MQTT.
Inoltre, i dispositivi edge in genere hanno connettori per sensori locali, sistemi di dati on-premise e altri dispositivi che non dispongono di accesso a internet o connettività IP. Ad esempio, il dispositivo periferico può fungere da gateway per altri dispositivi con vincoli locali connessi al gateway tramite BLE, a una rete di rete o a un altro protocollo Nearline. Una specifica dettagliata dell'architettura dei dispositivi connessi non rientra nell'ambito di questa guida.
Bilanciamento del carico
Nell'architettura, un servizio di bilanciamento del carico esterno è configurato tra la rete pubblica e il cluster del broker MQTT. Questo servizio offre diverse Importanti funzioni di networking, inclusa la distribuzione delle connessioni in entrata tra nodi di backend, crittografia delle sessioni e autenticazione.
Google Cloud supporta diversi tipi di bilanciatori del carico. Per scegliere il caricamento migliore per la tua architettura, considera quanto segue:
mTLS. mTLS gestisce sia la crittografia che i metodi di autenticazione mentre TLS standard gestisce solo la crittografia e richiede un dispositivo separato metodo di autenticazione:
- Se la tua applicazione utilizza mTLS per l'autenticazione del dispositivo e deve terminare il tunnel TLS, ti consigliamo di utilizzare un bilanciatore del carico di rete passthrough esterno o un bilanciatore del carico di rete proxy esterno con un proxy TCP di destinazione. I bilanciatori del carico di rete proxy esterni terminano la sessione TLS e eseguono il proxy della connessione al node broker, insieme a eventuali credenziali di autenticazione contenute nel messaggio. Se hai bisogno delle informazioni di connessione del client nell'ambito di autenticazione, puoi conservarlo nella connessione di backend l'attivazione del protocollo PROXY.
- Se la tua applicazione non utilizza mTLS, ti consigliamo di utilizzare un Bilanciatore del carico di rete proxy esterno con un proxy SSL di destinazione per trasferire l'elaborazione TLS e SSL esterna al bilanciatore del carico. I bilanciatori del carico di rete proxy esterni terminano la sessione TLS e eseguono il proxy della connessione al node broker, insieme a eventuali credenziali di autenticazione contenute nel messaggio. Se hai bisogno delle informazioni di connessione del client nell'ambito di autenticazione, puoi conservarlo nella connessione di backend l'attivazione del protocollo PROXY.
Endpoint HTTP(S). Se devi esporre endpoint HTTP(S), ti consigliamo di configurare un bilanciatore del carico delle applicazioni esterno separato per questi endpoint.
Per ulteriori informazioni sui tipi di bilanciatori del carico supportati da Cloud Load Balancing, consulta il riepilogo dei bilanciatori del carico Google Cloud.
Strategia di bilanciamento del carico
Qualsiasi servizio di bilanciamento del carico distribuisce le connessioni dai dispositivi edge ai nodi del cluster in base a uno di diversi algoritmi o modalità di bilanciamento. Per MQTT, affinità sessione la strategia di bilanciamento del carico è migliore di quella casuale il bilanciamento del carico. Poiché le connessioni client-server MQTT sono sessioni bidirezionali permanenti, lo stato viene mantenuto sul nodo broker che interrompe la connessione. In una configurazione in cluster, se un client si scollega e poi si ricollega a un altro nodo, lo stato della sessione viene spostato nel nuovo nodo, il che aumenta il carico sul cluster. Questo problema può essere evitato utilizzando del carico per affinità. Se i client cambiano spesso l'indirizzo IP, la connessione può interrompersi, ma nella maggior parte dei casi l'affinità sessione è migliore per MQTT. L'affinità delle sessioni è disponibile in tutti i prodotti Cloud Load Balancing.
Autenticazione del dispositivo e gestione delle credenziali
Le applicazioni del broker MQTT gestiscono l'autenticazione e il controllo dell'accesso dei dispositivi separatamente da Google Cloud. L'applicazione di un broker fornisce anche archivio credenziali e interfaccia di gestione. Il protocollo MQTT supporta l'autenticazione di base con nome utente e password nel pacchetto di connessione iniziale e questi campi vengono spesso utilizzati anche dalle implementazioni del broker per supportare altre forme di autenticazione come il certificato X.509 o l'autenticazione JWT. Inoltre, MQTT 5.0 aggiunge il supporto per i metodi di autenticazione avanzata che utilizzano con stile di risposta. Il metodo di autenticazione utilizzato dipende la scelta dell'applicazione di broker MQTT e il caso d'uso del dispositivo connesso.
Indipendentemente dal metodo di autenticazione utilizzato, l'intermediario gestisce un archivio credenziali del dispositivo. Questo archivio può essere in un database SQL locale o un flat file. Anche alcuni broker, tra cui HiveMQ e VerneMQ, supportano l'utilizzo di un servizio di database gestito come Cloud SQL. È necessario un servizio distinto per gestire il repository delle credenziali del dispositivo e gestire eventuali integrazioni con altri servizi di autenticazione come IAM. Lo sviluppo di questo servizio esula dall'ambito di questa guida.
Per ulteriori informazioni sull'autenticazione e sulla gestione delle credenziali, vedi Best practice per l'esecuzione di un backend IoT su Google Cloud.
Carichi di lavoro di backend
Il caso d'uso di qualsiasi dispositivo connesso include una o più applicazioni di backend che utilizzano i dati importati dai dispositivi connessi. A volte, queste applicazioni devono anche inviare comandi e aggiornamenti di configurazione ai dispositivi. Nell'architettura di broker MQTT autonoma di questo documento, i messaggi in entrata e i comandi in uscita vengono entrambi instradati tramite il broker MQTT. Esistono argomenti diversi all'interno della gerarchia degli argomenti dell'intermediario per distinguere tra i dati e i comandi.
Dati e comandi possono essere inviati tra il broker e le applicazioni di backend in in vari modi. Se l'applicazione stessa supporta MQTT o se può modificata per supportare MQTT, l'applicazione può sottoscrivere un abbonamento direttamente al broker in qualità di cliente. Questo approccio ti consente di utilizzare la funzionalità di messaggistica bidirezionale MQTT Pub/Sub direttamente utilizzando la tua applicazione per ricevere dati e inviare comandi ai dispositivi connessi.
Se la tua applicazione non supporta MQTT, sono disponibili diverse altre opzioni. Nella l'architettura descritta in questo documento, Apache Beam fornisce un driver MQTT, che consente l'integrazione bidirezionale con Dataflow e altri Beam deployment di machine learning. Molti broker dispongono anche di funzionalità di plug-in che supportano l'integrazione con servizi come Google Pub/Sub. In genere si tratta di integrazioni unidirezionali per l'integrazione dei dati, anche se alcuni broker supportano l'integrazione bidirezionale.
Casi d'uso
Un'architettura di broker MQTT è particolarmente adatta per i casi d'uso dei dispositivi descritti nelle sezioni seguenti.
Importazione di dati basata su standard da dispositivi eterogenei
Quando vuoi raccogliere e analizzare i dati di un parco di dispositivi eterogenei di grandi dimensioni, un broker MQTT è spesso una buona soluzione. Poiché MQTT è uno standard ampiamente adottato e implementato, molti dispositivi perimetrali ne supportano la funzionalità integrata e sono disponibili client MQTT leggeri per aggiungere il supporto MQTT ai dispositivi che non lo supportano. Anche il paradigma "pubblica e sottoscrivi" fa parte dello standard MQTT in modo che i dispositivi abilitati MQTT possano sfruttare questa architettura senza ulteriori interventi di implementazione. Al contrario, i dispositivi che si connettono a Pub/Sub devono implementare l'API Pub/Sub o utilizzare l'SDK Pub/Sub. Esecuzione di un broker MQTT conforme agli standard Google Cloud fornisce quindi una soluzione semplice per raccogliere i dati da un su un'ampia gamma di dispositivi.
Quando i tuoi dispositivi connessi non sono controllati dalla tua applicazione, ma da una terze parti, potresti non avere accesso al software di sistema del dispositivo e la gestione del dispositivo stesso sarebbe responsabilità dell'altra parte. In questo caso, ti consigliamo di eseguire un broker MQTT e di fornire le credenziali di autenticazione alla terza parte per configurare il canale di comunicazione dal dispositivo al cloud.
Comunicazione bidirezionale per l'integrazione di applicazioni multiparti
La funzionalità di messaggistica bidirezionale di MQTT lo rende molto adatto per un caso d'uso di applicazioni mobile multiparti, come la consegna di cibo su richiesta o un un'applicazione di chat web su larga scala. MQTT ha un overhead di protocollo basso, mentre MQTT e i clienti hanno un basso consumo di risorse. MQTT offre anche il routing Pubblichi e Abbonati, più livelli di qualità del servizio (QoS), conservazione dei messaggi integrata e un ampio supporto del protocollo. Un broker MQTT può essere il componente principale di una piattaforma di messaggistica scalabile per applicazioni di servizi on demand e casi d'uso simili.
Messaggistica integrata da bordo a cloud
Grazie alla standardizzazione e al basso overhead offerto da MQTT, può anche una buona soluzione per integrare la messaggistica on-premise e basata su cloud diverse applicazioni. Ad esempio, un operatore di una fabbrica può implementare più broker MQTT nell'ambiente on-premise per connettersi a sensori, macchine, gateway e altri dispositivi dietro il firewall. Il broker MQTT locale può gestire tutti Messaggistica di comando e controllo e telemetria bidirezionale per gli ambienti on-premise dell'infrastruttura. Il broker locale può anche essere collegato tramite abbonamento bidirezionale a un cluster di broker MQTT parallelo nel cloud, consentendo la comunicazione tra il cloud e l'ambiente edge senza esporre i dispositivi e i sistemi on-premise alla rete internet pubblica.
Passaggi successivi
- Scopri come connettere i dispositivi e creare applicazioni IoT su Google Cloud utilizzando Intelligent Products Essentials.
- Scopri di più sulle pratiche per il provisioning e la configurazione automatici delle sistemi e server bare metal.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.