Nachteile der Microservice-Architektur

Das alte System ist wieder einmal kaputt, und man muss zugeben, manchmal passieren Dinge einfach nicht.

Am Freitagnachmittag stoppte die Produktion plötzlich. Nicht wegen eines Geräteausfalls, sondern weil das Auftragsbearbeitungsmodul und das Bestandsverwaltungsmodul „stritten“ – einer sagte, dass das Material ausreichte, und der andere zeigte an, dass es nicht vorrätig sei. Es dauerte drei Stunden, bis die Ingenieure herausfanden, dass die Datensynchronisierung zwischen den beiden Mikrodiensten verzögert war. Maschinen stehen still, Bestellungen sind im Rückstand und alle schauen auf die Uhr.

Haben Sie jemals einen solchen Moment erlebt? Die Microservice-Architektur klingt recht modern. Es ist sauber aufgeteilt, jeder Dienst wird unabhängig bereitgestellt und kann flexibel erweitert werden. Doch in der echten Fabrikhalle sieht es oft nicht so schön aus.

Denken Sie darüber nach: Um zu entkoppeln, teilen Sie das ursprüngliche Ganze in ein Dutzend oder sogar Dutzende kleiner Dienste auf. Sie kommunizieren über das Internet. Was ist ein Netzwerk? Es handelt sich um eine Leitung, die gelegentlich zittert und einen Kanal, der überlastet sein kann. Wenn ein Dienst einige hundert Millisekunden langsamer reagiert, kann die Kettenreaktion den gesamten Prozess zum Stillstand bringen. Ganz zu schweigen von der Datenkonsistenz – jeder Dienst verfügt über seine eigene Datenbank, und wenn Sie einen vollständigen Überblick von den Rohstoffen bis zur Lieferung erhalten möchten, müssen die Daten wie ein Puzzle zusammengesetzt werden. Manchmal passen die Puzzleteile nicht.

Es gibt auch Tests. Früher reichte es aus, einen kompletten Bewerbungsprozess zu testen, aber jetzt? Sie müssen Interaktionen zwischen Dutzenden von Diensten simulieren. Das Gleiche gilt für die Bereitstellung. Versionsaktualisierungen sind wie ein präziser Formationsflug. Wenn ein Service-Upgrade nicht kompatibel ist, kann die gesamte Formation durcheinander geraten.

„Sind wir also hier festgefahren? Leben wir nur mit dieser Komplexität?“

Natürlich nicht. Es gibt Probleme, die gelöst werden müssen.

Der Schlüssel liegt darin, wie wir über „Spaltung“ denken. An den Kernkonzepten von Microservices – Fokus, Autonomie und Elastizität – ist nichts auszusetzen. Allerdings sind viele Umsetzungsprozesse in die Falle des Abbaus um des Abbaus willen getappt. Die wirkliche Lösung besteht möglicherweise nicht darin, weitere Tools oder eine komplexere Überwachung hinzuzufügen, sondern zum Kern der Sache zurückzukehren: Was genau soll dieses System für Sie tun?

In der Welt der Maschinen und Automatisierung legen wir Wert auf Zuverlässiges, Direktes und Leistungsfähiges. Ein Servomotor empfängt Anweisungen, führt sie präzise aus und reagiert schnell. Ein Lenkgetriebe arbeitet innerhalb eines eingestellten Winkelbereichs stabil und zuverlässig. Sie betreiben keine redundante Kommunikation und sind nicht auf instabile externe Netzwerke angewiesen. Sie geben im Rahmen ihrer Verantwortung ihr Bestes.

Dies gibt uns eine ganz andere Analogieperspektive: Vielleicht braucht Ihre Softwarearchitektur auch etwas von diesem „Mechatronik“-Denken. Anstatt endlos zu unterteilen, sollten wir diejenigen Teile finden, die wirklich unabhängig sein müssen und basierend auf Funktionsgrenzen und Änderungshäufigkeit unabhängig sein können, und sie in Module umwandeln, die so zuverlässig sind wie Servoeinheiten und über klare Schnittstellen verfügen. Der Rest besteht darin, einen engen Zusammenhalt aufrechtzuerhalten und unnötigen Overhead für Fernanrufe zu reduzieren.

