Eclipse Hono unterstützt jetzt Apache Kafka für nahtloses Device-Messaging

Eclipse Hono ist ein Open-Source-Projekt zum Verbinden großer Mengen heterogener Geräte mit einem (Cloud-)Backend. Hono definiert Service-Interfaces, die einheitliche Kommunikation zwischen Geräten ermöglichen, die weit unterschiedliche Protokolle nutzen, sowie Business-Applikationen. Das Projekt existiert seit einiger Zeit und wird in Bosch IoT Device Management seit mehreren Jahren erfolgreich eingesetzt. Neu ist die Unterstützung von Apache Kafka für Messaging. Die resultierenden Vorteile und Änderungen in der Hono-Nutzung werden in diesem Artikel vorgestellt.

Von Geräten kommende Daten werden in Hono durch Protokoll-Adapter (z. B. für MQTT, HTTP, CoAP) in ein einheitliches Nachrichtenformat transformiert und an ein Messaging-System übergeben. Business-Applikationen lesen diese Nachrichten – entweder Telemetrie-Nachrichten oder Events – direkt vom Messaging-System (sie können auch Command and Control nutzen, um Nachrichten an Geräte zu senden und Antworten zu empfangen). Für Messaging, das nicht Teil von Hono ist, sondern extern bereitgestellt werden muss, wurde bisher das AMQP 1.0-Protokoll verwendet.

Seit Version 1.7 unterstützt Hono Apache Kafka für Messaging als Technical Preview. Ein Kernfeature von Hono ist die Definition und Implementierung von APIs zum Weiterleiten von Nachrichten zu und von einem Messaging-System. Da die API-Definitionen auf Messaging basieren und direkt von dessen Eigenschaften abhängen, ist die Unterstützung eines neuen Messaging-Systems eine fundamentale Innovation für Hono. Für alle Messaging-APIs in Hono (Telemetrie, Event und Command and Control) wurden neue Spezifikationen basierend auf Kafka erstellt, sowohl in Richtung Protokoll-Adapter als auch Business-Applikation. Dabei wurde darauf geachtet, dass sie sich so ähnlich wie möglich zu den AMQP-basierten APIs verhalten.

Vorteile

Apache Kafka ist eine verteilte Event-Streaming-Plattform, designed für sehr hohen Durchsatz bei bestimmten Garantien zur Nachrichtenreihenfolge. Sie passt hervorragend zu Honos Anforderungen an Messaging aus mehreren Gründen. Kernvorteile:

• Skalierung: Mehrere Kafka-Server laufen simultan als Cluster, der bei Bedarf erweitert werden kann. Kafka ist optimiert, um vielen Prozessen gleichzeitiges Schreiben und Lesen zu erlauben. Mit AMQP 1.0 können multiple Prozesse auch parallel Nachrichten von derselben Adresse konsumieren – dabei geht jedoch die Reihenfolge verloren.
• Nachrichtenreihenfolge: Ein Kernfeature von Kafka ist die Partitionierung von Daten mittels Partition Key, mit der sich Daten auswählen lassen, für die Reihenfolge gewahrt bleiben muss, und Daten, die parallel verarbeitet werden können. In Hono ermöglicht dies, einfach sicherzustellen, dass alle Events eines Geräts der Business-Applikation in korrekter Reihenfolge bereitgestellt werden. Telemetriedaten des Geräts können parallel verarbeitet werden, ihre Reihenfolge ist ebenfalls garantiert. Nachrichten aller anderen Geräte können parallel, komplett unabhängig konsumiert werden, sogar in multiplen Instanzen der Business-Applikation gleichzeitig.
• Breite Adoption: Kafka wird von vielen Unternehmen genutzt und von vielen anderen Technologien unterstützt. Mehrere Firmen bieten Kafka as a Service auf verschiedenen Cloud-Plattformen an. Dies erleichtert, Hono mit einem professionell betriebenen Messaging-System zu versorgen. Vendor Lock-in wird ebenfalls vermieden.

Änderungen

AMQP 1.0 ist ein Kommunikationsprotokoll, bei dem Peers miteinander verbinden, um Nachrichten auszutauschen. Im Gegensatz dazu besteht ein Kafka-Cluster aus Brokern, die das Schreiben (und Lesen) von Daten in persistenten Speicher koordinieren. Dieser Unterschied hat zwei Konsequenzen: Erstens ist eine Nachricht eine Weile abrufbar, bevor sie schließlich gelöscht wird. Um diesen Effekt in Hono mit AMQP zu erreichen, stellt man typischerweise einen separaten Message Broker bereit, wo Events gespeichert werden, um Message Loss zu vermeiden, falls die Business-Applikation temporär unavailable ist. Mit Kafka wird jede Nachricht gespeichert. Dies umfasst Telemetrie-Nachrichten (die Speicherzeit hängt jedoch von der Konfiguration der Telemetrie-Topics im Kafka-Cluster ab). Zweitens entkoppelt die Kommunikation via persistenten Speicher Sende- und Empfangsoperationen zeitlich: Der Protokoll-Adapter kann nicht mehr an das Gerät zurückmelden, ob aktuell kein Consumer verbunden ist. Stattdessen speichert er die Nachrichten einfach, ohne zu „wissen“, ob oder wann eine Business-Applikation sie lesen wird.

