layline.io Blog
Korrektur von Problemen mit Microservices.
Seit einigen Jahren sind Microservices und serviceorientierte Architekturen in aller Munde. Aber sie haben auch ihre Schattenseiten. Können sie überwunden werden?
Reading time: 6 min.
Seit einigen Jahren sind Microservices und serviceorientierte Architekturen in aller Munde. Kurz darauf half die Containerisierung, die installierte Plattform von der bereitgestellten Plattform zu abstrahieren, indem das Betriebssystem und abhängige Bibliotheken zusammen mit der eigentlichen Anwendung verpackt wurden.
Aber wo Licht ist, da ist auch Schatten. Die Arbeit mit und die Verwendung von Microservices bringt eine Reihe von Herausforderungen mit sich. Wir haben eine ziemlich umfassende Liste hier gefunden (https://www.toolbox.com/tech/data-management/articles/top-10-challenges-of-using-microservices-for-managing-distributed-systems/). Schauen wir uns einige der wichtigsten Vor- und Nachteile an:
Die wichtigsten Herausforderungen bei Entwicklung, Bereitstellung und Betrieb von Microservices
Das Gute
- Atomarität: Autonome Dienste können in Bezug auf Entwicklung und Ausführung (abgesehen von Schnittstellen) individuell behandelt werden.
- Ausfallsicherheit: Einzelne Dienste sind in der Regel nicht gefährdet, wenn es zu Ausfällen in anderen Diensten kommt, was zu einer besseren Ausfallsicherheit führt.
- Skalierbarkeit: Einzelne Dienste können bei Bedarf elastisch skaliert werden.
Das Schlechte
- Lockere Kopplung: Microservices wissen in der Regel nichts voneinander und von ihrem breiteren Ausführungskontext. Sie sind von Natur aus atomar. Die Kommunikation zwischen ihnen ist mit einem Overhead verbunden und nicht standardisiert.
- Überwachung: Ein umfassendes Monitoring einer Vielzahl von Microservices ist extrem schwierig und fast unmöglich durchzuführen. Die eindeutige Aufdeckung individueller Probleme über verschiedene Dienste hinweg kann sich als äußerst schwierig erweisen, da verschiedene Arten von Protokollen überall verstreut sind, die Abhängigkeiten zwischen den Diensten unklar sind und Transaktionen über mehrere Dienste hinweg erfolgen usw.
- Debugging: Fehler, die in einer komplexen, verteilten Microservices-Architektur auftreten, können extrem zeit- und kostenaufwendig zu verfolgen sein. Es gibt kein übergreifendes Monitoring-System, sondern einzelne Logs und Stack Traces, die untersucht werden müssen, um sicher auf die Fehlerursache schließen zu können.
- Sicherheit: Ein wesentliches Merkmal von Microservices sind ihre Schnittstellen/APIs. Besonders in verteilten Umgebungen erfordert jede von ihnen besondere Sorgfalt in Bezug auf die Sicherheit. In solch komplexen Framework-Umgebungen kann man leicht den Überblick und die Kontrolle verlieren.
- Resilienz: Bei vielen verschiedenen Arten von Microservices, die von unterschiedlichen Teams entwickelt werden können, wird es exponentiell schwieriger, geeignete Failover-Mechanismen zu gewährleisten, so dass das gesamte System entsprechend reagieren kann, wenn ein oder mehrere Microservices ausfallen.
- Entwicklung: Das Deployment einzelner Microservices in einem komplexen Setup ohne Ausfallzeiten ist schwer zu orchestrieren und manchmal unmöglich zu bewerkstelligen, ohne alles neu zu starten.
- Kommunikation: Es muss eine Form der Standardisierung der Kommunikation zwischen Microservices in Bezug auf Serialisierung, Sicherheit, Anfrageoptionen, Fehlerbehandlung und die Liste der erwarteten Antworten geben. Eine Form der Top-Level-Design-Orchestrierung ist sehr wichtig, da es sonst zu Kommunikationsfehlern und Latenzproblemen kommt.
Dies sind nur einige der Herausforderungen, die zu bewältigen sind. Wie Sie sich vorstellen können, gibt es noch viele weitere Herausforderungen, wenn es um Wartung, Vernetzung, Team-Management usw. geht.
Lösung: MikroKonfigurationen anstelle von MikroServices
Während die Idee von Microservices großartig ist, kann es sehr schnell sehr unangenehm werden. Es stellt sich natürlich die Frage, ob es einen Weg gibt, die guten Teile eines Microservices-Setups zu erhalten und die schlechten Teile zu vermeiden.
Mikro-Konfigurationen können hier helfen. Wir definieren Mikro-Konfiguration (oder MicroConfig) als eine Trennung zwischen der eigentlichen Service-Logik (der Konfiguration) und der Service-Ausführung. (die Engine).
Die Konfiguration beschränkt sich in diesem Zusammenhang ausschließlich auf die Geschäftslogik, d. h. was mit den Daten geschehen soll, welche Aktion ausgelöst werden soll usw.
Ausführung ist alles, was die Ausführung der Konfiguration ermöglicht: Dies wäre
- Ausführung der Logik (Konfiguration),
- zentralisierte und standardisierte Protokollierung von Aktivitäten und Problemen,
- Orchestrierung der Ausführung über Dienste hinweg
- Metrikberichte für die Überwachung
- Unterstützung bei der Fehlersuche
- standardisierte Kommunikation über Dienstgrenzen hinweg
- und vieles mehr.
Dies ist im Allgemeinen kein neues Konzept in der Welt der Technik.
Beispiel: Eine typische Datenbank unterscheidet zwischen der Datenbankstruktur (Tabellen, Indizes, Beschränkungen usw.) und der Datenbank-Engine (Interpretation, Speicherung, Bereitstellung). Während die Engine für jeden Benutzer die gleiche ist, ist die Struktur einzigartig. Dennoch käme niemand auf die Idee, Tabellen direkt in der Engine fest zu codieren. Die Trennung von Config und Engine macht die Datenbank überhaupt erst generisch, jede der beiden hat einen speziellen Zweck und eine besondere Leistung.
layline.io ist insofern ähnlich, als dass die Dienste als sogenannte Workflow Konfigurationen und nicht als monolithische ausführbare Dateien implementiert werden. Es kann eine unbegrenzte Anzahl von verschiedenen Workflows definiert werden. Die Workflows werden von Reactive Engines ausgeführt, die ihrerseits auf Nodes laufen. Ein Kubernetes-Pod oder ein Raspberry Pi wäre zum Beispiel ein Node. Zwei oder mehr Engines bilden einen logischen Reactive Cluster. Das Setup hängt ausschließlich von Ihren Anforderungen und Ihrer Umgebung ab. Eine theoretisch unbegrenzte Anzahl von Engines (auf Nodes) kann in einem geografisch verteilten logischen Cluster erzeugt und betrieben werden. Edge-Computing ist hier einer der interessanten Anwendungsfälle. Da alles auf demselben Typ von Reactive Engine läuft, müssen Sie nicht darüber nachdenken, was Sie auf physischer Ebene einsetzen wollen.
Das Deployment von Workflow-Konfigurationen erfolgt automatisch, indem eine Konfiguration an einen Knoten im Reactive Cluster veröffentlicht wird und der Cluster dann automatisch die Konfiguration im gesamten Cluster verbreitet. Dadurch wird vermieden, dass man sich um die physische Verteilung von Microservices auf Pods oder physische Knoten kümmern muss. Neue Knoten, die dem Cluster hinzugefügt werden, erhalten ebenfalls automatisch die Konfigurationsdaten und können sofort mit der Verarbeitung beginnen.
Ausfallsicherheit, Skalierbarkeit und Failover sind in layline.io integriert. Die ständige Überwachung des Clusters stellt die Einhaltung der konfigurierten Skalierung der Workflows sicher, und gleicht die Auslastung der Workflows im Falle eines Node-Ausfalls automatisch aus.
Die zentrale Überwachung und Protokollierung stellt sicher, dass Probleme innerhalb des Reactive Clusters sofort erkannt werden. Remedy kann allgemein über die UI zur Verfügung gestellt werden, ohne in die physikalische Ebene einzugreifen.
Alles innerhalb der layline.io Plattform ist auf der Ausführungsebene standardisiert, aber auf der Konfigurationsebene offen. Dies erlaubt es Ihnen, das einzurichten, was Sie brauchen, ohne sich um die schwierigen Teile der Infrastruktur kümmern zu müssen.
Auch wenn das Konzept eines Frameworks nicht unbedingt das ist, was hartgesottene "Nur-Low-Level"-Entwickler mögen, macht es technisch und geschäftlich sehr viel Sinn. Sie würden ja auch nicht Ihre eigene Datenbank programmieren, oder doch?
Resources
- Top 10 Challenges of Using Microservices for Managing Distributed Systems
- Here’s Why Microservices Desperately Need Service Mesh Anomaly Detection.
- Erfahren Sie hier mehr über layline.io.
- Kontaktieren Sie uns hello@layline.io.