Die Wahl einer Architektur ist wie deren Zusammenbau: Microservices, Monolith oder SOA, welche macht Ihr mechanisches Projekt flexibler?

Stellen Sie sich vor, Sie sind in Ihrer Werkstatt und montieren einen neuen Antriebsstrang. Die Teile liegen ausgebreitet auf dem Tisch, Schrauben, Zahnräder, Motoren – wenn sie alle zu einem Eisenklumpen verschweißt sind, muss das Ganze dann demontiert und neu gestartet werden, wenn man in Zukunft die Zahnräder wechseln will? Wenn andererseits jede Schraube einzeln als Modul verpackt ist und bei jeder Anpassung Dutzende Schnittstellen neu angeschlossen werden müssen, befürchte ich, dass einem allein die Koordination den ganzen Tag Kopfschmerzen bereiten wird.

Dies ist wahrscheinlich das Dilemma, mit dem viele Menschen bei der Auswahl einer Softwarearchitektur konfrontiert sind. Microservices, Monomer, SOA – diese Begriffe klingen sehr technisch, unterscheiden sich aber tatsächlich nicht wesentlich von der Logik der mechanischen Montage. Heute werden wir beiläufig über diese Optionen sprechen und sehen, wie sie sich auf Ihr Projekt auswirken, sei es die Steuerung der Genauigkeit des Servomotors oder die etwas schnellere Reaktion des Servos.

Lassen Sie uns zunächst über diesen „großen Eisenklumpen“ sprechen: die monolithische Architektur

Manche Leute packen gerne alle Funktionen in ein Ganzes. Genau wie bei einigen altmodischen mechanischen Steuerungen in den Anfangsjahren befinden sich Leiterplatte, Treiber und Logik alle auf einer Platine. Was sind die Vorteile? Einfach. Die Entwicklung ist einfach, man muss bei der Bereitstellung einfach ein Paket einwerfen, und beim ersten Start läuft es recht stabil.

Aber nach einer Weile stellen Sie möglicherweise fest, dass Sie, wenn Sie nur eines der Sensormodule aktualisieren möchten, das gesamte System erneut testen müssen. Eines Tages, wenn die Last hoch ist und eine bestimmte Funktion hängen bleibt, kann es sein, dass das gesamte System langsamer wird. Es ist wie bei Ihrer fünf Jahre alten Graviermaschine, die Sie durch einen neuen Schneidkopf ersetzen möchten, nur um festzustellen, dass auch der Motortreiber ausgetauscht werden muss, weil nicht einmal daran gedacht wurde, dass Sie ihn separat aufrüsten können.

Jemand fragte: „Ist die monolithische Architektur nutzlos?“ Nicht wirklich. Wenn Ihr Projekt klein ist und über eine einfache Logik verfügt oder Sie dringend schnell einen Prototyp auf den Markt bringen müssen, erspart Ihnen dieser „einteilige“ Ansatz Sorgen. Die Probleme treten oft erst nach dem Erwachsenwerden auf.

Modularer Workshop: SOA (Serviceorientierte Architektur)

Also schlug jemand eine strukturiertere Idee vor: SOA. Man kann es sich wie eine Werkstatt mit klarer Arbeitsteilung vorstellen. Die Drehabteilung ist nur für das Schneiden zuständig, die Schleifabteilung ist nur für das Polieren zuständig und die Montagelinie ist für die Montage zuständig. Jede Abteilung stellt Standard-„Dienste“ bereit und kommuniziert zwischen ihnen über vordefinierte Schnittstellen.

Dieser Ansatz wird in vielen Unternehmen schon seit vielen Jahren praktiziert. Es löst einen Teil des Kopplungsproblems und ermöglicht es verschiedenen Teams, relativ unabhängig zu arbeiten. Die Kommunikation zwischen diesen „Abteilungen“ basiert jedoch häufig auf relativ umfangreicher Middleware und Protokollen, und die Anpassung erfordert immer noch einen hohen Koordinationsaufwand. Manchmal haben Sie möglicherweise das Gefühl, dass der Prozess etwas starr ist, als ob Sie für jeden Vorgang in der Werkstatt ein Formular ausfüllen und auf die Genehmigung warten müssten. Bei kleinen Änderungen dauert der Prozess länger als bei der eigentlichen Arbeit.

