Vielen Dank fur Ihre Anfrage.
Wir melden uns in Kürze bei Ihnen.
START A CONVERSATION
Share your requirements and we'll get back to you with how we can help.
AUFBAU VON ANWENDUNGEN MIT MICROSERVICE-ARCHITEKTUR
Die Microservice-Architektur (MSA) hat an Popularität gewonnen, da sie ein wesentlicher Faktor für die Agilität ist. Vorreiter wie Netflix und Amazon und viele andere große Webanwendungen sind aus Gründen der schnelleren Skalierbarkeit und der kontinuierlichen Innovation von monolithischen Einheiten zu Microservices übergegangen.
Gegenwärtig setzen mittelständische und sogar kleinere Unternehmen diesen modularen, serviceorientierten Ansatz ein, um die Entwicklungszeit erheblich zu verkürzen und schneller auf den Markt zu kommen.
Die rasante Digitalisierung und das verteilte Cloud Computing begünstigen zwar die Microservice-Architektur, sie muss aber nicht in jedem Fall der Standardansatz sein. Der Schlüssel liegt darin, den Bedarf zu erkennen, ohne blindlings einer Modeerscheinung zu folgen, und hier beweisen die QBurst-Architekten ihr Geschick.
Was ist eine Microservice-Architektur?
Microservice-Architektur bezieht sich auf einen Software-Design-Stil, bei dem verschiedene Komponenten als isolierte Dienste erstellt und gewartet werden. Jeder Microservice ist als kleiner Dienst für eine einzelne Geschäftsfunktion gedacht und wird einzeln bereitgestellt, ohne den Rest des Systems zu beeinträchtigen.
Traditionell wurden Anwendungen als eine einzige, zusammenhängende Einheit entwickelt, in der alle Funktionalitäten miteinander verwoben waren. Solche Software wird in der Regel auf einem einzigen Rechner eingesetzt und kann nur vertikal skaliert werden. Da dies nicht praktikabel war, wurden die logischen Einheiten innerhalb des monolithischen Systems in physische Schichten wie die Benutzeroberfläche, die Serverlogik oder den Webservice und die Datenbank für die Speicherung unterteilt (Schichtenarchitektur).
Schließlich wurde die serviceorientierte Architektur (SOA), bei der die Webservice-Schicht vertikal in verschiedene Dienste und die DB-Schicht in entsprechende Speicherlösungen aufgeteilt wird, zu einem praktikablen Konzept für eine einfache Skalierung. Die Microservice-Architektur kann als fortschrittliche Weiterentwicklung der SOA betrachtet werden.
Nachfolgend ist eine Beispielanwendung für einen Einzelhändler mit Microservice-Architektur dargestellt. Jeder Dienst ist für eine einzelne Geschäftsfunktion zuständig. Gleichzeitig kommunizieren die Microservices miteinander, um die benötigten Informationen zu erhalten.
Beispiel für eine Microservice-Architektur in einer eCommerce-Anwendung
Mögliche Gründe für Microservices
Ob groß oder klein, Unternehmen müssen ständig die wachsenden Anforderungen und Erwartungen ihrer Kunden erfüllen, um relevant zu bleiben. Während die herkömmliche Art der Softwareentwicklung und -bereitstellung oft nicht mithalten kann, bietet der Microservices-Ansatz bestimmte Vorteile, die es Unternehmen ermöglichen, flexibel und wettbewerbsfähig zu bleiben.
Flexibilität beim Technologieeinsatz
MSA ermöglicht die harmonische Koexistenz entkoppelter, in verschiedenen Sprachen geschriebener Dienste. So haben Sie die Freiheit, für jede Geschäftsfunktion den am besten geeigneten Technologie-Stack zu wählen.
Autonome Teams
Global verteilte Teams können produktiver arbeiten, wenn die Lösung in kleinere, voneinander unabhängige Fragmente zerlegt wird.
Kontinuierliche Bereitstellung
Da verschiedene Teams an unterschiedlichen Komponenten arbeiten, wird die Entwicklung beschleunigt und die Flexibilität des Unternehmens erhöht. Sie können neue Komponenten hinzufügen, bereitstellen und diese unabhängig voneinander skalieren.
Einfachere Wartung
Sie können so Fehler isolieren und einen Microservice modifizieren, ohne das gesamte System zu beeinträchtigen. Dies erleichtert die Wartung der Anwendungen im Vergleich zu komplexen monolithischen Systemen.
Implementierung einer Microservice-Architektur
Entscheidungsphase
Obwohl es gute Gründe für die Einführung von Microservices gibt, ist der Übergang oft nicht einfach. Um eine Microservice-Architektur erfolgreich zu implementieren, muss Ihre gesamte Organisation (Geschäftsteams, Entwicklung, IT-Support, Sicherheit) bereit sein, den Betrieb neu auszurichten und zu optimieren.
Ganz gleich, ob Sie eine neue Anwendung erstellen, einer bestehenden Anwendung neue Funktionen hinzufügen oder Ihre Legacy-Anwendung modernisieren – die wichtigste Entscheidung ist, ob Sie Microservices tatsächlich benötigen. Als Berater mit Erfahrung in der Implementierung von Microservice-Architekturen verstehen wir die Komplexität. Unser Team arbeitet mit Unternehmen zusammen, um festzustellen, ob Microservices für sie geeignet sind, und unterstützt Kunden bei der Einführung der Architektur durch bewährte Verfahren.
Klein anfangen und skalieren
Wir empfehlen eine schrittweise Umwandlung, bei der wir Ihre Anwendung schrittweise in eine Reihe kleinerer Komponenten refaktorisieren, ohne das gesamte System zu zerlegen und den Betrieb zu unterbrechen.
Jeder Microservice dient einer anderen Geschäftsfunktion. Der erste Schritt besteht also darin, eine Reihe von Funktionalitäten zu ermitteln, die als eigenständige Einheit zusammengefasst werden können. Eine komplexe Legacy-Anwendung kann viele solcher Module enthalten, die in eigenständige Microservices umgewandelt werden können.
Unsere Aufgabe besteht darin, die zu extrahierenden Module zu identifizieren und zu priorisieren. Module, die am wenigsten geschäftskritisch, leichter zu extrahieren, am nützlichsten sind oder besondere Ressourcenanforderungen haben, können Kandidaten für ein frühes Refactoring sein. Mit jedem Modul, das in einen Microservice umgewandelt wird, schrumpft der monolithische Aufbau, bis er schließlich nur noch aus Microservices besteht.
DevOps und Microservices
Microservices funktionieren besser in Verbindung mit DevOps, um die Agilität und Effizienz zu steigern. DevOps-Teams können parallel an unabhängigen Modulen arbeiten und so die Entwicklung beschleunigen. Da die Anzahl der Microservices zunimmt, ermöglichen automatisierte kontinuierliche Integrations- und Bereitstellungspipelines inkrementelle Releases und reduzieren gleichzeitig manuelle Fehler. In die CI/CD-Pipeline integrierte kontinuierliche Tests ermöglichen eine höhere Produktqualität.
Der unabhängige Charakter von Microservices hilft DevOps-Teams dabei, in kürzerer Zeit mehr zu erreichen. Zusammen können diese beiden Ansätze die Innovation beschleunigen und einen größeren Geschäftswert schaffen.
Bereitstellungsmodell
Container eignen sich perfekt für Microservice-Architekturen, da sie eine konsistente Umgebung von der Entwicklung über das Testen bis zur endgültigen Bereitstellung bieten. Die Verwendung einer virtuellen Maschine für jeden Microservice kann erhebliche Mehrkosten verursachen und die Bereitstellung mehrerer Microservices in einer einzigen virtuellen Maschine kann zu Konflikten zwischen den Services führen. Da mehrere Container von einem einzigen Betriebssystem unterstützt werden können, ist die Verwendung von Containern für Microservice-Architekturen weitaus effizienter als virtuelle Maschinen.
Auch unter dem Gesichtspunkt der Performance ist die Containerisierung von Vorteil. Da Container sehr kompakt sind, lassen sie sich schnell starten und passen besser zu den schwankenden Arbeitslasten von Microservices-basierten Anwendungen. Eine differenzierte Ausführungsumgebung, die Möglichkeit, mehrere Komponenten in einem einzigen Betriebssystem unterzubringen, und eine bessere Reaktion auf unregelmäßige Arbeitslasten machen Container oft zur bevorzugten Wahl für Microservice-Anwendungen.
Um die Bereitstellung von containerisierten Microservices zu automatisieren und all Ihre verschiedenen Microservices einfach zu verwalten, können wir Tools zur Container-Orchestrierung wie Kubernetes einrichten.
Umfassendes Monitoring
Die Überwachung von Tausenden von Microservices ist mühsam im Vergleich zu einem monolithischen System, bei dem man nur eine Stelle im Auge behalten muss. Um einen Überblick über die große Anzahl von Mikrokomponenten und eine einfache Fehlersuche zu ermöglichen, benötigen Sie eine zentrale Protokollierung und ein Dashboard.
Es gibt zahlreiche Open-Source-Tools zur Überwachung von containerisierten Microservices. Mit Tools wie Fluentd oder Logstash können wir Protokolle von jedem Microservice in einer zentralen Datenbank sammeln. Die Datenbank indiziert und speichert die Daten für zukünftige Abfragen. Mit Tools wie Kibana lassen sich visuelle Dashboards erstellen, die die aus der Protokollanalyse gewonnenen Erkenntnisse darstellen.
Serviceübergreifende Kommunikation
Eine häufige Herausforderung in der Microservice-Architektur ist die Kommunikation zwischen den Diensten. Ein Microservice ruft andere Microservices nicht direkt auf; stattdessen werden die Aufrufe über einen Message Broker oder ein API-Gateway weitergeleitet. Microservices können auch Daten mittels Background Workern importieren/exportieren.
Wenn eine Benutzeraktion erfordert, dass mehrere Dienste über das Netz durch Remote-Aufrufe miteinander interagieren, kann die Nichtverfügbarkeit oder hohe Latenz eines einzigen Dienstes zu einem Ausfall führen, der sich auf die gesamte Anwendung ausweitet. Das Schutzschaltermuster kann verwendet werden, um Ausfallzeiten oder Latenzzeiten von wichtigen Diensten zu überbrücken. Durch diese Methode kann sich der nicht reagierende Dienst erholen, indem seine Last verringert wird. Nach einer bestimmten Anzahl von fehlgeschlagenen Antworten meldet der Schutzschalter einen Fehler zurück, ohne den Dienst aufzurufen. Die Verbindung zu diesem Dienst wird nur dann wiederhergestellt, wenn die regelmäßigen Überprüfungen erfolgreich waren; andernfalls bleibt der Schaltkreis offen.
Wenn die Anzahl der Microservices steigt, wird die Kommunikation zwischen den Services immer schwieriger. Service-Discovery, Lastenverteilung, Leitungsunterbrechung, Authentifizierung und verschiedene andere Funktionen, die für jeden einzelnen Microservice erforderlich sind, können in eine separate, allen gemeinsame Schicht ausgelagert werden. Eine solche Infrastrukturebene zur Abwicklung der Kommunikation zwischen Diensten in einer Microservice-Architektur ist das Service-Mesh.
Da der Großteil der Netzwerkkommunikation auf das Service-Mesh ausgelagert ist, können sich die Entwickler auf die Geschäftslogik konzentrieren. Microservices, die in einer beliebigen Sprache geschrieben wurden, funktionieren mit dem Service-Mesh, das sprachunabhängig ist. Istio, Linkerd und Conduit sind einige der gängigen Implementierungen, wobei Conduit als ideal für Kubernetes-Umgebungen gilt.
Sicherheitsherausforderungen
Die Sicherheit in einer Microservices-Umgebung erfordert einen anderen Ansatz als in monolithischen Systemen. Die dienstübergreifende Kommunikation über das Netz bietet Dritten die Möglichkeit, sich in das System einzuhacken. Unsere Architekten arbeiten eng mit Sicherheitsexperten zusammen und setzen die richtigen Tools ein, um Anwendungen in solchen dezentralen Umgebungen zu sichern.
Identitätszugriffsmanagement
Wir können zwar ein benutzerdefiniertes Autorisierungsprotokoll erstellen, aber es gibt bereits Industriestandards wie OAuth-basierte Autorisierungsdienste, die verwendet werden können.
Zero-Trust-Modell
Jeder Microservice kann einzeln authentifiziert und autorisiert werden. Eine solche „niemals vertrauen, immer überprüfen“-Richtlinie gewährleistet eine höhere Sicherheit.
Defense in Depth
Die Anwendung verschiedener Sicherheitsebenen auf die sensibelsten Dienste macht es Angreifern schwerer, in diese einzudringen.
DevSecOps
Die Integration der Sicherheit in den CI/CD-Zyklus mit Sicherheits-Unit-Tests, rollenbasierten Zugriffskontrollrichtlinien und Container-Härtungsmaßnahmen sorgt für eine bessere Anwendungssicherheit.
Entscheidungsphase
Obwohl es gute Gründe für die Einführung von Microservices gibt, ist der Übergang oft nicht einfach. Um eine Microservice-Architektur erfolgreich zu implementieren, muss Ihre gesamte Organisation (Geschäftsteams, Entwicklung, IT-Support, Sicherheit) bereit sein, den Betrieb neu auszurichten und zu optimieren.
Ganz gleich, ob Sie eine neue Anwendung erstellen, einer bestehenden Anwendung neue Funktionen hinzufügen oder Ihre Legacy-Anwendung modernisieren – die wichtigste Entscheidung ist, ob Sie Microservices tatsächlich benötigen. Als Berater mit Erfahrung in der Implementierung von Microservice-Architekturen verstehen wir die Komplexität. Unser Team arbeitet mit Unternehmen zusammen, um festzustellen, ob Microservices für sie geeignet sind, und unterstützt Kunden bei der Einführung der Architektur durch bewährte Verfahren.
Klein anfangen und skalieren
Wir empfehlen eine schrittweise Umwandlung, bei der wir Ihre Anwendung schrittweise in eine Reihe kleinerer Komponenten refaktorisieren, ohne das gesamte System zu zerlegen und den Betrieb zu unterbrechen.
Jeder Microservice dient einer anderen Geschäftsfunktion. Der erste Schritt besteht also darin, eine Reihe von Funktionalitäten zu ermitteln, die als eigenständige Einheit zusammengefasst werden können. Eine komplexe Legacy-Anwendung kann viele solcher Module enthalten, die in eigenständige Microservices umgewandelt werden können.
Unsere Aufgabe besteht darin, die zu extrahierenden Module zu identifizieren und zu priorisieren. Module, die am wenigsten geschäftskritisch, leichter zu extrahieren, am nützlichsten sind oder besondere Ressourcenanforderungen haben, können Kandidaten für ein frühes Refactoring sein. Mit jedem Modul, das in einen Microservice umgewandelt wird, schrumpft der monolithische Aufbau, bis er schließlich nur noch aus Microservices besteht.
DevOps und Microservices
Microservices funktionieren besser in Verbindung mit DevOps, um die Agilität und Effizienz zu steigern. DevOps-Teams können parallel an unabhängigen Modulen arbeiten und so die Entwicklung beschleunigen. Da die Anzahl der Microservices zunimmt, ermöglichen automatisierte kontinuierliche Integrations- und Bereitstellungspipelines inkrementelle Releases und reduzieren gleichzeitig manuelle Fehler. In die CI/CD-Pipeline integrierte kontinuierliche Tests ermöglichen eine höhere Produktqualität.
Der unabhängige Charakter von Microservices hilft DevOps-Teams dabei, in kürzerer Zeit mehr zu erreichen. Zusammen können diese beiden Ansätze die Innovation beschleunigen und einen größeren Geschäftswert schaffen.
Bereitstellungsmodell
Container eignen sich perfekt für Microservice-Architekturen, da sie eine konsistente Umgebung von der Entwicklung über das Testen bis zur endgültigen Bereitstellung bieten. Die Verwendung einer virtuellen Maschine für jeden Microservice kann erhebliche Mehrkosten verursachen und die Bereitstellung mehrerer Microservices in einer einzigen virtuellen Maschine kann zu Konflikten zwischen den Services führen. Da mehrere Container von einem einzigen Betriebssystem unterstützt werden können, ist die Verwendung von Containern für Microservice-Architekturen weitaus effizienter als virtuelle Maschinen.
Auch unter dem Gesichtspunkt der Performance ist die Containerisierung von Vorteil. Da Container sehr kompakt sind, lassen sie sich schnell starten und passen besser zu den schwankenden Arbeitslasten von Microservices-basierten Anwendungen. Eine differenzierte Ausführungsumgebung, die Möglichkeit, mehrere Komponenten in einem einzigen Betriebssystem unterzubringen, und eine bessere Reaktion auf unregelmäßige Arbeitslasten machen Container oft zur bevorzugten Wahl für Microservice-Anwendungen.
Um die Bereitstellung von containerisierten Microservices zu automatisieren und all Ihre verschiedenen Microservices einfach zu verwalten, können wir Tools zur Container-Orchestrierung wie Kubernetes einrichten.
Umfassendes Monitoring
Die Überwachung von Tausenden von Microservices ist mühsam im Vergleich zu einem monolithischen System, bei dem man nur eine Stelle im Auge behalten muss. Um einen Überblick über die große Anzahl von Mikrokomponenten und eine einfache Fehlersuche zu ermöglichen, benötigen Sie eine zentrale Protokollierung und ein Dashboard.
Es gibt zahlreiche Open-Source-Tools zur Überwachung von containerisierten Microservices. Mit Tools wie Fluentd oder Logstash können wir Protokolle von jedem Microservice in einer zentralen Datenbank sammeln. Die Datenbank indiziert und speichert die Daten für zukünftige Abfragen. Mit Tools wie Kibana lassen sich visuelle Dashboards erstellen, die die aus der Protokollanalyse gewonnenen Erkenntnisse darstellen.
Serviceübergreifende Kommunikation
Eine häufige Herausforderung in der Microservice-Architektur ist die Kommunikation zwischen den Diensten. Ein Microservice ruft andere Microservices nicht direkt auf; stattdessen werden die Aufrufe über einen Message Broker oder ein API-Gateway weitergeleitet. Microservices können auch Daten mittels Background Workern importieren/exportieren.
Wenn eine Benutzeraktion erfordert, dass mehrere Dienste über das Netz durch Remote-Aufrufe miteinander interagieren, kann die Nichtverfügbarkeit oder hohe Latenz eines einzigen Dienstes zu einem Ausfall führen, der sich auf die gesamte Anwendung ausweitet. Das Schutzschaltermuster kann verwendet werden, um Ausfallzeiten oder Latenzzeiten von wichtigen Diensten zu überbrücken. Durch diese Methode kann sich der nicht reagierende Dienst erholen, indem seine Last verringert wird. Nach einer bestimmten Anzahl von fehlgeschlagenen Antworten meldet der Schutzschalter einen Fehler zurück, ohne den Dienst aufzurufen. Die Verbindung zu diesem Dienst wird nur dann wiederhergestellt, wenn die regelmäßigen Überprüfungen erfolgreich waren; andernfalls bleibt der Schaltkreis offen.
Wenn die Anzahl der Microservices steigt, wird die Kommunikation zwischen den Services immer schwieriger. Service-Discovery, Lastenverteilung, Leitungsunterbrechung, Authentifizierung und verschiedene andere Funktionen, die für jeden einzelnen Microservice erforderlich sind, können in eine separate, allen gemeinsame Schicht ausgelagert werden. Eine solche Infrastrukturebene zur Abwicklung der Kommunikation zwischen Diensten in einer Microservice-Architektur ist das Service-Mesh.
Da der Großteil der Netzwerkkommunikation auf das Service-Mesh ausgelagert ist, können sich die Entwickler auf die Geschäftslogik konzentrieren. Microservices, die in einer beliebigen Sprache geschrieben wurden, funktionieren mit dem Service-Mesh, das sprachunabhängig ist. Istio, Linkerd und Conduit sind einige der gängigen Implementierungen, wobei Conduit als ideal für Kubernetes-Umgebungen gilt.
Sicherheitsherausforderungen
Die Sicherheit in einer Microservices-Umgebung erfordert einen anderen Ansatz als in monolithischen Systemen. Die dienstübergreifende Kommunikation über das Netz bietet Dritten die Möglichkeit, sich in das System einzuhacken. Unsere Architekten arbeiten eng mit Sicherheitsexperten zusammen und setzen die richtigen Tools ein, um Anwendungen in solchen dezentralen Umgebungen zu sichern.
Identitätszugriffsmanagement
Wir können zwar ein benutzerdefiniertes Autorisierungsprotokoll erstellen, aber es gibt bereits Industriestandards wie OAuth-basierte Autorisierungsdienste, die verwendet werden können.
Zero-Trust-Modell
Jeder Microservice kann einzeln authentifiziert und autorisiert werden. Eine solche „niemals vertrauen, immer überprüfen“-Richtlinie gewährleistet eine höhere Sicherheit.
Defense in Depth
Die Anwendung verschiedener Sicherheitsebenen auf die sensibelsten Dienste macht es Angreifern schwerer, in diese einzudringen.
DevSecOps
Die Integration der Sicherheit in den CI/CD-Zyklus mit Sicherheits-Unit-Tests, rollenbasierten Zugriffskontrollrichtlinien und Container-Härtungsmaßnahmen sorgt für eine bessere Anwendungssicherheit.
Den Monolithen durch Microservices ersetzen
Bei der Anwendung unseres Kunden handelte es sich um ein Rapid-Prototyping-Tool für Produktdesign und -entwicklung. Die Anwendung war ein Monolith mit eng gekoppeltem Client und Server, sodass die Komponenten nicht separat entwickelt oder skaliert werden konnten. Das QBurst-Team wurde gebeten, den Technologie-Stack zu bewerten, dessen Mängel zu verstehen und eine neue Lösung vorzuschlagen.
Neben erheblichen Leistungseinschränkungen ergab unsere technische Bewertung ernsthafte Bedenken hinsichtlich der Quellcode-Wartung, der Codequalität und der allgemeinen Skalierbarkeit der Anwendung. Wir schlugen vor, das System als N-Tier-Anwendung mit Schichten in einem Microservices-Modell umzugestalten, bei dem jedes Modul unabhängig und lose mit anderen gekoppelt ist. Die hybride Microservice-Architektur sollte eine einzige, gemeinsam genutzte Datenbank anstelle eines Datenbank-pro-Service-Modells verwenden.
Wir schlugen eine vollständige Automatisierung des Lebenszyklus der neuen Anwendung vor. Die Erstellung und Bereitstellung der Microservices sollte mit Jenkins automatisiert werden. Mit der Einführung von IaC (Infrastructure as Code) konnten auch die Bereitstellung, Überwachung und Verwaltung der Infrastruktur automatisiert werden. Die Dockerisierung der Anwendung würde dazu beitragen, die Ressourcennutzung zu verringern und schnelle Bereitstellungen zu ermöglichen, während Orchestrierungstools die Verwaltung des Lebenszyklus von Containern vereinfachen würden. Abschließend wurde eine kontinuierliche Infrastrukturüberwachung und Protokollverwaltung mit dem ELK-Stack vorgeschlagen.