Node.js-Tutorial: So erstellen Sie mit Kafka eine einfache ereignisgesteuerte Anwendung

Haben Sie sich schon einmal gefragt, wie einige Ihrer Lieblings-Apps mit Echtzeit-Updates umgehen? Live-Sportergebnisse, Börsenticker oder sogar Social-Media-Benachrichtigungen – sie alle verlassen sich auf ereignisgesteuerte Architekturen (EDA), um Daten sofort zu verarbeiten. EDA ist wie eine Unterhaltung, bei der jede neue Information eine sofortige Reaktion auslöst. Dadurch wird eine Anwendung interaktiver und reaktionsschneller.

In dieser Schritt-für-Schritt-Anleitung führen wir Sie durch die Erstellung einer einfachen ereignisgesteuerten Anwendung mit Apache Kafka auf Heroku. Wir behandeln:

• Einrichten eines Kafka-Clusters auf Heroku

• Erstellen einer Node.js-Anwendung, die Ereignisse erzeugt und nutzt

• Bereitstellen Ihrer Anwendung auf Heroku

Apache Kafka ist ein leistungsstarkes Tool zum Erstellen von EDA-Systemen. Es handelt sich um eine Open-Source-Plattform, die für die Verarbeitung von Echtzeit-Datenfeeds entwickelt wurde. Apache Kafka auf Heroku ist ein Heroku-Add-on, das Kafka als Dienst bereitstellt. Heroku macht das Bereitstellen und Verwalten von Anwendungen ziemlich einfach, und ich habe es in letzter Zeit häufiger in meinen Projekten verwendet. Die Kombination von Kafka mit Heroku vereinfacht den Einrichtungsprozess, wenn Sie eine ereignisgesteuerte Anwendung ausführen möchten.

Am Ende dieses Handbuchs verfügen Sie über eine lauffähige Anwendung, die die Leistungsfähigkeit von EDA mit Apache Kafka auf Heroku demonstriert. Legen wir los!

Erste Schritte

Bevor wir uns in den Code vertiefen, wollen wir kurz einige Kernkonzepte wiederholen. Wenn Sie diese verstanden haben, fällt es Ihnen leichter, den Code zu verstehen.

• Ereignisse sind Daten, die auf ein bestimmtes Vorkommnis im System hinweisen, wie etwa eine Temperaturmessung durch einen Sensor.

• Themen sind Kategorien oder Kanäle, in denen Ereignisse veröffentlicht werden. Betrachten Sie sie als die Themen, die Sie in einem Newsletter abonnieren.

• Produzenten sind die Entitäten, die Ereignisse erstellen und an Themen senden. In unserer Demo-EDA-Anwendung werden unsere Produzenten eine Reihe von Wettersensoren sein.

• Verbraucher sind die Entitäten, die Ereignisse aus Themen lesen und verarbeiten. Unsere Anwendung verfügt über einen Verbraucher, der auf Wetterdatenereignisse wartet und diese protokolliert.

Einführung in unsere Anwendung

Wir erstellen eine Node.js-Anwendung mithilfe der KafkaJS- Bibliothek. Hier ist ein kurzer Überblick über die Funktionsweise unserer Anwendung:

1. Unsere Wettersensoren (die Produzenten) generieren regelmäßig Daten – wie Temperatur, Luftfeuchtigkeit und Luftdruck – und senden diese Ereignisse an Apache Kafka. Zu Demozwecken werden die Daten zufällig generiert.

   
   

2. Wir lassen einen Verbraucher die Themen abhören. Wenn ein neues Ereignis empfangen wird, schreibt er die Daten in ein Protokoll.

   
   

3. Wir stellen das gesamte Setup auf Heroku bereit und verwenden Heroku-Protokolle, um die Ereignisse zu überwachen, während sie auftreten.

Voraussetzungen

Bevor wir beginnen, stellen Sie sicher, dass Sie Folgendes haben:

• Ein Heroku-Konto: Wenn Sie keines haben, melden Sie sich bei Heroku an.
• Heroku CLI: Laden Sie die Heroku CLI herunter und installieren Sie sie.
• Node.js muss zur Entwicklung auf Ihrem lokalen Computer installiert sein. Auf meinem Computer verwende ich Node (v.20.9.0) und npm (10.4.0).

