¿Qué es un puente MQTT?

Volver al glosario

Un broker actuando como cliente de otro

Normalmente los clientes de un broker son dispositivos de borde y aplicaciones. Un puente es inusual porque uno de los clientes es a su vez otro broker. Cuando un broker de sitio se configura para puentear hacia un broker en la nube, el broker de sitio abre una conexión al broker en la nube igual que cualquier cliente, se autentica, y luego se suscribe a los tópicos que quiere jalar o publica los tópicos que quiere empujar. Para el broker en la nube, el broker de sitio entrante luce como un cliente ordinario bien comportado, y para los dispositivos del sitio nada cambia en absoluto.

Este arreglo permite a cada broker seguir haciendo su trabajo local mientras una porción definida del tráfico cruza entre ellos. Los dispositivos de un sitio publican hacia su broker local con baja latencia y sin depender del enlace de área amplia, y el puente retransmite en silencio los mensajes relevantes hacia adelante. Los dos brokers siguen siendo sistemas distintos, con sus propias sesiones, sus propios mensajes retenidos y sus propios suscriptores; el puente solo lleva los tópicos que se le indican, en la dirección que se le indica.

Un puente puede configurarse para mover datos en una dirección o en ambas. Un puente solo de subida reenvía la telemetría del sitio a la nube pero no jala nada, lo que conviene al monitoreo puro. Un puente bidireccional además permite al sistema central empujar comandos o consignas de regreso al sitio publicando en un tópico al que el broker de sitio se suscribió a través del puente. Qué tópicos fluyen en qué dirección es una parte explícita de la configuración del puente, no un espejeo automático de todo.

Reenvío selectivo y remapeo de tópicos

Un puente rara vez es una manguera que copia cada tópico. Más bien se configura con un conjunto de patrones de tópicos y una dirección para cada uno, de modo que solo el tráfico que necesita salir del sitio realmente lo haga. Un sitio podría reenviar sus tópicos de medición hacia arriba mientras conserva en casa la charla de diagnóstico puramente local, lo que mantiene magro el enlace de área amplia y evita enviar a la nube datos que no necesita. Esta selectividad es una de las razones principales por las que se prefiere un puente sobre apuntar cada dispositivo directamente a la nube.

Los puentes también suelen remapear tópicos al cruzar. Un dispositivo en un sitio podría publicar en un tópico local corto que no significa nada fuera de ese sitio, y el puente puede anteponerle un prefijo o reescribirlo para que, al llegar al broker en la nube, lleve la identidad del sitio, convirtiendo un nombre local en uno globalmente único. Esto permite a cada sitio usar una nomenclatura local sencilla mientras el sistema central ve una jerarquía limpia y con espacio de nombres en la que los datos de cada sitio aterrizan en su propia rama. El remapeo en dirección de bajada puede quitar ese prefijo otra vez para que los comandos lleguen al sitio bajo el nombre local que los dispositivos esperan.

Como el puente es un cliente normal del broker remoto, toda la mecánica ordinaria de MQTT aplica. Puede usar un nivel de calidad de servicio elegido para los mensajes reenviados, puede asegurarse con TLS y credenciales como cualquier otra conexión, y mantiene su propio estado de conexión. Si el enlace entre los dos brokers cae, el puente se comporta como cualquier cliente que perdió su conexión, reconectándose cuando puede, y un puente bien configurado combina esto con almacenamiento local para que los mensajes producidos durante la interrupción se reenvíen cuando el enlace regrese.

Almacenar en el sitio y empujar a la nube

El puente de broker-local-a-nube es una de las arquitecturas más comunes en la telemetría de campo, y con razón. Poner un broker en cada sitio da a los dispositivos un lugar cercano y siempre disponible para publicar, de modo que la adquisición sigue corriendo a toda velocidad incluso cuando el enlace de área amplia está degradado o caído. El puente luego lleva esos datos a la plataforma central cuando el enlace lo permite. El sitio se vuelve autosuficiente para la operación local, y la nube se vuelve el punto de agregación, sin que cada dispositivo tenga que administrar individualmente una frágil conexión de larga distancia.

Esta estructura se empareja de forma natural con el almacenamiento local. Cuando el enlace de retorno cae, el broker de sitio y su puente pueden retener mensajes y reenviar el rezago una vez restaurada la conectividad, de modo que una interrupción temporal produce un retraso en lugar de un hueco en el registro central. Los dispositivos que publican hacia el broker local quedan resguardados de la interrupción por completo, ya que hablan con algo en la misma red del sitio. El resultado es que el enlace de área amplia se convierte en un lugar donde la lentitud y las interrupciones se toleran, en vez de un lugar donde se pierden datos.

Para una plataforma SCADA en la nube como Merobix, el patrón de puente es una forma limpia de incorporar un sitio que ya corre su propio broker. El broker central en la nube recibe un solo flujo autenticado y remapeado de cada sitio en lugar de muchas conexiones de dispositivos individuales cruzando internet, lo que simplifica la seguridad y la nomenclatura. Los datos de cada sitio llegan bajo su propio espacio de nombres, listos para enrutarse hacia el historiador y las pantallas, mientras el control y la adquisición locales del sitio siguen corriendo con independencia de la salud del enlace a la nube.

Preguntas frecuentes