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 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. 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. Apache Kafka Apache Kafka auf Heroku 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. sind Daten, die auf ein bestimmtes Vorkommnis im System hinweisen, wie etwa eine Temperaturmessung durch einen Sensor. Ereignisse sind Kategorien oder Kanäle, in denen Ereignisse veröffentlicht werden. Betrachten Sie sie als die Themen, die Sie in einem Newsletter abonnieren. Themen sind die Entitäten, die Ereignisse erstellen und an Themen senden. In unserer Demo-EDA-Anwendung werden unsere Produzenten eine Reihe von Wettersensoren sein. Produzenten 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. Verbraucher Einführung in unsere Anwendung Wir erstellen eine Node.js-Anwendung mithilfe der Bibliothek. Hier ist ein kurzer Überblick über die Funktionsweise unserer Anwendung: KafkaJS- 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. Wir lassen einen Verbraucher die Themen abhören. Wenn ein neues Ereignis empfangen wird, schreibt er die Daten in ein Protokoll. 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, bei Heroku an. melden Sie sich Heroku CLI: Laden Sie die Heroku CLI sie. herunter und installieren 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 verfügbar. Sie können den Code gerne klonen und diesem Beitrag weiter folgen. GitHub-Repository 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 genannt, aber Sie können für Ihre App einen eindeutigen Namen wählen.) weather-eda 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 . 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. hier 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 in unserem Projektstammordner, die alle diese Konfigurationsvariablenwerte enthält. Dazu führen wir einfach den folgenden Befehl aus: .env ~/project$ heroku config --shell > .env Unsere Datei sieht folgendermaßen aus: .env 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: , das das Thema abonniert hat und alle veröffentlichten Ereignisse protokolliert. consumer.js , das alle paar Sekunden einige zufällig ausgewählte Wetterdaten zu diesem Thema veröffentlicht. producer.js 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 erstellen wir eine Datei namens . Sie sieht folgendermaßen aus: src kafka.js 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 in unserer Datei (die ursprünglich aus dem Aufruf der Heroku-Konfiguration stammt) analysieren können. Um den Verbindungsversuch zu authentifizieren, müssen wir , und angeben. KAFKA_URL .env KAFKA_TRUSTED_CERT KAFKA_CLIENT_CERT_KEY KAFKA_CLIENT_CERT Dann erstellen wir aus unserem Kafka-Client einen und einen und stellen sicher, dass unsere Konsumenten das Thema abonnieren. producer consumer weather-data Klarstellung zum Kafka-Präfix Beachten Sie in , dass wir unserem Thema und dem Namen unserer Verbrauchergruppe voranstellen. Wir verwenden den Basic 0-Plan für Apache Kafka auf Heroku, einen Multi-Tenant-Kafka-Plan. Das bedeutet, dass wir mit einem . Obwohl wir unser Thema und unsere Verbrauchergruppe genannt haben, muss ihren tatsächlichen Namen in unserem Multi-Tenant-Kafka-Cluster das vorangestellt werden (um sicherzustellen, dass sie eindeutig sind). kafka.js KAFKA_PREFIX KAFKA_PREFIX arbeiten weather-data weather-consumers KAFKA_PREFIX Technisch gesehen lautet der tatsächliche Themenname für unsere Demo also und nicht . (Das Gleiche gilt für den Namen der Verbrauchergruppe.) columbia-68051.weather-data weather-data Der Produzentenprozess Erstellen wir nun unseren Hintergrundprozess, der als Produzent unserer Wettersensoren fungieren wird. In unserem Projektstammordner haben wir eine Datei namens . Sie sieht folgendermaßen aus: producer.js 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): , oder . Das Objekt verfügt für jeden dieser Messwerte über eine Funktion, um einen entsprechenden Wert zu generieren. temperature humidity barometric_pressure getRandomReading Der gesamte Prozess wird als Funktion mit einer unendlichen Schleife ausgeführt. async while Innerhalb der Schleife führen wir Folgendes aus: while Wählen Sie nach dem Zufallsprinzip einen aus. sensor Wählen Sie nach dem Zufallsprinzip eine aus. reading Generieren Sie einen für diesen Messwert. value Rufen Sie auf, um diese Daten im Thema zu veröffentlichen. Der dient als für das Ereignis, während der und die Ereignisnachricht bilden. producer.send sensor key reading value Dann warten wir bis zu 20 Sekunden vor der nächsten Iteration der Schleife. Der Verbraucherprozess Der Hintergrundprozess in ist wesentlich einfacher. consumer.js 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 ist bereits beim Thema angemeldet. Wir rufen auf und richten dann einen Handler für ein. Immer wenn Kafka den über eine Nachricht benachrichtigt, protokolliert es die Nachricht. Das ist alles, was dazu zu sagen ist. consumer weather-data consumer.run eachMessage consumer Prozesse und das Procfile In der Datei müssen wir einige hinzufügen, die unsere Produzenten- und Konsumenten-Hintergrundprozesse starten. Die Datei sollte nun Folgendes enthalten: package.json scripts ... "scripts": { "start": "echo 'do nothing'", "start:consumer": "node consumer.js", "start:producer": "node producer.js" }, ... Die wichtigen sind und . Aber wir behalten in unserer Datei (obwohl es nichts Sinnvolles bewirkt), weil der Heroku-Builder erwartet, dass es dort ist. start:consumer start:producer start Als nächstes erstellen wir ein , das Heroku mitteilt, wie die verschiedenen Worker gestartet werden, die wir für unsere Heroku-App benötigen. Im Stammordner unseres Projekts sollte das folgendermaßen aussehen: Procfile Procfile consumer_worker: npm run start:consumer producer_worker: npm run start:producer Ganz einfach, oder? Wir haben einen Hintergrundprozess-Worker namens und einen anderen namens . Sie werden feststellen, dass wir keinen Worker haben, wie Sie ihn normalerweise in für eine Webanwendung sehen würden. Für unsere Heroku-App brauchen wir nur die beiden Hintergrund-Worker. Wir brauchen nicht. consumer_worker producer_worker web Procfile web 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 und . Wir führen den folgenden Befehl aus, um diese Prozesse entsprechend unseren Anforderungen einzustellen. consumer_worker producer_worker ~/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 mit dem Kafka-Cluster verbinden und dann alle paar Sekunden damit beginnen, Wettersensordaten zu veröffentlichen. Dann sollte sich unser mit dem Kafka-Cluster verbinden und alle Nachrichten protokollieren, die er von dem Thema empfängt, das er abonniert hat. producer_worker consumer_worker Um zu sehen, was unser macht, können wir in unseren Heroku-Protokollen nachsehen. consumer_worker ~/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]: > weather-eda-kafka-heroku-node@1.0.0 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]: > weather-eda-kafka-heroku-node@1.0.0 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} Wir wissen, dass unser Produzent regelmäßig Nachrichten an Kafka veröffentlicht, weil unser Verbraucher sie empfängt und dann protokolliert. Es funktioniert! 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 gesendet; in einer EDA-Anwendung kann ein Verbraucher jedoch reagieren, indem er eine Drittanbieter-API aufruft, eine SMS-Benachrichtigung sendet oder eine Datenbank abfragt. eachMessage 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!