Ausprobieren

Bei der Installation von Hono müssen Sie entweder ein AMQP-Messaging-Netzwerk oder einen Kafka-Cluster deployen. Es besteht auch die Möglichkeit, Hono so zu konfigurieren, dass beide Messaging-Systeme genutzt werden. Dann kann jeder Tenant (eine Teilmenge von Geräten und Konfiguration) so konfiguriert werden, dass er entweder AMQP oder Kafka nutzt. Das Hono-Projekt stellt eine öffentlich zugängliche Sandbox-Umgebung im Internet bereit, wo Sie mit Hono mittels AMQP oder Kafka-basiertem Messaging experimentieren können.

Praktisches Beispiel

Im Folgenden führen wir Sie durch ein kleines Beispiel zur Nutzung Apache Kafka-basierten Messaging in der Hono Sandbox. Sie senden eine Telemetrie-Nachricht an den HTTP-Protokoll-Adapter und lesen sie dann vom Kafka-Cluster.

Wir simulieren ein internetfähiges Gerät durch Senden von HTTP-Kommandos von der Kommandozeile. Dafür nutzen wir das populäre Open-Source-Tool curl. Falls aktuell nicht installiert, beachten Sie die Installationsanweisungen auf der curl-Homepage. Zur Simulation der Business-Applikation nutzen wir Honos Kommandozeilen-Client, herunterladbar von der Hono-Download-Seite. Beachten Sie, dass Java in mindestens Version 11 installiert sein muss, um ihn auszuführen.

Sollte einer der unten gezeigten Befehle nicht funktionieren (was bei solchen Anleitungen immer passieren kann), verweisen Sie auf den Kafka Messaging Guide, wo die Erklärungen mehr Details abdecken.

Gerät registrieren

Zuerst müssen Sie einen neuen Tenant in der Sandbox erstellen, um andere Nutzer nicht zu stören. Der folgende Befehl erstellt einen Tenant mit zufälliger ID und konfiguriert ihn für Kafka-Messaging.

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

Die Ausgabe sollte etwa enthalten: {"id":"85f63e23-1b78-4156-8500-debcbd1a8d35"}.

Kopieren Sie diese ID und setzen Sie sie als Environment Variable:

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

Gerät für den Tenant registrieren:

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

und erneut die zurückgegebene ID als Environment Variable setzen:

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

Schließlich Passwort für das Gerät setzen:

$ 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

Nachricht senden

Da Sie ein Gerät registriert haben, können Sie Nachrichten senden und empfangen.

Öffnen Sie ein zweites Terminalfenster zum Empfangen. Gehen Sie in das Verzeichnis, wo Sie den Hono-Kommandozeilen-Client heruntergeladen haben. Starten Sie den Client mit folgendem Befehl, wobei Sie my-tenant durch die ID des soeben erstellten Tenants ersetzen:

# 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"

Der Client ist bereit zum Empfang, wenn die Ausgabe eine Zeile ähnlich der folgenden enthält:
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

Jetzt können Sie eine Nachricht von Ihrem simulierten Gerät an Hono senden. Wechseln Sie zurück zum ersten Terminalfenster. Der folgende Befehl sendet eine Telemetrie-Nachricht an den HTTP-Protokoll-Adapter:

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

Die Nachricht sollte jetzt im zweiten Terminal ausgegeben werden.

Sie können auch ein Event senden:

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

Nun sollten Sie hoffentlich erfolgreich Nachrichten von einem Gerät an Hono gesendet und vom Kafka-Cluster empfangen haben. Als nächsten Schritt könnten Sie die detaillierteren Beispiele in Honos Kafka Messaging Guide ansehen. Er zeigt auch, wie Sie ein Command von der Business-Applikation an das Gerät senden und darauf antworten. Wenn Sie tiefer einsteigen wollen, schauen Sie sich die Spezifikationen der Kafka-basierten APIs in Honos API Specifications an.

Fazit

Das Messaging-System ist das Fundament für Eclipse Honos Kernfunktionalität, da dessen Interfaces darauf aufbauen. Kafka neben AMQP 1.0 zu unterstützen, ist eine sehr tiefgreifende Änderung für Hono, bei der großer Wert darauf gelegt wurde, dass Interfaces leicht aufeinander abgebildet werden können. Die Kernvorteile von Kafka sind seine Skalierbarkeit, seine Ordnungsgarantien, seine breite Adoption und der Reichtum an kommerziellen Service-Angeboten. Die Hauptunterschiede zu AMQP-Messaging: Alle Nachrichtentypen werden gebrokt. Das bedeutet, Nachrichten können zugestellt werden, selbst wenn der Empfänger kurzzeitig disconnected war. Die Kommunikation ist auch zeitlich entkoppelt, sodass direktes Feedback vom Empfänger an den Sender einer Nachricht nicht mehr möglich ist. In einem kurzen praktischen Beispiel zeigten wir, wie man Nachrichten von einem simulierten Gerät an die Hono Sandbox sendet und sie vom Kafka-Cluster konsumiert.