Wenn Ihr Servomotorprojekt auf Microservices trifft: Warum Sie eine Nachrichtenwarteschlange benötigen und unsere Praxis

Stellen Sie sich Folgendes vor: Sie debuggen einen Roboterarm, bei dem jedes Gelenk von einem unabhängigen Servomotor gesteuert wird. Diese Motoren müssen in Echtzeit zusammenarbeiten, aber die Anweisungen stammen von verschiedenen Mikrodiensten – einer berechnet die Flugbahn, einer kümmert sich um das Sensor-Feedback und ein anderer verwaltet die Sicherheitslogik. Plötzlich verlangsamt sich ein bestimmter Dienst aufgrund der hohen Auslastung für einige Millisekunden und der gesamte Vorgang beginnt einzufrieren oder gerät sogar aus der Synchronisierung. Dachten Sie in diesem Moment, dass es großartig wäre, wenn diese Dienste Gespräche „reibungsloser“ machen könnten?

Dabei handelt es sich tatsächlich nicht nur um ein Problem, das bei der mechanischen Steuerung auftritt. Jedes in Microservices aufgeteilte System steht vor ähnlichen Herausforderungen: Wie kann die Kommunikation zwischen Services zuverlässig und effizient erfolgen? Wie kann sichergestellt werden, dass Daten nicht verloren gehen, die Reihenfolge nicht durcheinander gerät und plötzlichem Datenverkehr standgehalten wird?

Vor ein paar Jahren stießen wir auf diese Herausforderung, als wir eine automatisierte Sortierlinie modernisierten. Herkömmliche Methoden wie direkte HTTP-Aufrufe werden mit der Zunahme der Dienste anfällig. Wenn ein Dienst ausfällt, sind auch andere Dienste auf der Verbindung betroffen; Sobald Spitzenanforderungen eintreffen, gerät das System in die Warteschlange und eine Echtzeitleistung ist nicht mehr möglich. Wir brauchen einen Mechanismus, der eher einem „Förderband“ ähnelt – legen Sie die Daten darauf ab und lassen Sie die Stellen, an denen sie benötigt werden, in ihrem eigenen Tempo darauf zugreifen, ohne sich gegenseitig zu blockieren.

Also machten wir uns auf die Suche und stellten schließlich Kafka vor.

Was ist Kafka? Stellen Sie sich das wie ein schnelles, intelligentes Fließband vor

Nehmen wir als Vergleich eine bekannte Szene: Kafka ist wie das nie endende Fließband in einer Fabrik. Jeder Microservice kann als Workstation betrachtet werden. Station A legt die Halbfertigprodukte (Nachrichten) auf das Förderband, die Stationen B und C nehmen sie bei Bedarf jederzeit zur Bearbeitung ab. Das Förderband selbst läuft weiter. Selbst wenn eine bestimmte Station vorübergehend repariert wird, verschwinden die Halbfabrikate nicht, sondern warten einfach still am Band, bis eine Station übernimmt.

Dies löst mehrere Kopfschmerzen:

• Entkopplung: Leistungen „rufen“ nicht mehr direkt an, sondern werden über ein Fließband übergeben. Der Absender lässt die Nachricht fallen und geht weg, ohne zu wissen, wer sie wann bearbeiten wird.
• Puffer: Wenn der Upstream plötzlich eine große Datenmenge generiert (z. B. ein plötzliches Hochfrequenzsignal von einem Sensor), kann das Förderband diese vorübergehend transportieren und der Downstream kann sie entsprechend seinen eigenen Fähigkeiten verarbeiten, um eine Überlastung zu vermeiden.
• Zuverlässigkeit: Nachrichten bleiben auf dem Förderband erhalten, und selbst wenn einige Dienste neu gestartet werden, gehen die Daten nicht verloren.
• Sequentialität: Auf einem Förderband ist die Reihenfolge der Artikel festgelegt. Dies ist entscheidend für sequenzsensitive Daten wie Motorsteuerungsanweisungen.

Wie nutzen wir es? Ein nichtlineares Experiment

Zu Beginn waren einige Leute im Team besorgt: „Ist das zu kompliziert? Wir müssen einen neuen Satz Middleware pflegen.“ Aber in der Praxis stellten wir fest, dass es sich eher um Bauklötze als um den Bau eines Wolkenkratzers handelte.

