Wenn Ihr Projekt in der Debatte „Microservices oder Monolith“ feststeckt

Stellen Sie sich vor: Die Teambesprechung ist in die dritte Stunde gegangen, das Whiteboard ist voller Kästchen und Pfeile, der Kaffee ist ausgetrunken, aber die Debatte über Architektur hat nicht aufgehört – „Microservices sind flexibler!“ „Aber die monolithische Bereitstellung ist einfacher!“ Wollen Sie zu diesem Zeitpunkt einfach etwas, das tatsächlich etwas bewegen kann, anstatt in theoretischen Debatten zu verharren?

Wir denken oft, dass die Technologieauswahl eine reine Softwarefrage sei, aber wenn man tatsächlich mit der Entwicklung von Produkten beginnt, wird man feststellen, dass Aktuatoren in der physischen Welt – wie präzise Servos und zuverlässige Servomotoren – oft die Hände sind, die Ideen in die Tat umsetzen. Unabhängig davon, welche Architektur im Backend verwendet wird, hat der Endbenutzer das Gefühl, ob der mechanische Teil reibungslos funktioniert und ob die Reaktion zeitnah erfolgt.

Warum sollte die Hardwareleistung Ihre Softwareentscheidungen beeinflussen?

Jemand fragte mich: „Wir nutzen Microservices im Backend. Sollte der Motorsteuerungsteil auch in unabhängige Module aufgeteilt werden?“ Tatsächlich besteht keine Notwendigkeit, es mechanisch zu kopieren. Die Softwarearchitektur löst Skalierbarkeits- und Wartbarkeitsprobleme, während sich die Hardwareauswahl auf Genauigkeit, Drehmoment und Reaktionsgeschwindigkeit konzentriert. Wenn Sie beispielsweise ein automatisiertes Anzeigegerät entwerfen, kann die Software häufig iterativ aktualisiert werden, aber das Lenkgetriebe im Inneren ist beim ersten Mal genau – es besteht keine Chance auf ein „Hot Update“.

kpowerBei der Bearbeitung dieser Art von Projekten wurde ein interessantes Phänomen entdeckt: Viele Teams verbringen viel Zeit damit, über die Software-Architektur zu debattieren, aber standardmäßig „wird es immer einen Weg geben“ im Hardware-Teil. Das Ergebnis ist oft ein schön gestaltetes System, das Gesamterlebnis wird jedoch aufgrund mangelnder Präzision der mechanischen Aktuatoren beeinträchtigt.

Wie kann man also aus diesem Kreislauf ausbrechen?

Überlegen Sie sich zunächst genau, welche Maßnahmen Sie ergreifen möchten, und überlegen Sie dann im Nachhinein, welche Struktur erforderlich ist.

Wenn Sie beispielsweise ein interaktives Anzeigegerät erstellen:

• Benötigen Sie eine schnelle kleine Winkeleinstellung? Dann kommt es auf Reaktionsgeschwindigkeit an
• Müssen Sie eine bestimmte Menge Gewicht sanft heben? Dass Drehmoment und Stabilität wichtiger sind
• Müssen Sie längere Zeit ununterbrochen laufen? Haltbarkeit und Wärmeableitung sollten Vorrang haben

Diese bestimmen, für welchen Motor Sie sich entscheiden, und wirken sich indirekt auch auf das Softwaredesign des Steuerungsteils aus. Ein Motor, der eine hohe Echtzeitsteuerung erfordert, eignet sich möglicherweise besser für eine enge Kopplung mit der Steuerung. Für Szenarien, die eine hohe Genauigkeit, aber keine extremen Echtzeitanforderungen erfordern, kann ein Microservice-Ansatz über API-Aufrufe sinnvoller sein.

Antworten auf häufig gestellte Fragen

