Eclipse Hono supporte maintenant Apache Kafka pour messagerie device transparente

Eclipse Hono est un projet open-source pour connecter de grands nombres de devices hétérogènes à un backend (cloud). Hono définit des interfaces de service permettant une communication uniforme entre devices, qui peuvent utiliser des protocoles très différents, ainsi que les applications métier. Le projet existe depuis un moment et est utilisé avec succès dans Bosch IoT Device Management depuis plusieurs ans. La nouveauté : il supporte maintenant Apache Kafka pour la messagerie. Les bénéfices et changements d'usage de Hono sont présentés ici.

Les données venant des devices sont transformées dans Hono en format de message uniforme par des adaptateurs de protocole (ex. pour MQTT, HTTP, CoAP) et passées à un système de messagerie. Les applications métier lisent ces messages, qui sont soit des messages télémétrie soit des événements, directement depuis le système de messagerie (elles peuvent aussi utiliser Command and Control pour envoyer des messages aux devices et recevoir des réponses). Pour la messagerie, qui n'est pas partie de Hono mais doit être fournie en externe, le protocole AMQP 1.0 a été utilisé jusqu'ici.

Depuis la version 1.7, Hono supporte Apache Kafka pour la messagerie en technical preview. Une fonctionnalité clé de Hono est la définition et l'implémentation d'APIs pour forwarder messages vers et depuis un système de messagerie. Comme les définitions d'API sont basées sur la messagerie et dépendent directement de ses propriétés, supporter un nouveau système de messagerie est une innovation fondamentale pour Hono. Pour toutes les APIs de messagerie dans Hono (télémétrie, événement, et command and control), de nouvelles spécifications basées sur Kafka ont été créées, côté adaptateur de protocole comme côté application métier. On a veillé à ce qu'elles se comportent le plus possible comme les APIs basées AMQP.

Bénéfices

Apache Kafka est une plateforme de streaming d'événements distribuée conçue pour un débit très haut tout en fournissant certaines garanties sur l'ordre des messages. Elle correspond bien aux besoins de Hono pour plusieurs raisons. Bénéfices clés :

• Scaling : Plusieurs serveurs Kafka opèrent simultanément en cluster extensible. Kafka est optimisé pour permettre à de nombreux processus d'écrire et lire des données simultanément. Avec AMQP 1.0, plusieurs processus peuvent aussi consommer des messages de la même adresse en parallèle. Mais cela fait perdre leur ordre.
• Ordre des messages : Une fonctionnalité cœur de Kafka est le partitionnement des données via une clé de partition, qui permet de sélectionner les données dont l'ordre doit être maintenu et celles qui peuvent être traitées en parallèle. Dans Hono, cela permet d'assurer facilement que tous les événements d'un device sont fournis à l'application métier dans le bon ordre. Les données télémétrie du device peuvent être traitées en parallèle, et leur ordre est aussi garanti. Les messages de tous les autres devices peuvent être consommés en parallèle, complètement indépendamment, même en multiples instances de l'application métier utilisées concurremment.
• Adoption large : Kafka est utilisé par un grand nombre d'entreprises et supporté par beaucoup d'autres technologies. Plusieurs entreprises offrent Kafka as a service reservable sur diverses plateformes cloud. Cela facilite de fournir à Hono un système de messagerie opéré professionnellement. Le vendor lock-in est aussi évité.

Changements

AMQP 1.0 est un protocole de communication où des pairs se connectent pour échanger des messages. En contraste, un cluster Kafka consiste en brokers qui coordonnent l'écriture (et lecture) de données vers stockage permanent. Cette différence a deux conséquences : Premièrement, un message est disponible pour récupération un moment avant d'être éventuellement supprimé. Pour obtenir cet effet dans Hono avec AMQP, on fournit typiquement un message broker séparé où les événements sont stockés pour éviter la perte de messages si l'application métier est temporairement indisponible. Avec Kafka, chaque message est stocké. Cela inclut les messages télémétrie (le temps de stockage dépend cependant de la configuration des topics télémétrie dans le cluster Kafka). Deuxièmement, communiquer via stockage permanent découple les opérations d'envoi et réception : l'adaptateur de protocole ne peut plus reporter au device s'il n'y a actuellement aucun consommateur connecté. À la place, il stocke simplement les messages sans « savoir » si ou quand une application métier les lira.

L'essayer

En installant Hono, vous devez déployer soit un réseau de messagerie AMQP, soit un cluster Kafka. Il y a aussi la possibilité de configurer Hono pour utiliser les deux systèmes de messagerie. Alors, chaque tenant (sous-ensemble de devices et configuration) peut être configuré pour utiliser AMQP ou Kafka. Le projet Hono fournit un environnement sandbox accessible publiquement sur Internet où vous pouvez expérimenter Hono avec messagerie AMQP ou Kafka-based.

Exemple pratique

Dans ce qui suit, nous vous guidons à travers un petit exemple d'utilisation de la messagerie Apache Kafka-based dans le sandbox Hono. Vous enverrez un message télémétrie à l'adaptateur de protocole HTTP et le lirez depuis le cluster Kafka.