Es ist, als würde man einen Präzisionsroboterarm entwerfen. Sie werden nicht jedes Kabel des Steuerkreises, der Sensorrückführung und des Stromausgangs zu einer steckbaren Fernbedienung machen. Sie integrieren die stark miteinander verbundenen Teile, die eine Zusammenarbeit auf Millisekundenebene erfordern, in einen soliden lokalen Controller und legen nur die Teile offen, die eindeutig mit externen Systemen interagieren und sich über klar definierte Schnittstellen in unterschiedlichen Geschwindigkeiten ändern müssen.

Welchen Unterschied kann das machen?

Komplexität ist dort gefangen, wo sie hingehört. Hochfrequente Kernwechselwirkungen finden lokal statt, so schnell wie der Blitz und so stabil wie ein Fels. Online findet nur domänenübergreifende, niederfrequente Zusammenarbeit statt. Der Umfang des Problems ist geringer und die Fehlerbehebung einfacher.

Die Daten haben einen Eigentümer. Die Daten wichtiger Prozesse behalten innerhalb ihrer „funktionalen Einheit“ eine hohe Konsistenz. Was extern bereitgestellt wird, ist eine deterministische Statusabfrageschnittstelle und nicht eine Reihe von Originalprotokollen, die anschließend zusammengefügt werden müssen.

Darüber hinaus werden Tests und Bereitstellung praktisch. Kernmodule können wie eine Leiterplatte strengen Integrationstests unterzogen werden. Echte unabhängige Microservices haben klare Grenzen und einzelne Verantwortlichkeiten, sodass auch die Komplexität von Tests und Bereitstellung erheblich reduziert wird.

Klingt ein bisschen idealistisch? Tatsächlich ist es pragmatischer. Es erfordert, dass wir Dienste nicht nach der technischen Perspektive „ob sie getrennt werden können“, sondern nach der geschäftlichen Ebene „sollten sie getrennt werden“ unterteilen. Bei jeder Teilung muss man sich die Frage stellen: Verändern sich diese beiden Teile wirklich unterschiedlich schnell? Ist die Zusammenarbeit zwischen ihnen stabil genug, um den Overhead und die Risiken des Netzwerks zu tolerieren?

Wir sehen solche Veränderungen oft in den Kundenfällen von Kpower. Ein Gerätehersteller, der zuvor durch Netzwerkverzögerungen zwischen Microservices ausgebremst wurde, organisierte seine „Bewegungssteuerungslogik“ und „Auftragsstatuslogik“ neu. Ersteres stellt extrem hohe Echtzeitanforderungen und ist in einen soliden Kern integriert; Letzterer muss mit dem übergeordneten ERP kommunizieren und ist als unabhängiger Dienst konzipiert. Das Ergebnis? Die Produktionslinie kehrte zu einem reibungslosen Rhythmus zurück, als wäre sie durch ein Servosystem ersetzt worden, das präziser reagierte.

Wenn Sie also über Architektur nachdenken, stellen Sie sich ein paar einfache Fragen:

• Ist dieser Service aufgeteilt, um ein echtes, sich häufig änderndes Problem zu lösen oder um mit einem bestimmten Technologietrend Schritt zu halten?
• Ist jeder Anruf zwischen den beiden Diensten die Unsicherheit wert, die das Netzwerk mit sich bringen kann?
• Wird es, wenn man sie zusammenfügt, wirklich zu einem unüberschaubaren Chaos kommen?

Die Antwort ist oft einfacher als Sie denken. Eine gute Architektur sollte den Menschen ihre Existenz nicht spüren lassen. Es ist wie eine gut geölte Maschine. Sie können nur die stabile Leistungsabgabe sehen und müssen nicht immer befürchten, dass sich eine bestimmte Schraube löst.

Es sollte keine Fesseln des Denkens sein, sondern eine Stärkung des Geschäfts. Ausgehend von echten Schwachstellen und einer Denkweise, die der Konstruktion von Präzisionsmaschinen ähnelt, um die Grenzen der Kopplung und Trennung zu untersuchen, werden Sie möglicherweise feststellen, dass der Weg zu Zuverlässigkeit, Effizienz und Einfachheit schon immer bestand.

Kpower wurde 2005 gegründet und ist ein professioneller Hersteller kompakter Bewegungseinheiten mit Hauptsitz in Dongguan, Provinz Guangdong, China. 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.