„Wir haben ein begrenztes Budget. Sollten wir uns zunächst mit Billigmotoren begnügen und diese später aufrüsten?“ Das ist ein bisschen so, als würde man ein hohes Gebäude mit einem dünnen Gerüst bauen – ein späterer Austausch bedeutet oft eine Neugestaltung der Struktur.kpowerIngenieure halfen einmal einem Team bei der Planung: Ursprünglich hatten sie geplant, zunächst kostengünstige Motoren zu verwenden, um die Idee zu überprüfen, doch der Test ergab, dass der Genauigkeitsfehler dazu führte, dass das gesamte Feedback-System nicht kalibriert werden konnte. Später wurde das Modell erneut ausgewählt, was die Anschaffungskosten um 15 % erhöhte, aber mindestens zwei Monate Zeit bei der Neuabstimmung des Systems sparte.

„Wie sollte unter der Microservice-Architektur der Hardware-Steuerungsteil gestaltet sein?“ Es besteht keine Notwendigkeit, Microservices um der „Microservices“ willen zu haben. Behandeln Sie den Teil, der direkt mit der Hardware interagiert, als unabhängige Dienstgrenze und definieren Sie die Schnittstelle basierend auf den Antworteigenschaften der Hardware. Wenn ein Motor eine Reaktion im Millisekundenbereich erfordert, lassen Sie ihn nicht zu viele Serviceschichten durchlaufen. Architektur dient Zielen, nicht umgekehrt.

Unsichtbare Details, sichtbare Ergebnisse

Letztes Jahr baute ein Team ein Demonstrationssystem für intelligente Lagerhaltung. Die Softwarearchitektur war elegant und schön. Allerdings vibrierte das Handling-Servo bei der Vorführung vor Ort immer leicht an Schlüsselpositionen. Das Problem liegt nicht in der Softwarelogik, sondern in der mangelnden Stabilität des Motors bei niedrigen Drehzahlen. Später wechselten sie zu einem Modell, das besser für Szenarien mit niedriger Geschwindigkeit geeignet war, und das Problem verschwand.

So etwas ist keine Seltenheit. Sie verbringen viel Zeit damit, perfekte Service-Splits, Datenbanken und Schnittstellendefinitionen zu entwerfen, aber das intuitivste Gefühl für Benutzer ist oft, ob der Roboterarm glatt ist, ob die rotierende Plattform leise ist und ob die Positionierung genau ist.

Also, wenn Sie das nächste Mal ein Meeting haben …

Wenn die Diskussion in den Zyklus „Welche Architektur ist besser“ fällt, versuchen Sie, die Frage zu ändern: „Welche physische Bewegung wollen wir erreichen? Wie schnell, genau und kraftvoll muss diese Bewegung sein?“

Die Antwort ist oft viel klarer. Die Software-Architektur kann kontinuierlich angepasst und neu aufgebaut werden, ist die Hardware jedoch erst einmal integriert, sind die Wiederbeschaffungskosten deutlich höher. Verankern Sie zuerst die Kernindikatoren der Hardware und lassen Sie dann die Softwarearchitektur daran anpassen, nicht umgekehrt.

Bei guten technischen Entscheidungen geht es nicht darum, eine „richtige“ Antwort auszuwählen, sondern darum, jeden Teil das tun zu lassen, was er am besten kann. Der Motor ist für die präzise Ausführung verantwortlich, die Software für die flexible Planung und Ihr Team für die Wertschöpfung. Auf diese Weise bietet das Frontend den Benutzern ein reibungsloses und zuverlässiges Erlebnis, unabhängig davon, ob es sich beim Backend um einen Microservice oder einen Monolithen handelt.

最终，用户不会关心你的服务拆得多细致，他们只关心产品是否按预期工作。而让预期变成现实的那一步，往往是从一个合适的电机开始的。

Gegründet im Jahr 2005,kpowerist einem professionellen Hersteller kompakter Bewegungseinheiten mit Hauptsitz in Dongguan, Provinz Guangdong, China, gewidmet. Kpower nutzt Innovationen in der modularen Antriebstechnologie und integriert 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.