MQTT vs sondeo: arquitectura a gran escala
Una arquitectura de sondeo que funciona bien para cincuenta dispositivos puede desmoronarse en silencio con cinco mil, y el arreglo suele ser arquitectónico y no un sondeo más rápido. MQTT y el sondeo tradicional conducido por el maestro representan dos maneras de mover datos de campo, y escalan de forma muy distinta. Esta página es para el arquitecto que dimensiona una flota creciente. Compara cómo se comporta cada una conforme sube el número de dispositivos, dónde gasta cada una el ancho de banda y el esfuerzo, y cuándo un modelo de publicación-suscripción se gana su lugar.
MQTT vs sondeo a escala en una línea: Elija una arquitectura MQTT de publicación-suscripción cuando una flota grande, geográficamente dispersa o de crecimiento rápido deba reportar a uno o muchos consumidores, porque cada dispositivo empuja sus cambios al broker una sola vez y cualquier número de suscriptores los recibe sin agregar carga de sondeo. Elija sondeo cuando la flota sea acotada, el maestro controle por completo los tiempos de solicitud y un modelo plano de solicitud-respuesta sea más simple de razonar. El pivote es el fan-out y el crecimiento: la carga del sondeo escala con dispositivos por consumidores, la de MQTT no.
Compare cómo escala cada una
En una arquitectura de sondeo, un maestro emite una solicitud a cada dispositivo y espera la respuesta, recorriendo una lista de sondeo. Agregue dispositivos y el ciclo se alarga o usted agrega maestros; agregue un segundo consumidor que también necesita los datos y este sondea por su cuenta o lee una caché compartida que usted ahora tiene que construir. En una arquitectura MQTT, cada dispositivo publica sus cambios a un broker, y cada consumidor interesado se suscribe; al dispositivo no le importa cuántos escuchan.
| Atributo | Sondeo | Publicación-suscripción MQTT |
|---|---|---|
| Quién inicia | El maestro solicita en un calendario | El dispositivo publica al cambiar |
| Carga vs número de dispositivos | Crece con la lista de sondeo | Crece solo con el tráfico real de cambios |
| Carga vs número de consumidores | Se multiplica o exige una caché compartida | Una publicación llega a todos los suscriptores |
| Ancho de banda con datos quietos | Sondeo completo de todos modos | Casi cero hasta que un valor cambia |
| Señal de vida | Un sondeo fallido delata al dispositivo muerto | Last will y keepalive delatan al desconectado |
| Acoplamiento central | El maestro debe alcanzar cada dispositivo | Los dispositivos alcanzan un broker |
MQTT desacopla a los productores de los consumidores a través del broker, que es lo que abarata el fan-out. La mecánica está en las guías de publicación-suscripción y de el broker MQTT.
La pega es que MQTT mueve los problemas, no los borra. Usted ahora opera y asegura un broker, diseña una jerarquía de tópicos y decide el QoS por flujo. El sondeo lo mantiene todo en el maestro sin broker que operar, al costo de escalar la carga con el tamaño de la lista de sondeo y el número de consumidores. Que esa disyuntiva favorezca a MQTT depende casi por completo de la escala y el fan-out.
Cuándo gana cada una
MQTT gana conforme la flota crece y más sistemas quieren los mismos datos. Si los dispositivos son numerosos, están repartidos en muchas redes y detrás de enlaces que usted no quiere sondear constantemente, que cada dispositivo empuje sus cambios a un broker es dramáticamente más eficiente que jalar de todos ellos. Gana todavía más cuando varios consumidores - un SCADA, un historiador, una tubería de analítica - necesitan el mismo flujo, porque una sola publicación los sirve a todos en lugar de que cada uno sondee por su cuenta. Emparejarlo con publicación por cambio mantiene el cable tranquilo, muy al estilo de reporte por excepción versus sondeo a nivel de dispositivo.
El sondeo gana cuando la flota es acotada y el control del maestro sobre los tiempos importa. Un conjunto modesto de dispositivos en una red confiable, donde usted quiere tiempos de solicitud determinísticos y un modelo mental simple, queda bien servido por el sondeo - no hay broker que operar y la falla de un sondeo es en sí una señal de vida limpia. El sondeo también gana donde un dispositivo simplemente no puede publicar y debe ser leído, que es la mayoría del equipo legado Modbus y DNP3; ahí usted sondea en el borde aunque publique hacia arriba.
La arquitectura escalada suele ser un híbrido: sondear los dispositivos legados en un gateway de borde, y luego publicar sus cambios hacia el norte por MQTT para que el lado empresarial escale por suscripción y no por sondeo. Eso le da el alcance de dispositivos del sondeo donde no tiene opción y el fan-out de MQTT donde el crecimiento realmente vive. La decisión es por capa, no por sistema.
Trampas a escala
La trampa del sondeo a escala es la inflación silenciosa del ciclo de sondeo: cada dispositivo que usted agrega alarga el ciclo, y eventualmente el dato más fresco tiene minutos de edad sin que nadie decidiera aceptarlo. Agregar maestros ayuda pero multiplica la superficie operativa, y atornillar un segundo consumidor a un sistema de sondeo lo tienta al sondeo duplicado que dobla la carga sobre el campo. Vigile el tiempo de ida y vuelta del sondeo SCADA conforme crece la lista, porque ahí es donde el techo se asoma primero.
La trampa de MQTT a escala es tratar el broker y el diseño de tópicos como ocurrencias tardías. Un espacio de tópicos plano o mal nombrado hace dolorosos las suscripciones y el control de acceso, el uso desmedido de mensajes retenidos infla la memoria, y un solo broker sin clúster se convierte en el cuello de botella de fan-out que usted intentaba evitar. Elegir un QoS sensato por flujo también importa, porque QoS 2 en todo compra garantías de orden que rara vez necesita a un costo que siempre paga. Diseñe la jerarquía de tópicos deliberadamente, como se cubre en la guía de jerarquía de tópicos y comodines MQTT.
En la práctica una plataforma en la nube como Merobix se sitúa del lado consumidor de cualquiera de los dos modelos - suscribiéndose a un broker MQTT o sondeando dispositivos y gateways - y presenta la flota como un solo conjunto de tags vivos. La elección de arquitectura trata de cómo los datos de campo llegan a esa frontera de forma eficiente a su escala, no de la plataforma. Sondee donde deba, publique donde crezca, y deje que la ruta conducida por cambios cargue el fan-out.
Preguntas frecuentes
¿MQTT siempre le gana al sondeo para flotas grandes?
Para fan-out y crecimiento, normalmente sí, pero no de forma automática. MQTT deja que cada dispositivo publique una vez y que cualquier número de consumidores se suscriba, así que la carga no se multiplica con el número de dispositivos o consumidores como con el sondeo. Pero MQTT agrega un broker que operar, un diseño de tópicos que acertar y decisiones de QoS que tomar. Si la flota es pequeña y acotada y el maestro controla bien los tiempos, el sondeo puede ser más simple sin broker que operar.
¿Puedo usar MQTT si mis dispositivos solo hablan Modbus?
Sí, a través de un gateway de borde. El gateway sondea los dispositivos Modbus localmente y luego publica sus cambios hacia el norte por MQTT, de modo que el lado empresarial escala por suscripción en lugar de por sondeo. Este híbrido es la arquitectura escalada común: usted conserva el sondeo donde el dispositivo lo obliga, y gana el fan-out de MQTT donde la flota realmente crece. El dispositivo nunca necesita hablar MQTT por sí mismo.
¿Qué se rompe primero cuando una arquitectura de sondeo escala?
El ciclo de sondeo. Cada dispositivo que usted agrega alarga el tiempo de leer la lista completa, así que el dato más fresco envejece en silencio hasta que el valor más nuevo tiene minutos de edad. Agregar un segundo consumidor tienta al sondeo duplicado que dobla la carga de campo. Vigilar el tiempo de ida y vuelta conforme crece la lista de sondeo muestra el techo acercándose antes de que la vejez de los datos se vuelva un problema visible en las pantallas.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.