Baugruppe im Lego-Stil: Microservices

Dann wurden Microservices populär. Diese Idee ähnelt eher einem Lego-Spiel: Jede Funktion wird in unabhängige kleine Bausteine ​​(Dienste) zerlegt, die selbstständig ausgeführt und springt und über leichtgewichtige Methoden (z. B. HTTP-API) chatten können. Jeder Dienst kann separat entwickelt, separat bereitgestellt und separat erweitert werden.

Sie arbeiten beispielsweise an einem Steuerungssystem für einen mehrachsigen Roboterarm. Sie könnten einen Mikrodienst für die Flugbahnberechnung, einen anderen für die Rückmeldung des Motorantriebs und einen weiteren für die Verarbeitung von Benutzeroberflächenanweisungen haben. Wenn etwas benötigt wird, müssen Sie nur diesen Computerdienst aktualisieren, ohne andere Teile zu beeinträchtigen. Wenn der Antriebsdruck eines bestimmten Motors hoch ist, können Sie diesem Dienst separat Ressourcen hinzufügen.

Klingt wunderbar, oder? Aber es ist auch keine Zauberei. Microservices bringen neue Herausforderungen mit sich: Wie kann man so viele kleine Services koordinieren? Wird die Netzwerkkommunikation zu einem neuen Flaschenhals? Wie kann man einem Problem auf die Spur kommen? Es ist, als würden Sie einen Haufen kleiner Roboter verwalten, die autonom agieren können. Sie benötigen bessere Überwachungstools und Bereitstellungsstrategien, um sicherzustellen, dass sie nicht miteinander in Konflikt geraten oder verloren gehen.

Wie wählt man also aus?

Tatsächlich ist keine Architektur „beste“. Genauso wie bei der Auswahl eines Treibers für einen Servomotor müssen Sie auf Last, Genauigkeit und Reaktionsgeschwindigkeit achten – auch die Softwarearchitektur muss zu Ihrem spezifischen Szenario passen.

Ein paar Tipps können Ihnen helfen, Ihre Gedanken zu ordnen:

• Wenn Sie gerade ein Pilotprojekt mit einem kleinen Team und großen Nachfragevariablen gestartet haben, können Sie mit einem Monolithen möglicherweise schneller arbeiten.
• Wenn Sie eine mittelgroße bis große Plattform aufbauen, die mit mehreren vorhandenen Systemen kommunizieren muss, ist eine standardisierte Servicegrenze wie SOA möglicherweise besser geeignet.
• Wenn Ihr System häufige Iterationen erfordert, Teile davon unabhängig voneinander skalieren oder Sie möchten, dass Ihr Team Funktionen autonom entwickelt und veröffentlicht, dann sind Microservices eine ernsthafte Überlegung wert.

Natürlich werden in der Realität viele Projekte diese Ideen vermischen. Möglicherweise verwendet der Kern Microservices, um Flexibilität zu gewährleisten, und einige Hilfsmodule verwenden der Einfachheit halber Monolithen. Wichtig ist, dass Sie sich nicht einfach auf ein Konzept einlassen, nur weil es beliebt ist. wiekpowerBei Motion-Control-Projekten für einige Kunden nehmen wir uns oft die Zeit, die tatsächlichen Arbeitsszenarien und Wachstumserwartungen zu verstehen, bevor wir die Technologiekombination besprechen – schließlich sind die richtigen Werkzeuge der Schlüssel für einen reibungslosen Betrieb der Maschine.

Lassen Sie mich nur sagen, dass Sie sich nicht ein für alle Mal für die Architektur entscheiden können. Es ist ein bisschen wie die Ausrüstungsanordnung in Ihrer Werkstatt, die sich an veränderte Produktionsanforderungen anpasst. Offen zu bleiben und bereit zu sein, bei Bedarf Umgestaltungen oder Weiterentwicklungen vorzunehmen, ist oft praktischer, als von Anfang an ein „perfektes Design“ anzustreben. Schließlich ist es nicht der Name einer bestimmten Architektur, die dafür sorgen kann, dass sich der Servomotor stabil dreht und der Manipulator präzise Aktionen ausführt, sondern ob sie wirklich zu dem zu lösenden Problem passt.

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.