Publicación y suscripción de mensajes MQTT mediante el corredor MQTT
Importante
Versión preliminar de operaciones de Azure IoT: habilitada por Azure Arc está actualmente en versión preliminar. No se debería usar este software en versión preliminar en entornos de producción.
Tendrá que implementar una nueva instalación de Operaciones de IoT de Azure cuando haya una versión disponible con carácter general. No podrá actualizar una instalación de versión preliminar.
Para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general, consulte los Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
Operations de IoT cuenta con un MQTT broker de grado empresarial conforme con los estándares, que es escalable, de alta disponibilidad y nativo de Kubernetes. Proporciona el plano de mensajería para Operaciones de IoT de Azure (versión preliminar), permite la comunicación perimetral bidireccional o en la nube y potencia aplicaciones controladas por eventos en el perímetro.
Conforme con MQTT
El Transporte de telemetría de cola de mensajes (MQTT) ha surgido como la lengua franca entre los protocolos del espacio de IoT. El diseño sencillo de MQTT permite que un único broker atienda a decenas de miles de clientes simultáneamente, con una creación y administración ligera de temas de publicación-suscripción. Muchos dispositivos IoT admiten MQTT de forma nativa sin necesidad de configuración, con la larga cola de protocolos de IoT que se racionalizan en MQTT mediante puertas de enlace de traducción posteriores.
El MQTT broker forma la base de la capa de mensajería en Operaciones de IoT y admite MQTT v3.1.1 y MQTT v5. Para obtener más información acerca de las características MQTT compatibles, consulte Compatibilidad de características MQTT en Corredor MQTT.
Alta disponibilidad y escalabilidad.
Kubernetes puede escalar las cargas de trabajo horizontalmente para ejecutarlas en varias instancias. Esta redundancia significa más capacidad para atender las solicitudes y confiabilidad en el caso de que cualquier instancia deje de funcionar. Kubernetes cuenta con recuperación automática integrada y las instancias se recuperan automáticamente.
Además de ser una tecnología de escalado flexible, Kubernetes es también un estándar para DevOps. Si MQTT es la lengua franca entre los protocolos de IoT, Kubernetes es la lengua franca para la capa de infraestructura informática. Al adoptar Kubernetes, puede usar las mismas herramientas, canalización de CI/CD, supervisión, empaquetado de aplicaciones y aptitudes de los empleados en todas partes. El resultado es un único sistema integral que abarca la informática en la nube, los servidores locales y las puertas de enlace de IoT más pequeñas de la planta de producción. Puede dedicar menos tiempo a la infraestructura o a DevOps y centrarse en su negocio.
Corredor MQTT se centra en el único valor de plano de datos nativo del perímetro que puede proporcionar al ecosistema de Kubernetes, al tiempo que se adapta perfectamente a él. Aporta un plano de plataforma de mensajería escalable y de alto rendimiento, así como una integración sin problemas con otras cargas de trabajo de Kubernetes escalables y Azure.
Seguro de forma predeterminada
Corredor MQTT se basa en los conceptos probados de identidad y seguridad nativos de Kubernetes y Azure, lo que hace que sea muy seguro y utilizable. Admite varios mecanismos de autenticación para aportar flexibilidad, junto con mecanismos de control de acceso pormenorizado hasta el nivel de tema de MQTT individual.
Sugerencia
Solo puede acceder a la implementación de corredor MQTT predeterminada mediante la dirección IP del clúster, TLS y un token de cuenta de servicio. Los clientes que se conectan fuera del clúster necesitan una configuración adicional para poder conectarse.
Integración de Azure Arc
La plataforma híbrida de Microsoft gira en torno a Kubernetes con Azure Arc como único plano de control. Proporciona un plano de administración que proyecta los recursos actuales que no son de Azure o que son del entorno local o de otras nubes en Azure Resource Manager. El resultado es un único panel de control para administrar las máquinas virtuales, los clústeres de Kubernetes y las bases de datos que no se ejecutan en centros de datos de Azure.
Corredor MQTT se implementa como una extensión de Azure Arc para Kubernetes y se puede administrar a través de un proveedor de recursos de Azure (RP) completo: microsoft/IoTOperationsMQ. Esto significa que puede administrarse igual que los recursos nativos en la nube de Azure, como máquinas virtuales, almacenamiento, etc.
La tecnología de Azure Arc permite que los cambios surtan efecto en los servicios de Corredor MQTT que se ejecutan en el clúster de Kubernetes local. Opcionalmente, si prefiere un enfoque totalmente nativo de Kubernetes, puede administrar Corredor MQTT con definiciones de recursos personalizados (CRD) de Kubernetes localmente o usando tecnologías de GitOps, como Flux.
Conectores de la nube
Es posible que tenga requisitos de mensajería diferentes para su escenario en la nube. Por ejemplo, una ruta de acceso rápida bidireccional en la nube o el perímetro para datos de alta prioridad o para alimentar paneles en la nube casi en tiempo real y una ruta de acceso lenta de menor costo para datos menos críticos en cuanto al tiempo que se pueden actualizar en lotes.
Para proporcionar flexibilidad, Corredor MQTT proporciona conectores de Azure integrados a Event Hubs (con el punto de conexión de Kafka), Funcionalidad de agente MQTT de Event Grid, Microsoft Fabric y Blob Storage. Corredor MQTT es extensible para que pueda elegir la solución de mensajería en la nube que prefiera y que funcione con su solución.
Al basarse en Azure Arc, permite configurar los conectores para usar la identidad administrada de Azure con el fin de acceder a los servicios en la nube con el eficaz control de acceso basado en rol (RBAC) de Azure. No se requiere ninguna administración manual, no segura y complicada de credenciales.
Modelo de programación de Dapr
Dapr simplifica la fontanería entre las aplicaciones distribuidas mediante la exposición de funcionalidad común de aplicaciones distribuidas, como la administración del estado, la invocación de servicio a servicio y la mensajería de publicación-suscripción. Los componentes de Dapr se basan en estos bloques de creación y proporcionan la implementación concreta de cada funcionalidad. Puede centrarse en la lógica de negocios y dejar que Dapr controle los detalles de las aplicaciones distribuidas.
Corredor MQTT proporciona bloques de creación de publicación-suscripción y almacenamiento de estados de Dapr conectables que hacen que el desarrollo y la implementación de aplicaciones controladas por eventos en el perímetro sean fáciles e independientes de la tecnología.
Arquitectura
El MQTT broker tiene tres capas:
- Capa de front-end sin estado que controla las solicitudes de los clientes.
- Equilibrador de carga que enruta las solicitudes y conecta el broker con otros.
- Capa de back-end con estado y particionada que almacena y procesa los datos.
La capa de back-end divide los datos por claves diferentes, como el identificador de cliente para las sesiones de cliente y el nombre del tema para los mensajes de tema. Usa la replicación en cadena para replicar los datos en cada partición. En el caso de los datos compartidos por todas las particiones, usa una única cadena que abarca todas las particiones.
Los objetivos de esta arquitectura son:
- Tolerancia a errores y aislamiento: la publicación de mensajes continúa si se produce un error en los nodos del back-end e impide que los errores se propaguen al resto del sistema.
- Recuperación de errores: recuperación automática de errores sin intervención del operador.
- Sin pérdida de mensajes: entrega de mensajes si se están ejecutando al menos un nodo del front-end y un nodo del back-end.
- Escalado flexible: escalado horizontal del procesamiento de publicación y suscripción para sustentar implementaciones perimetrales y en la nube.
- Rendimiento coherente a gran escala: limitar la sobrecarga de latencia de los mensajes debido a la replicación en cadena.
- Simplicidad operativa: dependencia mínima de los componentes externos para simplificar el mantenimiento y la complejidad.