IOT et industrie : Cas d'utilisation de Confluent, MQTT et Apache Kafka Power Real-Time IoT

Avec des milliards d'appareils Internet des objets (IoT), la réalisation de l'interopérabilité en temps réel est devenue un défi majeur. Ensemble, Confluent, Waterstream et MQTT accélèrent l'Industrie 4.0 avec de nouveaux cas d'utilisation de l'IoT industriel (IIoT) et de l'IoT grand public (CIoT), révolutionnant la façon dont les entreprises fabriquent et utilisent des machines, des appareils et d'autres composants connectés.
Cet article de blog examine l'IoT, sa relation avec la norme MQTT et les options d'intégration de MQTT avec Apache Kafka® et Confluent Cloud, y compris une nouvelle implémentation native Kafka d'un courtier MQTT.
Cas d'utilisation pour l'IoT et le streaming d'événements avec Apache Kafka
Commençons par un aperçu d'une variété d'exemples CIoT et IIoT / Industrie 4.0 pour voir comment cela fonctionne

Lyft: corrélation des événements des conducteurs, des invités et des systèmes backend tels que le CRM, le service météo, les informations sur le trafic et le fournisseur de paiement pour calculer les itinéraires, l'heure d'arrivée estimée, le coût estimé, etc.
Audi: infrastructure de voiture connectée pour l'ingestion, le traitement et l'analyse en temps réel des événements pour l'après-vente et d'autres cas d'utilisation liés aux clients
Bosch: alertes en temps réel et nouveaux tableaux de bord en temps réel qui fusionnent et présentent les données des usines de fabrication, des concessionnaires, des propriétaires d'outils et d'autres sources de l'entreprise.
Deutsche Bahn: connectivité à différentes technologies, telles que les systèmes de messagerie, les bases de données et les fichiers pour corréler les événements pour le calcul et l'affichage des informations sur les trains en temps réel, les retards et les annulations sur les applications mobiles, les écrans de gare et d'autres interfaces
Eon: plate-forme cloud IoT pour intégrer et corréler les données des applications internes, des maisons intelligentes, des réseaux intelligents et des systèmes partenaires, fournissant une infrastructure en temps réel pour la distribution d'énergie
Severstal: analyse en temps réel à la périphérie pour des améliorations de qualité et une maintenance prédictive dans les lignes de production en usine.

Tous partagent les exigences suivantes:

Intégration et traitement des données en temps réel
Déploiements critiques, 24h / 24 et 7j / 7 sans temps d'arrêt
Traitement à grande échelle des événements de centaines de milliers, voire de millions d'utilisateurs et d'interfaces machines et appareils

Ces exemples utilisent différentes architectures et infrastructures pour l'edge computing, les déploiements hybrides et le cloud computing. Kafka et son écosystème sont au cœur de tous ces déploiements. Nous constatons cette tendance dans de nombreux secteurs, notamment l'automobile, la fabrication, l'énergie, le pétrole et le gaz, la logistique, etc.
Pour comprendre l'architecture de déploiement pour Kafka et IoT plus en détail, veuillez consulter les modèles d'architecture pour les déploiements Apache Kafka distribués, hybrides, en périphérie et globaux et Apache Kafka est le nouveau noir à la périphérie de l'IoT industriel, de la logistique et de la vente au détail. Pour un aperçu général des cas d'utilisation et des architectures pour le streaming d'événements dans les cas d'utilisation de l'IoT, veuillez consulter la présentation suivante: Introduction à l'IoT avec Apache Kafka et Event Streaming.Standards and Protocols for IoT Scenarios.
Normes et protocoles pour les scénarios IoT
Plusieurs standards existent pour soutenir les projets IoT:

MQTT: la norme la plus pertinente prenant en charge de nombreux cas d'utilisation dans CIoT et IIoT. Conçu pour les réseaux peu fiables et des millions d'appareils.
OPC-UA: pour l'IoT industriel uniquement. La plupart des nouvelles machines, périphériques et intergiciels dans les environnements IIoT prennent en charge cette norme.
HTTP: communication synchrone avec les services Web REST. Bien compris, simple et pris en charge par presque tous les frameworks et produits. Ce n'est pas une norme IoT, mais souvent utilisé dans les projets IoT si des exigences de latence et d'évolutivité limitées sont données.
WebSocket: un canal de communication moderne en duplex intégral sur une seule connexion TCP. De plus en plus utilisé dans CIoT pour les applications en temps réel et évolutives pour remplacer les communications HTTP, qui ne sont pas évolutives et fonctionnent bien dans les grands déploiements.
Syslog, SNMP et plus: alors que les normes telles que MQTT et OPC-UA sont conçues pour résoudre des défis spécifiques de l'IoT, la plupart des infrastructures complètent ces normes avec d'autres technologies établies pour la journalisation, la surveillance et le dépannage.

MQTT est l'une des normes les plus importantes pour les projets IoT, à la fois en IIoT et CIoT.
MQTT et Apache Kafka
La plupart des projets IoT combinent MQTT et Kafka pour de bonnes raisons. L'architecture de haut niveau ressemble généralement à ceci:

D'un point de vue technique, MQTT n'est qu'un autre producteur et / ou consommateur. Kafka dissocie différents clients, applications et backends les uns des autres.

Les avantages et les inconvénients de MQTT (en tant que technologie standard de l'IoT) et les avantages et les inconvénients de Kafka (en tant que norme de facto pour une plate-forme de streaming d'événements) se correspondent de manière très complémentaire, ce qui montre clairement pourquoi les deux sont si souvent combinés. .
Avantages et inconvénients de MQTT
Avantages MQTT:

Poids léger
Prend en charge tous les langages de programmation
Conçu pour les scénarios de mauvaise connectivité / latence élevée (par exemple, les réseaux mobiles)
Évolutivité et disponibilité élevées *
Norme ISO
Protocole IoT le plus populaire

Contre MQTT:

Uniquement pub / sub, pas de traitement de flux
Traitement asynchrone (les clients peuvent être hors ligne pendant une longue période)
Pas de retraitement des événements

Avantages et inconvénients d'Apache Kafka (du point de vue de l'IoT)
Les pros de Kafka

Traitement de flux, pas seulement pub / sous
Haut débit
Grande échelle
La haute disponibilité
Stockage et mise en mémoire tampon à long terme
Retraitement des événements
Intégration forte d'autres technologies d'entreprise

Contre Kafka

Non conçu pour des dizaines de milliers de connexions
Nécessite un réseau stable et une bonne infrastructure
Pas de fonctionnalités spécifiques à l'IoT comme Keep Alive, Last Will ou Testament

Comme vous pouvez le voir, MQTT et Kafka fonctionnent parfaitement ensemble. Vous pouvez en savoir plus sur cette combinaison dans Bonnes pratiques pour la diffusion de données IoT avec MQTT et Apache Kafka.
Maintenance prédictive en temps réel pour 100000 voitures connectées avec MQTT et Kafka
La combinaison MQTT et le streaming d'événements permettent l'intégration, le traitement et l'analyse en temps réel des données IoT. Un cas d'utilisation pour MQTT et Kafka peut ressembler à ceci:

Dans cet exemple, nous voyons un pipeline d'intégration en temps réel pour diffuser les données de millions de voitures connectées via MQTT vers la plate-forme de streaming d'événements pour le streaming ETL, l'apprentissage automatique, le jumeau numérique, l'analyse de données volumineuses et d'autres cas d'utilisation.
Options d'intégration MQTT pour Apache Kafka, Confluent Platform et Confluent Cloud
Alors, quelles sont les différentes options pour l'implémentation et l'intégration de MQTT avec Apache Kafka?
De nombreuses options d'intégration existent pour l'intégration de MQTT à Kafka:

Kafka Connect + connecteurs source et récepteur Confluent MQTT + courtier MQTT: une option courante. Tirez parti des avantages de Kafka Connect pour une communication bidirectionnelle avec n'importe quel courtier MQTT conforme à la norme, y compris l'implémentation de référence Mosquitto (pour Hello World et les déploiements non critiques) ou une solution évolutive et testée au combat comme HiveMQ
Proxy Confluent MQTT: Une option très légère permettant une intégration directe entre les périphériques MQTT et un cluster Kafka. Pas besoin du tout d'un courtier MQTT. Les inconvénients sont l'ensemble de fonctionnalités limité et (au moment de la rédaction de cet article) aucune communication bidirectionnelle, mais juste l'ingestion de MQTT vers Kafka.
Intégration spécifique au fournisseur: certains fournisseurs proposent leurs propres intégrations entre leur courtier MQTT et Kafka. Par exemple, HiveMQ a son propre plugin Kafka pour la communication bidirectionnelle.
Implémentation native Kafka de MQTT: cette option ne nécessite pas d'intégration car le courtier MQTT s'exécute en tant qu'application Kafka se connectant à Kafka via les consommateurs et producteurs Kafka natifs.

Les compromis entre l'utilisation de Kafka Connect et MQTT Broker, Confluent MQTT Proxy ou Confluent REST Proxy sont abordés plus en détail dans cette présentation: Traitement des données IoT de bout en bout avec MQTT et Apache Kafka.
Trouver la bonne option pour votre problème et votre cas d'utilisation
Lors de l'évaluation de votre solution MQTT en conjonction avec Kafka, de nombreux facteurs doivent être pris en compte, car de nombreuses offres ont des limites. Par exemple, les offres cloud des principaux fournisseurs de cloud ne sont généralement pas des courtiers MQTT entièrement conformes, ont des ensembles de fonctionnalités limités et des caractéristiques d'évolutivité et de performances limitées.
Voici quelques autres aspects à vérifier:

Conformité MQTT
Prise en charge de la version 3.x ou 5.x de MQTT (les deux principales versions utilisées dans l'industrie)
Une mise en œuvre complète ou un ensemble de fonctionnalités limité qui manque l'un des éléments suivants: qualité de service (QoS), messages conservés, dernière volonté et testament, sessions persistantes, Keep Alive, prise de contrôle client, etc.
Communication unitaire ou bidirectionnelle entre MQTT et Kafka
Fonctions de sécurité telles que l'authentification, l'autorisation et le cryptage
Intégration Kafka (connecteur, plugin et natif Kafka)

Pour les cas d'utilisation à grande échelle, une implémentation de courtier MQTT dédiée et complète est la meilleure option. La question clé à vous poser est de savoir si vous souhaitez déployer un cluster MQTT distinct ou utiliser une implémentation native de Kafka.
L'apprentissage automatique en continu à l'échelle à partir de 100000 appareils IoT avec HiveMQ, Confluent et TensorFlow est un exemple de déploiement à grande échelle avec des clusters séparés pour MQTT et Kafka. Cette architecture est bien comprise et fonctionne bien dans le monde réel.
Cela dit, concentrons-nous maintenant sur une nouvelle option à évaluer: une implémentation de MQTT au-dessus de Kafka. Cela ajoute une autre option à comparer pour trouver la bonne architecture pour votre cas d'utilisation. Le principal avantage de cette option est que vous devez exploiter, maintenir et surveiller une seule infrastructure distribuée pour vos projets IoT critiques, car le courtier MQTT exécute Kafka de manière native en tant qu'application Kafka Streams, avec tous les avantages de Kafka sous le capot. (comme une haute disponibilité, un débit élevé, une faible latence, etc.).
Présentation de Waterstream: un courtier MQTT natif de Kafka
Vous avez maintenant une nouvelle option: Waterstream, qui est vérifié par Confluent et peut transformer votre cluster Kafka en un courtier MQTT complet. Il fonctionne comme une couche fine et bidirectionnelle entre les appareils Kafka et IoT. Il n’a pas de persistance intermédiaire et les messages des clients MQTT sont immédiatement écrits dans Kafka et vice versa. Dès que le message est récupéré de Kafka, il est envoyé aux clients MQTT. Tout l'état MQTT nécessaire (c'est-à-dire les abonnements, l'état des messages QoS au moins une fois et exactement une fois et les messages conservés) est également stocké dans Kafka – pas besoin de stockage supplémentaire.
Outre les fonctionnalités MQTT requises, Waterstream propose des fonctionnalités optionnelles (telles que WebSockets) et des fonctionnalités qui sortent du cadre de la spécification MQTT (telles que l'authentification X.509 et des règles d'autorisation flexibles basées sur l'identité X.509).
Waterstream évolue linéairement. Pour la plupart des opérations, ses nœuds ne dépendent pas les uns des autres, vous pouvez donc ajouter plus de machines si vous avez plus de clients à gérer. Avec 5 à 10 machines, il peut gérer des centaines de milliers de clients (voir évolutivité et performances pour plus de détails).
L'architecture de référence pour l'infrastructure IoT basée sur Kafka avec Waterstream peut ressembler à ceci:

Les appareils envoient la télémétrie à Waterstream via l'équilibreur de charge. Les nœuds Waterstream peuvent être ajoutés ou supprimés dynamiquement en fonction des besoins actuels. Ensuite, ces données sont transférées vers la rubrique Kafka et peuvent être utilisées par n'importe quel outil Kafka – il peut s'agir de code personnalisé utilisant un consommateur Kafka, Kafka Connect ou une application Kafka Streams. ksqlDB peut être utilisé pour enrichir les données à mesure qu'elles arrivent et renvoyer des suggestions aux périphériques. Un exemple vous avertit des stations-service les plus proches lorsque vous êtes dans un véhicule en mouvement avec peu de carburant. Les producteurs (comme une sorte de console de gestion) peuvent envoyer des commandes aux appareils via Kafka et Waterstream.
Parmi les solutions préexistantes, Confluent MQTT Proxy est le plus proche de Waterstream. Mais contrairement au proxy MQTT, Waterstream prend en charge la communication bidirectionnelle et persiste les sessions MQTT. Par conséquent, si un client MQTT se reconnecte à Waterstream après une défaillance d'un seul nœud, l'équilibreur de charge peut envoyer la demande à n'importe quel autre nœud sain, et ce nœud peut choisir une transmission de message non terminée avec QoS au moins une fois ou exactement une fois.
Par rapport au connecteur MQTT Kafka, Waterstream a moins de pièces mobiles – il n'a pas besoin d'un courtier MQTT externe déployé séparément car il s'agit d'un courtier complet lui-même (combiné avec Kafka, bien sûr). En outre, vous n’avez pas besoin de gérer les boucles de messages ou la situation malheureuse d’un sujet mappant un message de Kafka envoyé à un sujet MQTT à partir duquel le connecteur lit à nouveau et renvoie dans le même sujet Kafka.
Quels sont les meilleurs cas d'utilisation de Waterstream? La plus évidente est l'intégration étroite de vos appareils avec Kafka. Une fine couche entre Kafka et MQTT Waterstream assure la petite latence sur MQTT vers un chemin Kafka. Une autre raison d'utiliser Waterstream est un déploiement plus simple. Comme ses nœuds sont sans état, vous avez moins de pièces mobiles à configurer et vous pouvez facilement augmenter ou diminuer votre trafic à mesure que votre trafic augmente ou diminue. Les nœuds ne dépendent pas les uns des autres pour le traitement des messages, vous pouvez donc le mettre à l'échelle horizontalement pour gérer les cas d'utilisation typiques de l'IoT, qui nécessitent des centaines de milliers d'appareils.
Rien n'est gratuit, bien sûr. Toutes les communications MQTT dans Waterstream transitent par Kafka, même si elles sont censées passer d'un appareil à un autre, et il n'y a pas de traitement supplémentaire dans des installations centralisées comme ksqlDB comme prévu. Cela signifie que l'aller-retour du message prend plus de temps. Si vous avez seulement besoin d'envoyer un message d'un appareil à un autre, sans intégration avec Kafka, Waterstream peut avoir une latence plus élevée par rapport aux solutions traditionnelles.
Comment fonctionne Waterstream

Selon la configuration, Waterstream lit / écrit les messages MQTT depuis / vers une ou plusieurs rubriques Kafka en utilisant le nom de rubrique MQTT comme clé de message Kafka et la charge utile de message MQTT comme valeur de message Kafka. Pour chaque connexion MQTT, une session en mémoire est maintenue, qui garde une trace des aspects avec état, tels que l'état de transmission des messages au moins une fois ou exactement une fois, les abonnements, le message Last Will, les décalages des derniers messages consommés, etc.
Si la session est persistante (le client MQTT marque la «session de nettoyage» comme fausse), les modifications sont conservées dans la rubrique de session dans Kafka. Cela permet de transférer la session à une autre instance Waterstream si celle en cours échoue ou si le client MQTT se reconnecte et que l'équilibreur de charge la dirige vers l'autre instance. Lorsque le client se connecte à nouveau, le composant Kafka Streams sélectionne le dernier état de session de ce nœud ou d'un autre. La persistance de l'état MQTT dans Kafka et sa relecture en cas d'échec permet aux clients MQTT de réaliser une intégration de bout en bout, une seule fois si vous utilisez QoS 2 pour publier les messages et vous abonner aux rubriques, auquel cas, la reconnexion , le message MQTT inachevé terminera la publication et tous les messages manqués des abonnements seront remis dans l'ordre.
Étant donné que les règles de dénomination des sujets dans Kafka sont beaucoup plus strictes que dans MQTT, tous les sujets MQTT ne peuvent pas correspondre à un sujet Kafka. Par conséquent, une rubrique MQTT est représentée par une clé de message dans Kafka et une seule rubrique Kafka peut contenir des messages pour plusieurs rubriques MQTT. Waterstream prend en charge les règles de mappage de rubrique avec des caractères génériques de style MQTT.
Au-delà de cela, un sujet Kafka par défaut doit être configuré dans Waterstream, qui contient des messages provenant de sujets qui ne correspondent à aucune des règles de mappage. Par exemple, avec les règles kafkaTopic1: cars / speed / + et kafkaTopic2: cars / #, le sujet MQTT cars / speed / 1 est mappé sur kafkaTopic1, cars / location / 1, puis sur kafkaTopic2, cars / speed / 1/2 , trains / speed / 1 et le sujet par défaut.
Chaque fois qu'un client MQTT s'abonne à un modèle de rubrique MQTT, le consommateur Kafka du nœud Waterstream correspondant commence à lire les rubriques Kafka nécessaires pour couvrir ce modèle. En utilisant le mappage de notre exemple précédent, si le client s'abonne à cars / speed / +, alors seul kafkaTopics1 est consommé. Mais s'il s'abonne à cars / #, alors kafkaTopic1 et kafkaTopic2 sont consommés, et si trains / #, alors seulement le sujet par défaut.
Certaines mises en garde pour un abonnement MQTT subsistent. Si un nœud Waterstream utilise une rubrique Kafka, il doit lire les messages de toutes les partitions, car à partir du joker de rubrique MQTT (tel que voiture / vitesse / + ou trains / #), vous ne pouvez pas toujours dire quelles clés Kafka exactes regarder . Les sujets MQTT sont dynamiques; ils peuvent aller et venir à mesure que les nouveaux messages arrivent, donc Waterstream devrait vérifier chaque nouveau message dans les rubriques Kafka qui correspondent au modèle d'abonnement MQTT. Par conséquent, les sujets MQTT, qui sont destinés à être consommés séparément, doivent être mappés aux différents sujets Kafka. C'est le principe clé de la configuration de MQTT sur un mappage de rubriques Kafka afin d'obtenir les meilleures performances de lecture possibles.
Évolutivité et performances
Nous voulons évaluer combien de clients avec un débit de messages IoT raisonnable que Waterstream peut prendre en charge par nœud et dans quelle mesure il évolue pour gérer un plus grand nombre de clients. Pour simuler la charge, nous avons développé un outil simple mais flexible qui est facile à exécuter dans différents environnements cloud (Kubernetes, GCP, etc.). Il est configuré pour publier un message avec un texte aléatoire toutes les 10 secondes. La longueur du message est choisie au hasard entre 400 et 600 octets.
Waterstream et le simulateur de charge sont déployés sur GCP: Waterstream sur les machines n1-standard-1 et n1-standard-2 (2 processeurs, 7,5 Go de RAM), et le simulateur de charge sur n1-standard-1 (1 processeur, 3,75 Go) RAM) machines. Pour plus de détails, consultez les éléments suivants:

Pour Kafka, nous avons utilisé Confluent Cloud, qui est le moyen le plus simple de le faire fonctionner et de le faire fonctionner sans aucun effort de notre part. Il est livré avec des outils pour visualiser et surveiller les sujets sous-jacents et le flux de données des producteurs aux consommateurs.

Avec chaque configuration de déploiement Waterstream, nous augmentons progressivement le nombre de clients dans le simulateur de charge et surveillons le tableau de bord Grafana. En examinant le nombre de connexions et le taux de publication de Kafka, nous déciderons si la configuration actuelle de Waterstream est suffisante pour un tel nombre de clients.

Courant d'eau
Simulateur de charge
Résultats

Nombre de nœuds
Tas
Nombre de nœuds
Clients par nœud
Connexions réussies
Taux de publication Kafka (msg / s)

3
6000m
dix
20K
190 000
19K

5
6000m
dix
20K
200 000
20K

5
6000m
20
20K
400 000
40 000

5
6000m
30
20K
579 000
50 000

dix
6000m
30
20K
600 000
60 000

dix
6000m
40
20K
800 000
80 000

dix
6000m
50
20K
993 000
97 000

12
6000m
50
20K
1 000 000
100 000

12
6000m
60
20K
1 180 000
110 000

Les résultats en vert indiquent les cas où le système a bien géré la charge. Ceux en jaune indiquent où le système était sur le point de prendre du retard (jusqu'à 5% de connexions en moins que prévu).
Après avoir construit un graphique à partir de ces données, nous voyons une évolutivité presque linéaire:

Lors des dernières évaluations, 12 nœuds n1-standard-2 ont traité avec succès 1,18 million d'appareils simulés. Cela signifie qu'un nœud n1-standard-2 peut gérer environ 98 000 connexions MQTT.
MQTT, Waterstream et Kafka au bord
Alors que Waterstream et Kafka évoluent bien pour prendre en charge de grandes charges dans les grands centres de données, ils peuvent également évoluer vers de petits déploiements à la périphérie. Vous pouvez avoir un déploiement plus petit plus près des appareils, comme dans un bâtiment d'usine). Cela réduit la latence entre les appareils et Waterstream, aide à survivre aux pannes de connexion Internet temporaires et réduit les coûts de stockage. Vous n'aurez peut-être pas besoin d'envoyer toutes les données au centre de données, mais uniquement des enregistrements pré-filtrés ou pré-agrégés. Confluent Replicator peut pomper les données de ces petits déploiements à la périphérie vers le cluster plus grand, qui pourrait être géré par Confluent Cloud.

Pour aller à l'extrême, nous avons testé un déploiement sur un seul nœud n1-standard-1 dans GCP (1 processeur, 3,7 Go de RAM), qui contient Apache ZooKeeper, Kafka et Waterstream. Le même outil utilisé pour générer la charge pour les tests d'évolutivité a été utilisé, mais avec un seul nœud simulant 20 000 clients, chacun envoyant un message toutes les 10 secondes. Parmi ces clients, 14 000 ont réussi à se connecter, Waterstream écrivant 1 400 messages / seconde à Kafka. Vous trouverez ci-dessous un tableau de bord Grafana s'exécutant localement, en récupérant les données de Waterstream, qui s'exécute sur un nœud GCP.

Bien entendu, avec un seul nœud, vous ne bénéficiez pas d'une haute disponibilité et vous risquez de subir des temps d'arrêt. Les déploiements périphériques réels iront rarement aussi loin et doivent choisir la taille et le nombre de nœuds en fonction de la disponibilité et des besoins de performances.
Démo en direct de Waterstream, Confluent Cloud et ksqlDB
Nous avons créé une démonstration en direct de Waterstream connectant des milliers d'appareils (virtuels) et en l'intégrant à Confluent Cloud et ksqlDB. Il simule une flotte de 15 000 camions circulant à travers l'Italie, qui envoient en permanence leur position à l'aide de messages MQTT.
À partir de la position actuelle, chaque camion est affecté à une destination aléatoire. L'itinéraire est calculé avec OpenStreetMap en utilisant un profil compatible avec un véhicule lourd. Une fois arrivé à destination, le camion s'arrête pendant un laps de temps aléatoire avant de redémarrer, simulant ainsi le repos du conducteur et la préparation d'une nouvelle charge.
La carte affiche un sous-ensemble des véhicules afin que vous puissiez les suivre à mesure qu'ils se déplacent. L'effet global est assez réaliste avec un flux fluide et fluctuant de messages présentés dans le tableau de bord Grafana intégré.
Chaque appareil est simulé avec un client MQTT qui envoie les données suivantes à Waterstream au format JSON:

La plaque utilisée comme identifiant du camion
La position actuelle
Le prochain waypoint
La vitesse actuelle
Un horodatage

Chaque camion utilise sa rubrique MQTT, qui consiste en la concaténation d'un préfixe fixe avec la plaque. Ces sujets sont mappés dans un seul sujet Kafka pour faciliter leur analyse.
L'interface utilisateur présente deux types d'informations extraites du sujet Kafka. Sur la carte, il y a 15 marqueurs montrant des véhicules en mouvement, tandis que sur la barre latérale, nous présentons une agrégation de la direction des camions partitionnée par des points cardinaux.

Voici comment les données voyagent à travers cette démo:

Le simulateur de véhicules envoie des données à Waterstream via MQTT, qui à son tour transmet les données à Kafka pour suivre les véhicules. ksqlDB traite ces informations et écrit les résultats dans une autre rubrique Kafka. Waterstream a des mappages pour ces deux sujets afin qu'il puisse les lire. L'interface utilisateur utilise MQTT sur WebSocket pour se connecter au Waterstream sans aucun intermédiaire. Les règles d'autorisation dans Waterstream sont configurées de manière à permettre un accès en lecture seule à l'interface utilisateur et des autorisations d'écriture sur le simulateur de véhicules.
Le code source de la démo est disponible sur GitHub.
Conclusion
Cet article de blog a présenté une nouvelle option pour combiner MQTT et Kafka: Waterstream, une implémentation de courtier MQTT natif Kafka tirant parti de Kafka Streams. Cela simplifie votre architecture de streaming d'événements, peu importe si votre déploiement est dans le cloud avec Confluent Cloud ou à la périphérie avec Confluent Platform.
Comme le prouvent sa conception et ses références, cette solution est évolutive, capable de se connecter à des centaines de milliers d'appareils MQTT et entièrement compatible MQTT avec une communication bidirectionnelle.
Pour démarrer avec Apache Kafka en tant que service, vous pouvez utiliser le code promo CL60BLOG pour 60 $ supplémentaires de Confluent Cloud gratuit et suivre le démarrage rapide. *

Kai Waehner travaille comme évangéliste de la technologie chez Confluent. Le principal domaine d'expertise de Kai se situe dans les domaines de l'analyse des mégadonnées, de l'apprentissage automatique, de l'intégration, des microservices, de l'Internet des objets, du traitement de flux et de la blockchain. Il est régulièrement conférencier lors de conférences internationales, telles que JavaOne, O’Reilly Software Architecture et ApacheCon, écrit des articles pour des revues professionnelles et aime écrire sur ses expériences avec les nouvelles technologies.

Paul Lysak est un développeur principal chez SimpleMatter, où il est responsable du développement de Waterstream, un courtier MQTT natif de Kafka. Depuis 13 ans, il développe des logiciels dans un large éventail d'industries, principalement sur JVM. Il est fan de systèmes réactifs et de programmation fonctionnelle.

Laisser un commentaire