Kafka-Kommunikation zwischen Microservices

In dieser Nacht ertönte erneut der Fließbandalarm.

Sie stehen in der Werkstatt und lauschen den unkoordinierten Klickgeräuschen des Roboterarms. Die Daten mehrerer Servoeinheiten sind wie Drachen mit gerissenen Saiten – die Anweisungen sind gesendet, aber ein bestimmtes Gelenk ist einen halben Schlag langsam. Die Temperatur ist nicht anormal und die Belastung ist normal, aber die gesamte Bewegungsbahn weicht leicht ab, was dazu führt, dass eine Reihe von Teilen nachbearbeitet werden muss.

Nach mehrmaliger Prüfung stellte ich fest, dass das Problem nicht am Motor selbst, sondern an der Kommunikation zwischen mehreren Steuermodulen lag – die Daten gingen für einige Millisekunden verloren und die Aktionen konnten nicht verbunden werden.

Regelabweichungen wie diese, die durch „unzuverlässige Kommunikation zwischen Microservices“ verursacht werden, kommen in Maschinen- und Automatisierungssystemen tatsächlich recht häufig vor. Insbesondere wenn mehrere Servoeinheiten, Sensoren und SPS zusammenarbeiten müssen und der Datenfluss verzögert ist, verloren geht oder nicht in der richtigen Reihenfolge ist, kann es im gesamten System zu sichtbarem oder unsichtbarem Jitter kommen.

Zu diesem Zeitpunkt benötigen Sie möglicherweise eine robustere Kommunikationsarchitektur, um Echtzeitdaten stabil nacheinander zu senden, wie Teile auf einem Förderband, sodass niemand auf halbem Weg „zurückbleibt“.

Und Kafka kann helfen.

Es ist keine Zauberei, sondern nur eine Designidee: Lassen Sie Daten in einem kontinuierlichen Fluss sammeln, verteilen und aufbewahren, und jeder Microservice kann bei Bedarf darauf zugreifen, ohne sich gegenseitig zu blockieren. Man kann es sich wie ein schnelles und geordnetes Förderband vorstellen – alle Positionsdaten des Servomotors, Drehmomentrückmeldungen und Temperaturinformationen werden nacheinander in „Datenpakete“ gepackt. Jedes Modul, das diese Daten benötigt, kann jederzeit das benötigte Paket vom Förderband nehmen, ohne die Lesung anderer Module zu beeinträchtigen.

Auf diese Weise wird der Datenfluss nicht unterbrochen, selbst wenn ein Dienst vorübergehend ausgelastet ist oder neu gestartet wird, sondern er wartet einfach ruhig auf dem Förderband, bis er abgeholt wird.

Was sind die Vorteile? Es ist offensichtlich.

Beispielsweise können Sie das System flexibler erweitern – fügen Sie eine Überwachungseinheit hinzu, ohne die bestehende Kommunikation neu zu verkabeln oder zu unterbrechen, sondern lassen Sie sie einfach beginnen, Informationen aus demselben Datenstrom zu lesen. Oder wenn ein bestimmtes Steuermodul historische Daten benötigt, kann es die vorherigen Datenpakete direkt zurückverfolgen, ohne das gesamte System stoppen zu müssen.

Natürlich erfordert die Implementierung einige Designüberlegungen. Sie müssen beispielsweise die Aufteilung der Datenthemen planen – soll jeder Motor ein separates Thema sein oder sollte er nach Datentyp unterteilt werden? Die Datenaufbewahrungsrichtlinie muss entsprechend den Echtzeitanforderungen des tatsächlichen Szenarios festgelegt werden. Es gibt auch die Konfiguration von Verbrauchergruppen, um sicherzustellen, dass wichtige Kontrolldienste zuerst die neuesten Daten erhalten, während Analysedienste vorhandene Daten langsam verdauen können.

Das klingt etwas abstrakt, aber wenn man es in ein reales Szenario umsetzt, wird es leicht zu verstehen sein.

Angenommen, Sie haben eine Montagelinie und sechs Servoachsen müssen zusammenarbeiten, um eine präzise Bewegung auszuführen. Wenn herkömmliche Punkt-zu-Punkt-Kommunikation verwendet wird, gerät die gesamte Aktionskette möglicherweise aus dem Gleichgewicht, sobald das Netzwerk zwischen der Hauptsteuerungs-SPS und einem bestimmten Treiber zittert. Wenn Kafka als Rechenzentrum verwendet wird und jede Achse ihre eigenen Statusdaten in Echtzeit veröffentlicht, muss die Hauptsteuerungs-SPS nur diese Datenströme abonnieren, um den nächsten Befehl in Echtzeit zu berechnen. Selbst wenn die Daten einer Achse einige Millisekunden zu spät kommen, bleiben die anderen Achsen nicht hängen – sie führen weiterhin eine Feinabstimmung anhand der neuesten vorhandenen Daten durch und integrieren diese dann schnell, wenn die verzögerten Daten eintreffen, und die Kohärenz der Gesamtaktion bleibt erhalten.