Die Codebasis für dieses gesamte Projekt ist in diesem GitHub-Repository verfügbar. Sie können den Code gerne klonen und diesem Beitrag weiter folgen.

Nachdem wir nun die Grundlagen abgedeckt haben, richten wir unseren Kafka-Cluster auf Heroku ein und beginnen mit dem Aufbau.

Einrichten eines Kafka-Clusters auf Heroku

Lassen Sie uns alles auf Heroku einrichten. Das geht ziemlich schnell und einfach.

Schritt 1: Über die Heroku CLI anmelden

 ~/project$ heroku login

Schritt 2: Erstellen einer Heroku-App

 ~/project$ heroku create weather-eda

(Ich habe meine Heroku-App weather-eda genannt, aber Sie können für Ihre App einen eindeutigen Namen wählen.)

Schritt 3: Apache Kafka zum Heroku-Add-on hinzufügen

 ~/project$ heroku addons:create heroku-kafka:basic-0 Creating heroku-kafka:basic-0 on ⬢ weather-eda... ~$0.139/hour (max $100/month) The cluster should be available in a few minutes. Run `heroku kafka:wait` to wait until the cluster is ready. You can read more about managing Kafka at https://devcenter.heroku.com/articles/kafka-on-heroku#managing-kafka kafka-adjacent-07560 is being created in the background. The app will restart when complete... Use heroku addons:info kafka-adjacent-07560 to check creation progress Use heroku addons:docs heroku-kafka to view documentation

Weitere Informationen zum Add-on „Apache Kafka on Heroku“ finden Sie hier . Für unsere Demo füge ich die Stufe „Basic 0“ des Add-ons hinzu. Das Add-on kostet 0,139 USD/Stunde. Beim Erstellen dieser Demoanwendung habe ich das Add-on weniger als eine Stunde lang verwendet und es dann heruntergefahren.

Es dauert ein paar Minuten, bis Heroku Kafka hochgefahren und für Sie bereit hat. Schon bald werden Sie Folgendes sehen:

 ~/project$ heroku addons:info kafka-adjacent-07560 === kafka-adjacent-07560 Attachments: weather-eda::KAFKA Installed at: Mon May 27 2024 11:44:37 GMT-0700 (Mountain Standard Time) Max Price: $100/month Owning app: weather-eda Plan: heroku-kafka:basic-0 Price: ~$0.139/hour State: created

Schritt 4: Kafka-Anmeldeinformationen und -Konfigurationen abrufen

Nachdem unser Kafka-Cluster hochgefahren ist, müssen wir Anmeldeinformationen und andere Konfigurationen abrufen. Heroku erstellt mehrere Konfigurationsvariablen für unsere Anwendung und füllt sie mit Informationen aus dem gerade erstellten Kafka-Cluster. Wir können alle diese Konfigurationsvariablen anzeigen, indem wir Folgendes ausführen:

 ~/project$ heroku config === weather-eda Config Vars KAFKA_CLIENT_CERT: -----BEGIN CERTIFICATE----- MIIDQzCCAiugAwIBAgIBADANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQDDCdjYS1h ... -----END CERTIFICATE----- KAFKA_CLIENT_CERT_KEY: -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAsgv1oBiF4Az/IQsepHSh5pceL0XLy0uEAokD7ety9J0PTjj3 ... -----END RSA PRIVATE KEY----- KAFKA_PREFIX: columbia-68051. KAFKA_TRUSTED_CERT: -----BEGIN CERTIFICATE----- MIIDfzCCAmegAwIBAgIBADANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQDDCdjYS1h ... F+f3juViDqm4eLCZBAdoK/DnI4fFrNH3YzhAPdhoHOa8wi4= -----END CERTIFICATE----- KAFKA_URL: kafka+ssl://ec2-18-233-140-74.compute-1.amazonaws.com:9096,kafka+ssl://ec2-18-208-61-56.compute-1.amazonaws.com:9096...kafka+ssl://ec2-34-203-24-91.compute-1.amazonaws.com:9096

