Veröffentlichen und Abonnieren von MQTT-Nachrichten mit dem MQTT-Broker

Der standardkonforme MQTT-Broker auf Unternehmensniveau ist skalierbar, hochverfügbar und Kubernetes-nativ. Es stellt die Messagingebene für Azure IoT Einsatz (Vorschau) bereit, ermöglicht bidirektionale Edge-/Cloudkommunikation und unterstützt ereignisgesteuerte Anwendungen am Edge.

MQTT-konform

Der standardkonforme MQTT-Broker unterstützt sowohl MQTT v3.1.1 als auch MQTT v5.

Message Queue Telemetry Transport (MQTT) hat sich als Verkehrssprache zwischen Protokollen im IoT-Raum etabliert. Das einfache Design von MQTT ermöglicht es einem einzigen Broker, mehrere zehntausend Kund*innen gleichzeitig zu bedienen, mit einer einfachen Erstellung und Verwaltung von Veröffentlichen/Abonnieren-Themen. Viele IoT-Geräte unterstützen MQTT standardmäßig, wobei die meisten IoT-Protokolle durch nachgeschaltete Übersetzungsgateways in MQTT umgewandelt werden.

Der MQTT-Broker verwendet das MQTT-Protokoll als Grundlage für die Nachrichtenschicht. Weitere Informationen zu unterstützten MQTT-Features finden Sie unter MQTT-Featureunterstützung im MQTT-Broker.

Hochverfügbar und skalierbar

Kubernetes kann Workloads horizontal skalieren, die in mehreren Instanzen ausgeführt werden. Diese Redundanz bedeutet zusätzliche Kapazität zur Bearbeitung von Anforderungen und Zuverlässigkeit, falls eine Instanz ausfällt. Kubernetes verfügt über integrierte Selbstreparatur, und Instanzen werden automatisch wiederhergestellt.

Kubernetes ist nicht nur eine elastische Skalierungstechnologie, sondern auch ein Standard für DevOps. Wenn MQTT die Verkehrssprache unter den IoT-Protokollen ist, dann ist Kubernetes die Verkehrssprache für die Recheninfrastrukturschicht. Durch die Einführung von Kubernetes können Sie überall dieselbe CI/CD-Pipeline, dieselben Tools, dieselbe Überwachung, dieselbe App-Verpackung und dieselbe Mitarbeiterkompetenz verwenden. Das Ergebnis ist ein einziges End-to-End-System aus Cloud Computing, lokalen Servern und kleineren IoT-Gateways im Fertigungsbereich. Sie können weniger Zeit mit der Infrastruktur oder DevOps verbringen und sich auf Ihr Unternehmen konzentrieren.

Der MQTT-Broker konzentriert sich auf den einzigartigen edgenativen Datenebenenwert, der für das Kubernetes-Ökosystem bereitgestellt werden kann, und fügt sich nahtlos in dieses ein. Es bietet eine leistungsstarke und skalierbare Messaging-Plattformebene, die rund um MQTT aufgebaut ist, sowie eine nahtlose Integration in andere skalierbare Kubernetes-Workloads und Azure.

Standardmäßig sicher

Der MQTT-Broker baut auf den bewährten Sicherheits- und Identitätskonzepten von Azure und Kubernetes auf und ist damit äußerst sicher und benutzerfreundlich. Es unterstützt mehrere Authentifizierungsmechanismen für Flexibilität sowie differenzierte Zugriffssteuerungsmechanismen bis hin zu einzelnen MQTT-Themenebenen.

Azure Arc-Integration

Die Hybridplattform von Microsoft ist rund um Kubernetes mit Azure Arc als einzelne Steuerungsebene verankert. Sie stellt eine Verwaltungsebene bereit, die vorhandene Nicht-Azure-Ressourcen sowie lokale oder andere Cloudressourcen in Azure Resource Manager projiziert. Das Ergebnis ist ein einziger Steuerungsbereich zum Verwalten von VMs, Kubernetes-Clustern und Datenbanken, die nicht in Azure-Rechenzentren ausgeführt werden.

Der MQTT-Broker wird als Azure Arc für Kubernetes-Erweiterung bereitgestellt und kann über einen Azure-Ressourcenanbieter (RP) mit vollem Funktionsumfang verwaltet werden: microsoft/IoTOperationsMQ. Dies bedeutet, dass Sie es wie native Azure-Cloudressourcen wie VMs, Speicher usw. verwalten können.