Wir haben nicht mit einer kompletten Überarbeitung begonnen. Stattdessen haben wir uns für eine Verbindung mit dem offensichtlichsten Schwachpunkt entschieden, um das Wasser zu testen – die Statusüberwachung des Roboterarms. Es stellt sich heraus, dass Statusdaten von einem Dienst an einen anderen übertragen werden und häufig aufgrund von Netzwerkschwankungen verloren gehen, was dazu führt, dass das Überwachungspanel von Zeit zu Zeit „fragmentiert“ wird. Wir haben einfach ein Kafka-Thema eingerichtet (das als dediziertes Förderband verstanden werden kann), den Statusveröffentlichungsdienst hier Daten schreiben lassen und den Überwachungsdienst abonnieren. Das Fragmentierungsproblem verschwand fast sofort. Denn selbst wenn der Überwachungsdienst vorübergehend offline ist, kann er nach dem Neustart alle unverarbeiteten Statusaktualisierungen vom Haltepunkt lesen.

Dieser kleine Erfolg gab uns Zuversicht. Anschließend haben wir den Auftragsanweisungsfluss und den Alarmereignisfluss schrittweise migriert. Nach und nach wird der Datenfluss des gesamten Systems deutlich sichtbar, als würde man eine Echtzeit-Logistikkarte betrachten. Auf einen Blick ist ersichtlich, welche Leitungen überlastet und welche frei sind.

Einige echte Fragmente und Gefühle

Natürlich gab es dabei auch einige Erkundungen. Zum Beispiel hatten wir einmal Probleme mit der Frage: „In wie viele Förderbänder (Themen) sollten unterteilt werden?“ Später stellten wir fest, dass wie in einem Workshop nicht alle Teile in einer Zeile gemischt werden und es sinnvoller ist, sie nach Datendomäne und Dringlichkeit getrennt zu verwalten. Motorsteuerungsanweisungen erfordern eine geringe Latenz und erfordern eine separate Hochgeschwindigkeitsleitung; Protokoll- und Prüfdaten haben ein großes Volumen, stellen aber nur geringe Echtzeitanforderungen. Verwenden Sie daher eine andere Leitung mit hoher Kapazität. Jeder geht seinen eigenen Weg, ohne sich gegenseitig zu behindern.

Manche Leute fragen auch: „Was ist, wenn das Förderband selbst kaputt geht?“ Das verteilte Design von Kafka macht es von Natur aus überflüssig. Die Daten werden auf mehreren Knoten gesichert. Fällt ein einzelner Knoten aus, können andere Knoten sofort übernehmen und der Dienst ist nahezu unmerklich. Es ist, als würde man einen Ersatzmotor in das Getriebe einbauen.

Rückblickend hat die Einführung von Kafka das System nicht „komplexer“ gemacht, sondern das ursprünglich unsichtbare Chaos geordnet. Die angespannte direkte Kopplungsbeziehung zwischen Microservices wurde gelockert. Jeder Dienst kann sich stärker auf seine eigene Logik konzentrieren und die Flexibilität der gesamten Architektur wurde erheblich verbessert. Wenn die Produktionslinie erweitert und eine neue Inspektionsstation hinzugefügt werden muss, müssen wir nur den neuen Service für das entsprechende Thema abonnieren. Dies ist so einfach wie das Hinzufügen einer neuen Station neben dem Förderband, ohne andere Teile überhaupt zu beeinträchtigen.

Lassen Sie uns über Entscheidungen sprechen

Es gibt viele Tools für Nachrichtenwarteschlangen auf dem Markt. Warum sollten Sie sich für Kafka entscheiden? Wir schätzen die ausgewogene Leistung in Bezug auf hohen Durchsatz, Persistenz und Sequenzgarantien. Es ist vielleicht nicht das Gerät mit den auffälligsten Funktionen, aber es ist solide genug für Industrieszenarien, die eine stabile Verarbeitung von Datenströmen erfordern. Natürlich ist kein Werkzeug ein Allheilmittel, und seine Lernkurve sowie Betriebs- und Wartungskosten erfordern Investitionen. Wenn aber auch Ihre Microservices aufgrund von Kommunikationsproblemen anfangen, „unkoordiniert zu agieren“, kann es sich lohnen, über die Installation eines Satzes solcher „intelligenten Förderbänder“ im System nachzudenken.

Schließlich sollte gute Technologie wie eine zuverlässige mechanische Übertragung sein – leise, präzise und eine mühelose komplexe Zusammenarbeit.

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.