Wie Sie sehen, haben wir mehrere Konfigurationsvariablen. Wir benötigen eine Datei mit dem Namen .env in unserem Projektstammordner, die alle diese Konfigurationsvariablenwerte enthält. Dazu führen wir einfach den folgenden Befehl aus:

 ~/project$ heroku config --shell > .env

Unsere .env Datei sieht folgendermaßen aus:

 KAFKA_CLIENT_CERT="-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----" KAFKA_CLIENT_CERT_KEY="-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----" KAFKA_PREFIX="columbia-68051." KAFKA_TRUSTED_CERT="-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----" KAFKA_URL="kafka+ssl://ec2-18-233-140-74.compute-1.amazonaws.com:9096,kafka+ssl://ec2-18-208-61-56.compute-1.amazonaws.com:9096...kafka+ssl://ec2-34-203-24-91.compute-1.amazonaws.com:9096"

Außerdem stellen wir sicher, dass wir .env zu unserer .gitignore-Datei hinzufügen. Wir möchten diese sensiblen Daten nicht in unserem Repository speichern.

Schritt 5: Installieren Sie das Kafka-Plugin in der Heroku CLI

Die Heroku CLI enthält nicht automatisch Kafka-bezogene Befehle. Da wir Kafka verwenden, müssen wir das CLI-Plugin installieren .

 ~/project$ heroku plugins:install heroku-kafka Installing plugin heroku-kafka... installed v2.12.0

Jetzt können wir unseren Kafka-Cluster über die CLI verwalten.

 ~/project$ heroku kafka:info === KAFKA_URL Plan: heroku-kafka:basic-0 Status: available Version: 2.8.2 Created: 2024-05-27T18:44:38.023+00:00 Topics: [··········] 0 / 40 topics, see heroku kafka:topics Prefix: columbia-68051. Partitions: [··········] 0 / 240 partition replicas (partitions × replication factor) Messages: 0 messages/s Traffic: 0 bytes/s in / 0 bytes/s out Data Size: [··········] 0 bytes / 4.00 GB (0.00%) Add-on: kafka-adjacent-07560 ~/project$ heroku kafka:topics === Kafka Topics on KAFKA_URL No topics found on this Kafka cluster. Use heroku kafka:topics:create to create a topic (limit 40)

Schritt 6: Testen der Interaktion mit dem Cluster

Nur um die Plausibilität zu überprüfen, wollen wir ein bisschen mit unserem Kafka-Cluster herumspielen. Wir beginnen mit der Erstellung eines Themas.

 ~/project$ heroku kafka:topics:create test-topic-01 Creating topic test-topic-01 with compaction disabled and retention time 1 day on kafka-adjacent-07560... done Use `heroku kafka:topics:info test-topic-01` to monitor your topic. Your topic is using the prefix columbia-68051.. ~/project$ heroku kafka:topics:info test-topic-01 ▸ topic test-topic-01 is not available yet

Innerhalb von etwa einer Minute ist unser Thema verfügbar.

 ~/project$ heroku kafka:topics:info test-topic-01 === kafka-adjacent-07560 :: test-topic-01 Topic Prefix: columbia-68051. Producers: 0 messages/second (0 bytes/second) total Consumers: 0 bytes/second total Partitions: 8 partitions Replication Factor: 3 Compaction: Compaction is disabled for test-topic-01 Retention: 24 hours

Als Nächstes agieren wir in diesem Terminalfenster als Verbraucher und hören uns dieses Thema an, indem wir es verfolgen.

 ~/project$ heroku kafka:topics:tail test-topic-01

Von hier aus wartet das Terminal einfach auf alle zum Thema veröffentlichten Ereignisse.

In einem separaten Terminalfenster fungieren wir als Produzent und veröffentlichen einige Nachrichten zum Thema.

 ~/project$ heroku kafka:topics:write test-topic-01 "hello world!"

Zurück im Terminalfenster unseres Verbrauchers sehen wir Folgendes:

 ~/project$ heroku kafka:topics:tail test-topic-01 test-topic-01 0 0 12 hello world!