Mit der Azure Arc-Technologie können die Änderungen für MQTT-Brokerdienste wirksam werden, die auf dem lokalen Kubernetes-Cluster ausgeführt werden. Wenn Sie einen vollständig Kubernetes-nativen Ansatz bevorzugen, können Sie den MQTT-Broker mit benutzerdefinierten Kubernetes-Ressourcendefinitionen (CRDs) lokal oder mit GitOps-Technologien wie Flux verwalten.

Cloudconnectors

Möglicherweise haben Sie unterschiedliche Messaginganforderungen für Ihr Cloudszenario. Dies könnte z. B. ein bidirektionaler schneller Cloud-/Edge-Pfad für Daten mit hoher Priorität oder zur Unterstützung von Clouddashboards in nahezu Echtzeit sein und ein kostengünstiger langsamer Pfad für weniger zeitkritische Daten, die in Batches aktualisiert werden können.

Um Flexibilität zu bieten, enthält der MQTT-Broker Azure-Connectors für Event Hubs (mit Kafka-Endpunkt), die MQTT-Brokerfunktion von Event Grid, Microsoft Fabric und Blob Storage. Der MQTT-Broker ist erweiterbar, sodass Sie Ihre bevorzugte Cloudmessaginglösung auswählen können, die mit Ihrer Lösung kompatibel ist.

Auf Azure Arc aufbauend können die Connectors so konfiguriert werden, dass sie eine verwaltete Azure-Identität für den Zugriff auf die Clouddienste mit der leistungsstarken rollenbasierten Zugriffssteuerung (RBAC) von Azure verwenden. Es ist keine manuelle, unsichere und umständliche Verwaltung von Anmeldeinformationen erforderlich.

Dapr-Programmiermodell

Dapr vereinfacht die Verknüpfung zwischen verteilten Anwendungen, indem allgemeine verteilte Anwendungsfunktionen wie Zustandsverwaltung, Dienst-zu-Dienst-Aufruf und Veröffentlichen/Abonnieren-Messaging verfügbar gemacht werden. Unterhalb der Bausteine befinden sich die Dapr-Komponenten, die die konkrete Implementierung für jede Funktion bereitstellen. Sie können sich auf die Geschäftslogik konzentrieren und Dapr die Details der verteilten Anwendung überlassen.

Der MQTT-Broker bietet austauschbare Dapr-Bausteine für Pub/Sub und Zustandsspeicher zur einfachen und technologieunabhängigen Entwicklung und Bereitstellung von ereignisgesteuerten Anwendungen am Edge.

Aufbau

Der MQTT Vermittler hat drei Ebenen:

• Zustandslose Front-End-Ebene, die Clientanforderungen verarbeitet
• Lastenausgleichsmodul, das Anforderungen weiterleitet und den Broker mit anderen verbindet
• Zustandsbehaftete und horizontal partitionierte Back-End-Ebene, die Daten speichert und verarbeitet

Die Back-End-Ebene partitioniert Daten nach verschiedenen Schlüsseln, z. B. Client-ID für Clientsitzungen, und Themenname für Themennachrichten. Sie verwendet die Kettenreplikation, um Daten innerhalb jeder Partition zu replizieren. Für Daten, die von allen Partitionen gemeinsam genutzt werden, wird eine einzige Kette verwendet, die alle Partitionen umfasst.

Die Ziele der Architektur sind:

• Fehlertoleranz und Isolation: Die Veröffentlichung von Nachrichten wird fortgesetzt, wenn Back-End-Knoten ausfallen und verhindert, dass Fehler an den Rest des Systems weitergegeben werden.
• Wiederherstellung nach Fehlern: Automatische Wiederherstellung nach Fehlern ohne Operatoreingriff
• Kein Nachrichtenverlust: Zustellung von Nachrichten, wenn mindestens ein Front-End-Knoten und ein Back-End-Knoten ausgeführt werden
• Elastische Skalierung: Horizontale Skalierung der Veröffentlichung und Abonnieren des Durchsatzes zur Unterstützung von Edge- und Cloudbereitstellungen
• Konsistente Leistung im großen Stil: Beschränkung des Latenzaufwands für Nachrichten aufgrund der Kettenreplikation
• Betriebliche Einfachheit: Minimale Abhängigkeit von externen Komponenten zur Vereinfachung der Wartung und Komplexität

Nächste Schritte

Bereitstellen von Azure IoT Einsatz (Preview) in einem Arc-fähigen Kubernetes-Cluster