Die Arbeit befasst sich mit einem neuen Architekturmuster, dem Microservices-Architekturmuster. Tatsächlich ist das Microservices-Architekturmuster auf dem aktuellen Markt nicht sehr weit verbreitet und stellt daher für viele ein fremdes Architekturmuster dar. Dennoch kommt es bei vielen großen Firmen wie Netflix, Amazon, Microsoft bereits zur Anwendung. Das Microservices-Architekturmuster beinhaltet viele neue Aspekte beim Software-Design, die eine deutliche Verbesserung der Softwarequalität mit sich bringen.
Das erste Kapitel widmet sich der Definiton des Microservices-Architekturmusters. In diesem Rahmen werden wir die Vor- und Nachteile sowie die wichtigsten Eigenschaften dieses Architekturmusters erläutern. Im zweiten Kapitel werden wir die Serviceorientierte-Architektur definieren und darauf aufbauend sie mit der Microservices-Architektur vergleichen. Kapitel drei wird das Prinzip von Domain Driven Design definieren und sei-ne wichtigsten Aspekten erklären. Im vierten Kapitel wird die Kommunikation bei einer Microservices-Architektur mit ihren beiden Arten: synchron und asynchron vorgestellt. Abschließend werden wir eine Musterarchitektur beschreiben, dabei die wichtigsten Aspekte erwähnen und erklären, die beim Designen eines Microservices-Systems berück-sichtigen werden müssen.
Insbesondere bietet die Microservices-Architektur eine Lösung für viele Probleme, die aus anderen Architekturmustern stammen. Das monolithische Architekturmuster stellt zurzeit das bekannteste und am häufigsten gebrauchte Architekturmuster dar. Diese Art der Architektur ist jedoch für viele Enterprise-Anwendungen nicht mehr passend, wes-halb andere Lösungen hermüssen. Diese Ausarbeitung befasst sich mit den Nachteilen bzw. Problemen der monolithischen Architektur und erklärt wie die Microservices-Architektur damit umgeht bzw. diese Probleme löst. Dabei werden diverse Basispunkte des Microservices-Architekturmusters erklärt, wobei nicht alle Aspekte der Microservices-Architektur erläutert werden, sondern nur die wichtigsten. Viele sind der Ansicht bei der Microservices-Architektur handele es sich um eine SOA (Serviceorientierte-Architektur). Ob diese Ansicht korrekt ist (Microservices-Architektur gleich SOA), werden wir in dieser Ausarbeitung durch einen Vergleich der Serviceorientierten-Architektur mit der Microservices-Architektur herausfinden.
Inhaltsverzeichnis
1 Einleitung
2 Definition des Microservices-Architekturmusters
2.1 Einleitung
2.2 Vorteile und Nachteile
2.2.1 Vorteile
2.2.2 Nachteile
2.3 Die wichtigsten Eigenschaften
2.3.1 Lose Kopplung
2.3.2 Hochgradige Geschlossenheit
3 Microservices-Architektur vs Serviceorientierte Architektur (SOA)
3.1 Einleitung
3.2 Serviceorientierte Architektur
3.2.1 Definition
3.3 Unterschied zwischen Microservices-Architektur und SOA
3.4 Zusammenfassung
4 Musterarchitektur
4.1 Einführung
4.2 Problemstellung
4.3 Architektur
4.3.1 Klassendiagramm
4.4 Aufteilung auf Microservices
4.5 Zusammenfassung
Zielsetzung & Themen
Die Arbeit verfolgt das Ziel, das Microservices-Architekturmuster als moderne Alternative zum traditionellen monolithischen Ansatz zu analysieren, seine Vor- und Nachteile zu evaluieren und von der serviceorientierten Architektur (SOA) abzugrenzen.
- Vergleich zwischen monolithischen Systemen und Microservices.
- Analyse der Vorteile wie Skalierbarkeit und technologische Vielfalt sowie Herausforderungen wie Komplexität.
- Abgrenzung der Microservices-Architektur von der serviceorientierten Architektur (SOA).
- Darstellung technischer Implementierungsaspekte anhand einer Musterarchitektur.
- Diskussion der Bedeutung von Service-Registry, Load-Balancing und asynchroner Kommunikation.
Auszug aus dem Buch
2.2.1 Vorteile
In diesem Teil werden nicht alle Vorteile genannt, sondern die wichtigsten davon [2].
Heterogenität der Technologien
Bei einem System, das aus mehreren kollaborierenden Services besteht, kann man in den einzelnen Services je nach Bedarf unterschiedliche Technologien einsetzen. Dadurch sind die Architekten sehr flexibel darin die entsprechenden Technologien zu jedem Task zu wählen.
Die einzelnen Microservices können in verschiedenen Programmiersprachen entwickelt werden, wobei jeder Microservice eine eigene Datenbank hat (wenn er eine braucht). Die Datenbanken können auch unterschiedlich sein (GraphDB: Neo4J, DokumentenDB: MongoDB, etc.). Weil die Microservices total voneinander unabhängig sind, ist die Integration bzw. das Ausprobieren neuer Technologien einfach, da das Risiko sehr niedrig ist, dass andere Microservices von den Änderungen beschädigt werden. Man soll aber natürlich bei der Anzahl der Technologien nicht übertreiben.
Belastbarkeit
„Bounded context“: Dies ist ein sehr wichtiger Aspekt in der Microservices-Architektur und darauf werden wir im folgenden Kapitel noch genauer eingehen. Die Unabhängigkeit und das Abschotten der Microservices spielen eine wesentliche Rolle, wenn man ein stabiles System und eine hohe Belastbarkeit gewährleisten will. Beim Microservices-Architekturmuster kann es sein, dass einer der Microservices ausfällt. Das System soll aber immer lauffähig sein. Die Ursachen und die Fehler, die zu diesem Ausfall geführt haben, kann man ganz schnell und einfach beheben, da die Microservices nicht zu groß sind. Das ist aber nicht der Fall bei den monolithischen Systemen. Dabei führt ein Fehler zum Ausfall des ganzen Systems. Um das System wieder lauffähig zu bekommen, muss man den Fehler beheben und das System neu deployen. Das ist aber kompliziert bei einem großen monolithischen System.
Zusammenfassung der Kapitel
1 Einleitung: Die Einleitung führt in das Konzept der Systemarchitektur ein, positioniert Microservices als Lösung für Probleme monolithischer Architekturen und stellt den Vergleich zu SOA als zentrales Ziel der Arbeit vor.
2 Definition des Microservices-Architekturmusters: Dieses Kapitel definiert den Begriff der Microservices-Architektur, beleuchtet deren Vor- und Nachteile sowie die entscheidenden Eigenschaften der losen Kopplung und der hohen Geschlossenheit.
3 Microservices-Architektur vs Serviceorientierte Architektur (SOA): Hier werden die beiden Ansätze gegenübergestellt, definiert und anhand kritischer Merkmale wie Heterogenität, Bounded Context und Kommunikation voneinander abgegrenzt.
4 Musterarchitektur: In diesem praktischen Kapitel wird ein konkretes Fallbeispiel einer Prüfungssystems-Architektur genutzt, um die Implementierung von Microservices, einschließlich technischer Aspekte wie Registry und Load-Balancing, zu verdeutlichen.
Schlüsselwörter
Microservices, Softwarearchitektur, Monolith, SOA, Skalierbarkeit, Lose Kopplung, Bounded Context, Serviceregistry, Load-Balancing, Komplexität, Java, Spring, REST, DevOps, Fehlertoleranz
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit behandelt die Microservices-Architektur als alternatives Architekturmuster zur klassischen monolithischen Softwareentwicklung und untersucht deren Chancen und Risiken.
Was sind die zentralen Themenfelder?
Zu den zentralen Themen gehören die Abgrenzung zu monolithischen Systemen, der Vergleich mit der Serviceorientierten Architektur (SOA) sowie die technische Implementierung von Microservices-Systemen.
Was ist das primäre Ziel der Forschungsarbeit?
Das primäre Ziel ist es, das Microservices-Architekturmuster verständlich zu machen, seine spezifischen Eigenschaften zu analysieren und Kriterien für dessen Anwendung im Vergleich zu SOA aufzuzeigen.
Welche wissenschaftliche Methode wird verwendet?
Die Arbeit stützt sich auf eine theoretische Analyse bestehender Architekturmuster, einen vergleichenden Diskurs zu SOA sowie ein praktisches Fallbeispiel zur Illustration der technischen Umsetzung.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil gliedert sich in die Definition von Microservices, deren Vor- und Nachteile, den Vergleich mit der SOA und die praktische Modellierung einer Musterarchitektur anhand eines Beispiels aus dem Hochschulumfeld.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die Arbeit wird maßgeblich durch Begriffe wie Microservices, Skalierbarkeit, Lose Kopplung, Bounded Context und Fehlertoleranz charakterisiert.
Wie unterscheidet sich die Kommunikation in einer Microservices-Architektur von der in einer SOA?
Während bei einer SOA die Kommunikation oft zentral über einen Enterprise Service Bus (ESB) gesteuert wird, setzen Microservices stärker auf direkte Interaktion, beispielsweise über REST, wobei die Dezentralität und Unabhängigkeit der Dienste im Vordergrund steht.
Was bedeutet das Prinzip des "Bounded Context" in diesem Kontext?
Der "Bounded Context" beschreibt eine wichtige Entwurfsgrenze, innerhalb derer ein Modell oder ein Service konsistent bleibt, was die Unabhängigkeit der Microservices unterstreicht und die Datenkonsistenz innerhalb der Servicegrenzen sicherstellt.
- Citation du texte
- Saifeddine Bargui (Auteur), 2019, Microservices Architektur. Definition, Chancen und Risiken, Munich, GRIN Verlag, https://www.grin.com/document/542013
