Warum wir Kafka in Microservices verwenden

Haben Sie schon einmal versucht, eine große Gruppe von Servomotoren so zu steuern, dass sie sich wie ein Symphonieorchester synchronisieren?

Ich habe einmal an einem automatisierten Produktionslinienprojekt gearbeitet, bei dem Dutzende Roboterarme gleichzeitig liefen und weiterhin Sensordaten einströmten. Zuerst habe ich eine normale Nachrichtenwarteschlange verwendet, aber ich stellte fest, dass das gesamte System zu „stecken“ begann, als die Datenmenge in einer bestimmten Verbindung plötzlich anstieg, genau wie an einer Kreuzung während der Hauptverkehrszeit, an der alle Autos blockiert waren und der Roboterarm dahinter nur warten konnte.

Zu diesem Zeitpunkt werden Sie sich fragen: Gibt es eine Möglichkeit, die Daten so zu gestalten, dass sie dem Verkehrsfluss auf der Autobahn entsprechen, selbst wenn ein bestimmter Abschnitt verstopft ist und andere Fahrspuren noch frei sind?

Später kam ich mit der Idee in Kontakt, Kafka zur Verarbeitung von Microservices zu nutzen. Einfach ausgedrückt ist es wie ein Förderbandsystem, das niemals verstopft. Jeder Ihrer Microservices – etwa ein Programm, das für das Parsen von Lenkgetriebepositionsdaten verantwortlich ist, oder ein anderer Dienst, der mechanische Schwingungsfrequenzen aufzeichnet – kann die benötigten Datenpakete selbstständig von diesem Förderband nehmen und seine eigenen Angelegenheiten erledigen, ohne sich gegenseitig zu stören.

Geben Sie ein Beispiel. Angenommen, Sie verfügen über drei Mikrodienste: A empfängt Sensorsignale, B berechnet Bewegungstrajektorien und C zeichnet Laufprotokolle auf. In der traditionellen Architektur wartet B darauf, dass A die Verarbeitung abschließt, bevor sie funktionieren kann, und C muss auf B warten. Nach der Verwendung von Kafka legt A jedoch die Originaldaten auf das „Förderband“, und B und C können gleichzeitig darauf zugreifen und unabhängig voneinander arbeiten. Selbst wenn C vorübergehend langsamer ist, wird es A und B nicht verlangsamen.

Warum ist dies besonders wichtig für mechanische Projekte? Denn mechanische Systeme arbeiten oft in Echtzeit und sind hochgradig gleichzeitig. Die Servomotoren jedes Gelenks eines sechsachsigen Roboters geben Daten im Millisekundenbereich zurück. Kommt es zu einer Verzögerung in der Datenverarbeitungskette, verliert die gesamte Bewegung die Koordination. Das „persistente Protokoll“-Design von Kafka stellt sicher, dass die Daten während der Ausfallzeit auch bei einem Neustart eines Dienstes nicht verloren gehen – genau wie eine kontinuierliche Aufzeichnung des laufenden Protokolls jedes Geräts, das jederzeit abgespielt werden kann.

Jemand fragte mich: „Das hört sich gut an, aber wird es kompliziert sein?“ Tatsächlich kommt es nicht darauf an, wie tiefgreifend die Technologie selbst ist, sondern ob sie zu Ihrem Szenario passt. Wenn Sie nur zwei oder drei Servos steuern, um einfache Schwünge auszuführen, ist dies möglicherweise nicht sinnvoll. Wenn Sie es jedoch mit einer ganzen Werkstattautomatisierungsausrüstung mit Hunderten von Datenquellen zu tun haben, kann Ihnen diese Architektur dabei helfen, die Mühe zu vermeiden, spät in der Nacht Überstunden zu machen, um Probleme zu beheben.

Bei der Auswahl eines Modells achte ich in der Regel auf drei Punkte: Der erste ist, ob der Durchsatz mit Ihrer Datenspitze mithalten kann – etwa ein Sturmszenario, wenn alle Sensoren gleichzeitig melden; Die zweite Frage ist, ob die Verzögerung innerhalb des Toleranzbereichs Ihres mechanischen Systems liegt. Der dritte sind die Betriebs- und Wartungskosten. Kafka hat in diesen Dimensionen einen guten Balancepunkt gefunden.

Natürlich gibt es kein Allheilmittel. Dazu ist ein klarer Plan für den Datenfluss erforderlich, beispielsweise für die Aufteilung von Themen und die Gestaltung von Partitionen. Es ist wie bei der Planung einer Fließbandroute für eine neue Fabrik: Welche Daten auf die Überholspur gelangen sollen und welche für den Transport konsolidiert werden können, muss man sich im Vorfeld überlegen.

Lassen Sie uns über die tatsächliche Implementierungserfahrung sprechen. Bei der ersten Bereitstellung muss sich das Team an diesen Wandel im „Publish-Subscribe“-Denken anpassen und darf nicht länger auf direkten Aufrufen zwischen Diensten bestehen. Doch sobald es in Betrieb geht, erhöht sich die Flexibilität des Systems deutlich. Wenn ein Dienst aktualisiert wird, werden andere Dienste wie gewohnt ausgeführt. Wenn ein neues Datenanalysemodul hinzugefügt wird, müssen Sie es lediglich den entsprechenden Datenstrom abonnieren lassen, ohne den ursprünglichen Link zu ändern.

Die digitale Welt mechanischer Systeme ist oft unsichtbar, aber sie bestimmt, ob die Bewegungen physischer Geräte präzise und reibungslos sind. Die Wahl einer geeigneten Datenarchitektur ist so, als würde man einen präzisen mechanischen Mechanismus mit einem passenden Nervensystem ausstatten – es ist vielleicht nicht direkt sichtbar, aber es macht die Drehung jedes Zahnrads sicherer.

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.kpowerhat 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.