Nous simulons un device Internet-enabled en envoyant des commandes HTTP en ligne de commande. Pour cela, nous utilisons l'outil open-source populaire curl. Si pas installé sur votre ordinateur, référez-vous aux instructions d'installation sur la page d'accueil curl. Pour simuler l'application métier, nous utilisons le client ligne de commande Hono, téléchargeable depuis la page de téléchargement Hono. Notez que Java doit être installé en version 11 minimum pour l'exécuter.

Si l'une des commandes ci-dessous ne fonctionne pas (ce qui peut toujours arriver avec de telles instructions), référez-vous au Kafka Messaging Guide où les explications couvrent plus de détails.

Enregistrement d'un device

D'abord, vous devez créer un nouveau tenant dans le sandbox pour ne pas interférer avec d'autres utilisateurs. La commande suivante crée un tenant avec ID aléatoire et le configure pour utiliser Kafka pour la messagerie.

$ curl -i -H "content-type: application/json" --data-binary '{
 "ext": {
 "messaging-type": "kafka"
 }
}' https://hono.eclipseprojects.io:28080/v1/tenants

La sortie devrait contenir quelque chose comme : {"id":"85f63e23-1b78-4156-8500-debcbd1a8d35"}.

Copiez cet ID et définissez-le comme variable d'environnement :

$ export MY_TENANT=85f63e23-1b78-4156-8500-debcbd1a8d35

Enregistrez un device pour le tenant :

$ curl -i -X POST https://hono.eclipseprojects.io:28080/v1/devices/$MY_TENANT

et fournissez à nouveau l'ID retourné comme variable d'environnement :

$ export MY_DEVICE=4412abe2-f219-4099-ae14-b446604ae9c6

Finalement, définissez un mot de passe pour le device :

$ export MY_PWD=my-pwd
$ curl -i -X PUT -H "content-type: application/json" --data-binary '[{
 "type": "hashed-password",
 "auth-id": "'$MY_DEVICE'",
 "secrets": [{
 "pwd-plain": "'$MY_PWD'"
 }]
}]' https://hono.eclipseprojects.io:28080/v1/credentials/$MY_TENANT/$MY_DEVICE

Envoi d'un message

Maintenant que vous avez enregistré un device, vous pouvez envoyer et recevoir des messages.

Ouvrez une seconde fenêtre terminal pour recevoir les messages. Allez dans le répertoire où vous avez téléchargé le client ligne de commande Hono. Démarrez le client avec la commande suivante, en remplaçant my-tenant par l'ID du tenant que vous venez de créer :

# in directory where the hono-cli-*-exec.jar file has been downloaded to
$ java -jar hono-cli-*-exec.jar --spring.profiles.active=receiver,sandbox,kafka --tenant.id="my-tenant"

Le client est prêt à recevoir des messages si la sortie contient une ligne similaire à :
10:23:01.807 [vert.x-eventloop-thread-0] INFO org.eclipse.hono.cli.app.Receiver - Receiver [tenant: 85f63e23-1b78-4156-8500-debcbd1a8d35, mode: all] created successfully, hit ctrl-c to exit

Maintenant vous pouvez envoyer un message depuis votre device simulé vers Hono. Revenez à la première fenêtre terminal. La commande suivante envoie un message télémétrie à l'adaptateur de protocole HTTP :

$ curl -i -u $MY_DEVICE@$MY_TENANT:$MY_PWD -H "content-type: application/json" --data-binary '{"temp": 42}' https://hono.eclipseprojects.io:8080/telemetry

Le message devrait maintenant s'afficher dans le second terminal.

Vous pouvez aussi envoyer un événement :

$ curl -i -u $MY_DEVICE@$MY_TENANT:$MY_PWD -H "content-type: application/json" --data-binary '{"hello": "kafka"}' https://hono.eclipseprojects.io:8080/event

Maintenant vous avez, espérons-le, réussi à envoyer des messages d'un device vers Hono et les recevoir du cluster Kafka. Comme prochaine étape, vous pourriez regarder les exemples plus détaillés dans le Kafka Messaging Guide de Hono. Il montre aussi comment envoyer une commande depuis l'application métier vers le device et y répondre. Si vous voulez creuser, vous pourriez regarder les spécifications des APIs Kafka-based, trouvables dans les API Specifications de Hono.

Conclusion

Le système de messagerie est la fondation de la fonctionnalité cœur d'Eclipse Hono car ses interfaces sont fournies par-dessus. Supporter Kafka aux côtés d'AMQP 1.0 est un changement très profond pour Hono, où une grande emphase a été mise sur l'assurance que les interfaces peuvent être facilement mappées l'une à l'autre. Les bénéfices clés de Kafka sont sa scalabilité, ses garanties d'ordre, son adoption large, et la richesse d'offres de services commerciaux. Les principales différences avec la messagerie AMQP sont que tous les types de messages sont brokerés. Cela signifie que les messages peuvent être délivrés même si le destinataire était déconnecté un moment. La communication est aussi découplée dans le temps de sorte que le feedback direct du destinataire à l'expéditeur n'est plus possible. Dans un exemple pratique bref, nous vous avons montré comment envoyer des messages d'un device simulé vers le sandbox Hono et les consommer depuis le cluster Kafka.