Ausgezeichnet! Wir haben erfolgreich ein Ereignis zu einem Thema in unserem Kafka-Cluster erstellt und verwendet. Wir sind bereit, mit unserer Node.js-Anwendung fortzufahren. Lassen Sie uns dieses Testthema zerstören, um unseren Spielplatz aufgeräumt zu halten.

 ~/project$ heroku kafka:topics:destroy test-topic-01 ▸ This command will affect the cluster: kafka-adjacent-07560, which is on weather-eda ▸ To proceed, type weather-eda or re-run this command with --confirm weather-eda > weather-eda Deleting topic test-topic-01... done Your topic has been marked for deletion, and will be removed from the cluster shortly ~/project$ heroku kafka:topics === Kafka Topics on KAFKA_URL No topics found on this Kafka cluster. Use heroku kafka:topics:create to create a topic (limit 40).

Schritt 7: Kafka für unsere Anwendung vorbereiten

Um unsere Anwendung für die Verwendung von Kafka vorzubereiten, müssen wir zwei Dinge erstellen: ein Thema und eine Verbrauchergruppe.

Lassen Sie uns das Thema erstellen, das unsere Anwendung verwenden wird.

 ~/project$ heroku kafka:topics:create weather-data

Als Nächstes erstellen wir die Verbrauchergruppe, zu der der Verbraucher unserer Anwendung gehören wird:

 ~/project$ heroku kafka:consumer-groups:create weather-consumers

Wir sind bereit, unsere Node.js-Anwendung zu erstellen!

Erstellen der Anwendung

Lassen Sie uns ein neues Projekt initialisieren und unsere Abhängigkeiten installieren.

 ~/project$ npm init -y ~/project$ npm install kafkajs dotenv @faker-js/faker pino pino-pretty

In unserem Projekt werden zwei Prozesse ausgeführt:

1. consumer.js , das das Thema abonniert hat und alle veröffentlichten Ereignisse protokolliert.

   
   

2. producer.js , das alle paar Sekunden einige zufällig ausgewählte Wetterdaten zu diesem Thema veröffentlicht.

Beide Prozesse müssen KafkaJS verwenden, um eine Verbindung zu unserem Kafka-Cluster herzustellen. Daher werden wir unseren Code modularisieren, um ihn wiederverwendbar zu machen.

Arbeiten mit dem Kafka-Client

Im Projektordner src erstellen wir eine Datei namens kafka.js . Sie sieht folgendermaßen aus:

 const { Kafka } = require('kafkajs'); const BROKER_URLS = process.env.KAFKA_URL.split(',').map(uri => uri.replace('kafka+ssl://','' )) const TOPIC = `${process.env.KAFKA_PREFIX}weather-data` const CONSUMER_GROUP = `${process.env.KAFKA_PREFIX}weather-consumers` const kafka = new Kafka({ clientId: 'weather-eda-app-nodejs-client', brokers: BROKER_URLS, ssl: { rejectUnauthorized: false, ca: process.env.KAFKA_TRUSTED_CERT, key: process.env.KAFKA_CLIENT_CERT_KEY, cert: process.env.KAFKA_CLIENT_CERT, }, }) const producer = async () => { const p = kafka.producer() await p.connect() return p; } const consumer = async () => { const c = kafka.consumer({ groupId: CONSUMER_GROUP, sessionTimeout: 30000 }) await c.connect() await c.subscribe({ topics: [TOPIC] }); return c; } module.exports = { producer, consumer, topic: TOPIC, groupId: CONSUMER_GROUP };

In dieser Datei beginnen wir mit der Erstellung eines neuen Kafka-Clients. Dies erfordert URLs für die Kafka-Broker, die wir aus der Variable KAFKA_URL in unserer .env Datei (die ursprünglich aus dem Aufruf der Heroku-Konfiguration stammt) analysieren können. Um den Verbindungsversuch zu authentifizieren, müssen wir KAFKA_TRUSTED_CERT , KAFKA_CLIENT_CERT_KEY und KAFKA_CLIENT_CERT angeben.

Dann erstellen wir aus unserem Kafka-Client einen producer und einen consumer und stellen sicher, dass unsere Konsumenten das Thema weather-data abonnieren.

Klarstellung zum Kafka-Präfix