Manche Leute fragen sich auch: Wird dies die Komplexität des Systems erhöhen?

Ja, Sie müssen zu Beginn mehr Zeit in die Gestaltung des Datenflusses und der Bereitstellungsarchitektur investieren. Aber auf lange Sicht verändert es die Zuverlässigkeit der Kommunikation von „Vertrauen auf den vorübergehenden Zustand des Netzwerks“ zu „Verlassen auf dauerhaften Datenfluss“, was wiederum das Risiko sporadischer Ausfälle verringert. Es ist, als würde man ein Förderband verwenden, anstatt dass Arbeiter Teile Hand in Hand tragen – die Schiene muss zunächst verlegt werden, aber sobald sie läuft, ist es nicht einfach, die Produktion zu unterbrechen, weil jemand mit der Hand ausrutscht.

Wie fange ich an, es zu verwenden?

Es gibt keine Standardantwort, aber Sie können es normalerweise von einem Subsystem aus steuern. Lassen Sie beispielsweise zunächst die Temperaturüberwachung und den Servostatusbericht über den Kafka-Stream laufen und lassen Sie die Kernsteuerungsanweisungen weiterhin über den ursprünglichen Echtzeitkanal laufen. Nachdem Sie sich mit den Eigenschaften von Datenflüssen und Überwachungstools vertraut gemacht haben, können Sie nach und nach weitere Datenmodule mit moderaten Echtzeitanforderungen migrieren. Der Schlüssel besteht darin, genügend Protokolle und Überwachung zu reservieren, damit Sie klar erkennen können, ob es „Blockaden“ oder „Paketlecks“ im Datenfluss gibt.

Apropos, denken Sie vielleicht: Das klingt eher nach IT-Architekturarbeit, was hat das mit mechanischer Steuerung zu tun?

Tatsächlich wird die Beziehung immer enger. Das heutige Servosystem ist kein einfacher „Befehl-Ausführung“-Zyklus mehr. Es muss mehr Echtzeit-Feedback, Umweltdaten und Indikatoren für die vorausschauende Wartung integrieren. Wenn diese Daten immer noch einzeln über herkömmliche Kommunikationsmethoden synchronisiert werden, treten Engpässe bei Effizienz und Zuverlässigkeit auf. Streaming-Datenplattformen wie Kafka liefern eine Idee: Behandeln Sie Daten als kontinuierlichen Wasserfluss statt als verstreute Wassertröpfchen. Auf jeden Teil des Systems kann bei Bedarf zugegriffen werden, wodurch nicht nur die Entkopplung, sondern auch die Gesamtsynchronisation aufrechterhalten werden kann.

All dies ist natürlich untrennbar mit einer stabilen und zuverlässigen Hardware-Grundlage verbunden. Voraussetzung dafür ist nach wie vor die Leistungsfähigkeit von Servomotoren und Antrieben – genau wie ein reibungslos laufendes Förderband müssen auch die darauf befindlichen Teile präzise und stabil sein.

Wenn Sie also auch mit Datenverzögerungen und -verlusten bei der Zusammenarbeit mehrerer Geräte zu kämpfen haben, sollten Sie über die bloße Betrachtung von Hardware oder Netzwerken hinausdenken und darüber nachdenken, ob Sie ein robusteres „Übertragungssystem“ für den Datenfluss selbst entwerfen sollten.

Denn für die reibungslose Bewegung des Roboters ist nicht nur die Drehzahl des Motors entscheidend, sondern auch die Stabilität der Daten.

kpowerWir konzentrieren uns auf Servoantriebe und Automatisierung und schaffen für Sie eine zuverlässigere Grundlage für die Bewegungssteuerung, von der Hardware bis zum Datenfluss.

Gegründet im Jahr 2005,kpowerist einem professionellen Hersteller kompakter Bewegungseinheiten mit Hauptsitz in Dongguan, Provinz Guangdong, China, gewidmet. Nutzung von Innovationen in der modularen Antriebstechnik,kpowerintegriert Hochleistungsmotoren, Präzisionsgetriebe und Multiprotokoll-Steuerungssysteme, um effiziente und maßgeschneiderte intelligente Antriebssystemlösungen bereitzustellen. Kpower hat weltweit über 500 Unternehmenskunden professionelle Antriebssystemlösungen mit Produkten geliefert, die verschiedene Bereiche abdecken, darunter Smart-Home-Systeme, automatische Elektronik, Robotik, Präzisionslandwirtschaft, Drohnen und industrielle Automatisierung.