Considerazioni sulla progettazione MQTT rispetto a MQ

Question

Non ho una query specifica qui; solo bisogno di alcune linee guida di progettazione.

Mi sono imbattuto in questo articolo su Node.js , MQTT and Websockets. Suppongo di poter raggiungere uno scopo simile usando Node/Java + ActiveMQ + Websockets. La mia domanda è come selezionare tra MQ e MQTT? Posso usare tranquillamente un server "aperto" come mosquitto in un progetto di scala medio-grande, rispetto ad ActiveMQ?

10 ha avuto alcune intuizioni, e sembra che dovrei usare sia MQ che MQTT, poiché MQTT potrebbe essere di aiuto se ottengo client leggeri in futuro.

Grazie!

Answer 1

Aggiungendo a ciò che ha detto Shashi, questi hanno capacità diverse e casi d'uso.

MQTT definisce un protocollo di filo standard per pub/sub e, come notato da Shashi, è progettato per ambienti molto leggeri. Come tale ha un formato di filo molto minimale, alcune qualità di base del servizio e un set di funzionalità di base.

tradizionale messaggio sistemi accodamento dall'altro sono generalmente proprietarie (sebbene AMQP vuole cambiare questa situazione), coprono sia point-to-point e pub/sub, offrire molte qualità di servizio e tendono ad avere un filo formato più pesante , anche se questo esiste per supportare set di funzionalità avanzate come indirizzamento di risposta, conversione del protocollo, ecc.

Un buon esempio di MQTT è dove si trovano gli endpoint in telefoni, tablet e set-top box. Questi hanno potenza minima, memoria e risorse di sistema. In genere le connessioni da questi rimangono MQTT e parlano tra loro o sono collegate a un MQ di classe enterprise in cui possono comunicare tra loro con applicazioni back-end. Ad esempio, un client di chat basato su MQTT potrebbe comunicare direttamente con un altro tramite il broker MQTT. In alternativa, un sistema di distribuzione dei contenuti basato su MQTT collegherebbe a una rete di messaggistica aziendale che ospitava gli annunci e altri contenuti da consegnare alle app in esecuzione su telefoni e tablet. Il back-end aziendale gestirà tutte le statistiche di pubblicazione degli annunci e visualizzazioni su cui si basano le fatturazioni e la sezione MQTT consente di spingere il contenuto con un consumo minimo di batteria o potenza sul dispositivo dell'utente finale.

Quindi MQTT viene utilizzato per sistemi embedded e dispositivi per utenti finali in cui la potenza, la larghezza di banda e la stabilità della rete sono problemi. Questo è spesso in combinazione con i tradizionali messaggi MQ, sebbene non abbia mai visto MQTT utilizzato come trasporto esclusivo per le applicazioni di messaggistica tradizionali. Presumibilmente, questo è dovuto al fatto che MQTT manca di alcune delle funzionalità più robuste come la correlazione dei messaggi, l'indirizzamento di risposta e l'indirizzamento point-to-point che sono stati fondamentali per la messaggistica per 20 anni.

Answer 2

Il protocollo MQTT è adatto per dispositivi di piccole dimensioni come sensori, telefoni cellulari ecc. Che hanno un ingombro di memoria ridotto. Questi dispositivi si trovano in genere in una rete fragile e in genere hanno una bassa potenza di calcolo.

Questi dispositivi si collegano a una rete back-end aziendale tramite il protocollo MQTT per l'invio e la ricezione di messaggi. Ad esempio, un sensore di temperatura in un oleodotto raccoglie la temperatura dell'olio che fluisce attraverso il tubo e lo invia al centro di controllo. In risposta, un messaggio di comando può essere inviato su MQTT a un altro dispositivo per ridurre/interrompere il flusso di olio attraverso quel tubo.

WebSphere MQ è in grado di inviare/ricevere messaggi ai/dai dispositivi MQTT. Pertanto, se si prevede di implementare una soluzione basata su messaggistica che coinvolge i sensori &, è possibile considerare MQ e MQTT.

HTH

Answer 3

Come già discusso, MQTT definisce un protocollo filo applicativo (ovvero, come le informazioni sono organizzate e quindi serializzate, prima di essere trasferite). Mosquitto, o qualsiasi altro broker MQTT, è solo un'implementazione di Hub and Spoke Integration Pattern, proprio come i broker basati su JMS e AMQP, la differenza consiste nel protocollo a livello di trasporto: AMQP definisce un protocollo di trasporto standardizzato, invece broker JMS come ActiveMQ definisce il proprio formato proprietario, ovvero lo OpenWire. Naturalmente, non implementazioni standard, come Mosquitto, implementano un protocollo di trasporto del filo proprietario (questo ha un impatto sull'interoperabilità, ma può essere una scelta migliore in termini di prestazioni).

Torna alla domanda. Broker come Mosquitto possono essere utilizzati in scenari reali, in base alle vostre esigenze in termini di scalabilità e affidabilità: normalmente, è necessario il clustering per assicurare i. Disponibilità, ii. Affidabilità e iii. Scalabilità. I broker hanno pensato a PAN (Private Area Netorks), normalmente non forniscono tali funzionalità (Out of The Box) - ActiveMQ lo fornisce.

Concludendo, tocca alle proprie esigenze di scegliere per voi la soluzione migliore.