Beachten Sie in kafka.js , dass wir unserem Thema und dem Namen unserer Verbrauchergruppe KAFKA_PREFIX voranstellen. Wir verwenden den Basic 0-Plan für Apache Kafka auf Heroku, einen Multi-Tenant-Kafka-Plan. Das bedeutet, dass wir mit einem KAFKA_PREFIX arbeiten . Obwohl wir unser Thema weather-data und unsere Verbrauchergruppe weather-consumers genannt haben, muss ihren tatsächlichen Namen in unserem Multi-Tenant-Kafka-Cluster das KAFKA_PREFIX vorangestellt werden (um sicherzustellen, dass sie eindeutig sind).

Technisch gesehen lautet der tatsächliche Themenname für unsere Demo also columbia-68051.weather-data und nicht weather-data . (Das Gleiche gilt für den Namen der Verbrauchergruppe.)

Der Produzentenprozess

Erstellen wir nun unseren Hintergrundprozess, der als Produzent unserer Wettersensoren fungieren wird. In unserem Projektstammordner haben wir eine Datei namens producer.js . Sie sieht folgendermaßen aus:

 require('dotenv').config(); const kafka = require('./src/kafka.js'); const { faker } = require('@faker-js/faker'); const SENSORS = ['sensor01','sensor02','sensor03','sensor04','sensor05']; const MAX_DELAY_MS = 20000; const READINGS = ['temperature','humidity','barometric_pressure']; const MAX_TEMP = 130; const MIN_PRESSURE = 2910; const PRESSURE_RANGE = 160; const getRandom = (arr) => arr[faker.number.int(arr.length - 1)]; const getRandomReading = { temperature: () => faker.number.int(MAX_TEMP) + (faker.number.int(100) / 100), humidity: () => faker.number.int(100) / 100, barometric_pressure: () => (MIN_PRESSURE + faker.number.int(PRESSURE_RANGE)) / 100 }; const sleep = (ms) => { return new Promise((resolve) => { setTimeout(resolve, ms); }); }; (async () => { const producer = await kafka.producer() while(true) { const sensor = getRandom(SENSORS) const reading = getRandom(READINGS) const value = getRandomReading[reading]() const data = { reading, value } await producer.send({ topic: kafka.topic, messages: [{ key: sensor, value: JSON.stringify(data) }] }) await sleep(faker.number.int(MAX_DELAY_MS)) } })()

Ein Großteil des Codes in der Datei beschäftigt sich mit der Generierung von Zufallswerten. Ich werde die wichtigen Teile hervorheben:

• Wir simulieren fünf verschiedene Wettersensoren. Ihre Namen finden Sie unter SENSORS .

• Ein Sensor gibt einen Wert für einen von drei möglichen Messwerten aus (veröffentlicht ihn): temperature , humidity oder barometric_pressure . Das Objekt getRandomReading verfügt für jeden dieser Messwerte über eine Funktion, um einen entsprechenden Wert zu generieren.

• Der gesamte Prozess wird als async Funktion mit einer unendlichen while Schleife ausgeführt.

Innerhalb der while Schleife führen wir Folgendes aus:

• Wählen Sie nach dem Zufallsprinzip einen sensor aus.
• Wählen Sie nach dem Zufallsprinzip eine reading aus.
• Generieren Sie einen value für diesen Messwert.
• Rufen Sie producer.send auf, um diese Daten im Thema zu veröffentlichen. Der sensor dient als key für das Ereignis, während der reading und value die Ereignisnachricht bilden.
• Dann warten wir bis zu 20 Sekunden vor der nächsten Iteration der Schleife.

Der Verbraucherprozess

Der Hintergrundprozess in consumer.js ist wesentlich einfacher.

 require('dotenv').config(); const logger = require('./src/logger.js'); const kafka = require('./src/kafka.js'); (async () => { const consumer = await kafka.consumer() await consumer.run({ eachMessage: async ({ topic, partition, message }) => { const sensorId = message.key.toString() const messageObj = JSON.parse(message.value.toString()) const logMessage = { sensorId } logMessage[messageObj.reading] = messageObj.value logger.info(logMessage) } }) })()

Unser consumer ist bereits beim Thema weather-data angemeldet. Wir rufen consumer.run auf und richten dann einen Handler für eachMessage ein. Immer wenn Kafka den consumer über eine Nachricht benachrichtigt, protokolliert es die Nachricht. Das ist alles, was dazu zu sagen ist.

Prozesse und das Procfile

In der Datei package.json müssen wir einige scripts hinzufügen, die unsere Produzenten- und Konsumenten-Hintergrundprozesse starten. Die Datei sollte nun Folgendes enthalten:

 ... "scripts": { "start": "echo 'do nothing'", "start:consumer": "node consumer.js", "start:producer": "node producer.js" }, ...

Die wichtigen sind start:consumer und start:producer . Aber wir behalten start in unserer Datei (obwohl es nichts Sinnvolles bewirkt), weil der Heroku-Builder erwartet, dass es dort ist.

Als nächstes erstellen wir ein Procfile , das Heroku mitteilt, wie die verschiedenen Worker gestartet werden, die wir für unsere Heroku-App benötigen. Im Stammordner unseres Projekts sollte das Procfile folgendermaßen aussehen:

 consumer_worker: npm run start:consumer producer_worker: npm run start:producer

Ganz einfach, oder? Wir haben einen Hintergrundprozess-Worker namens consumer_worker und einen anderen namens producer_worker . Sie werden feststellen, dass wir keinen web Worker haben, wie Sie ihn normalerweise in Procfile für eine Webanwendung sehen würden. Für unsere Heroku-App brauchen wir nur die beiden Hintergrund-Worker. Wir brauchen web nicht.

Bereitstellen und Testen der Anwendung

Damit ist unser gesamter Code fertig. Wir haben unseren gesamten Code in das Repository übertragen und sind bereit für die Bereitstellung.

 ~/project$ git push heroku main … remote: -----> Build succeeded! … remote: -----> Compressing... remote: Done: 48.6M remote: -----> Launching... … remote: Verifying deploy... done

Nach der Bereitstellung möchten wir sicherstellen, dass wir unsere Dynos richtig skalieren. Wir benötigen keinen Dyno für einen Webprozess, aber wir benötigen einen für consumer_worker und producer_worker . Wir führen den folgenden Befehl aus, um diese Prozesse entsprechend unseren Anforderungen einzustellen.

 ~/project$ heroku ps:scale web=0 consumer_worker=1 producer_worker=1 Scaling dynos... done, now running producer_worker at 1:Eco, consumer_worker at 1:Eco, web at 0:Eco

Jetzt sollte alles einsatzbereit sein. Im Hintergrund sollte sich unser producer_worker mit dem Kafka-Cluster verbinden und dann alle paar Sekunden damit beginnen, Wettersensordaten zu veröffentlichen. Dann sollte sich unser consumer_worker mit dem Kafka-Cluster verbinden und alle Nachrichten protokollieren, die er von dem Thema empfängt, das er abonniert hat.

Um zu sehen, was unser consumer_worker macht, können wir in unseren Heroku-Protokollen nachsehen.

 ~/project$ heroku logs --tail … heroku[producer_worker.1]: Starting process with command `npm run start:producer` heroku[producer_worker.1]: State changed from starting to up app[producer_worker.1]: app[producer_worker.1]: > [email protected] start:producer app[producer_worker.1]: > node producer.js app[producer_worker.1]: … heroku[consumer_worker.1]: Starting process with command `npm run start:consumer` heroku[consumer_worker.1]: State changed from starting to up app[consumer_worker.1]: app[consumer_worker.1]: > [email protected] start:consumer app[consumer_worker.1]: > node consumer.js app[consumer_worker.1]: app[consumer_worker.1]: {"level":"INFO","timestamp":"2024-05-28T02:31:20.660Z","logger":"kafkajs","message":"[Consumer] Starting","groupId":"columbia-68051.weather-consumers"} app[consumer_worker.1]: {"level":"INFO","timestamp":"2024-05-28T02:31:23.702Z","logger":"kafkajs","message":"[ConsumerGroup] Consumer has joined the group","groupId":"columbia-68051.weather-consumers","memberId":"weather-eda-app-nodejs-client-3ee5d1fa-eba9-4b59-826c-d3b924a6e4e4","leaderId":"weather-eda-app-nodejs-client-3ee5d1fa-eba9-4b59-826c-d3b924a6e4e4","isLeader":true,"memberAssignment":{"columbia-68051.test-topic-1":[0,1,2,3,4,5,6,7]},"groupProtocol":"RoundRobinAssigner","duration":3041} app[consumer_worker.1]: [2024-05-28 02:31:23.755 +0000] INFO (21): {"sensorId":"sensor01","temperature":87.84} app[consumer_worker.1]: [2024-05-28 02:31:23.764 +0000] INFO (21): {"sensorId":"sensor01","humidity":0.3} app[consumer_worker.1]: [2024-05-28 02:31:23.777 +0000] INFO (21): {"sensorId":"sensor03","temperature":22.11} app[consumer_worker.1]: [2024-05-28 02:31:37.773 +0000] INFO (21): {"sensorId":"sensor01","barometric_pressure":29.71} app[consumer_worker.1]: [2024-05-28 02:31:54.495 +0000] INFO (21): {"sensorId":"sensor05","barometric_pressure":29.55} app[consumer_worker.1]: [2024-05-28 02:32:02.629 +0000] INFO (21): {"sensorId":"sensor04","temperature":90.58} app[consumer_worker.1]: [2024-05-28 02:32:03.995 +0000] INFO (21): {"sensorId":"sensor02","barometric_pressure":29.25} app[consumer_worker.1]: [2024-05-28 02:32:12.688 +0000] INFO (21): {"sensorId":"sensor04","humidity":0.1} app[consumer_worker.1]: [2024-05-28 02:32:32.127 +0000] INFO (21): {"sensorId":"sensor01","humidity":0.34} app[consumer_worker.1]: [2024-05-28 02:32:32.851 +0000] INFO (21): {"sensorId":"sensor02","humidity":0.61} app[consumer_worker.1]: [2024-05-28 02:32:37.200 +0000] INFO (21): {"sensorId":"sensor01","barometric_pressure":30.36} app[consumer_worker.1]: [2024-05-28 02:32:50.388 +0000] INFO (21): {"sensorId":"sensor03","temperature":104.55}

Es funktioniert! Wir wissen, dass unser Produzent regelmäßig Nachrichten an Kafka veröffentlicht, weil unser Verbraucher sie empfängt und dann protokolliert.

In einer größeren EDA-App ist natürlich jeder Sensor ein Produzent. Sie können zu verschiedenen Zwecken zu mehreren Themen oder alle zum selben Thema veröffentlichen. Und Ihr Verbraucher kann mehrere Themen abonniert haben. In unserer Demo-App haben unsere Verbraucher außerdem einfach eine Menge pro eachMessage gesendet; in einer EDA-Anwendung kann ein Verbraucher jedoch reagieren, indem er eine Drittanbieter-API aufruft, eine SMS-Benachrichtigung sendet oder eine Datenbank abfragt.

Nachdem Sie nun über ein grundlegendes Verständnis von Ereignissen, Themen, Produzenten und Konsumenten verfügen und wissen, wie Sie mit Kafka arbeiten, können Sie mit dem Entwerfen und Erstellen Ihrer eigenen EDA-Anwendungen beginnen, um komplexere geschäftliche Anwendungsfälle abzudecken.

Abschluss

EDA ist ziemlich leistungsstark – Sie können Ihre Systeme entkoppeln und gleichzeitig wichtige Funktionen wie einfache Skalierbarkeit und Echtzeit-Datenverarbeitung nutzen. Für EDA ist Kafka ein wichtiges Tool, mit dem Sie Datenströme mit hohem Durchsatz problemlos verarbeiten können. Mit Apache Kafka auf Heroku können Sie schnell loslegen. Da es sich um einen verwalteten Dienst handelt, müssen Sie sich nicht um die komplexen Teile der Kafka-Clusterverwaltung kümmern. Sie können sich einfach auf die Erstellung Ihrer Apps konzentrieren.

Von hier aus ist es Zeit für Sie, zu experimentieren und Prototypen zu erstellen. Finden Sie heraus, welche Anwendungsfälle gut zu EDA passen. Tauchen Sie ein, testen Sie es auf Heroku und bauen Sie etwas Erstaunliches. Viel Spaß beim Programmieren!