Microservices Architektur. Definition, Chancen und Risiken

Inhaltsverzeichnis

Abbildungsverzeichnis

Motivation

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

Lieraturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1 : Microservices: fachlich getrennt

Abbildung 2.2 : Eine monolithische Architektur: einzige zentrale Komponente

Abbildung 2.3 : Skalierung des monolithischen Systems

Abbildung 2.4 : Skalierung in der Microservices-Architektur

Abbildung 3.1 : Enterprise Service Bus

Abbildung 4.1 : Klassendiagramm

Motivation

Beim sogenannten monolithischen Architekturmuster handelt es sich um eins von aktuell zwei vorherrschenden Architekturmustern, das das traditionelle Vorgehen für die Softwa­reentwicklung darstellt.

Dabei sind alle Bestandteile eines monolithischen Systems miteinander verbunden und tauschen sich mit derselben zentralen Datenbank (eine JAR/WAR Datei für das gesamte System) aus. Wichtigster Vorteil eines monolithischen Systems ist die Geschwindigkeit der Kommunikation zwischen den Komponenten bedingt dadurch, dass die verschiede­nen Komponenten durch Funktionsaufrufe miteinander kommunizieren. Diese Art der Kommunikation stellt einen der Hauptunterschiede zwischen dem monolithischen Archi­tekturmuster und dem Microservices-Architekturmuster dar.

Alle Komponenten eines monolithischen Systems müssen in derselben Programmier­sprache geschrieben werden, da selbt die kleinste Änderung einer einzigen Komponente Fehler bei mehreren anderen Komponenten zur Folge haben kann. Sudhir Tonse von Net­flix hat (bei AWS re:Invent 2014) ein Beispiel dafür gegeben, dass ein fehlendes Semikolon in 2008 die ganze Netflix-Webseite für mehrere Stunden ausfallen ließ.¹

Aufgrund der Tatsache, dass bei monolithischen Systemen die Komponenten sowohl unterschiedliche Ressourcen als auch unterschiedliches Verhalten haben, sollte der Syste­madmin im Bedarfsfall eine Komponente skalieren können (für den Fall, dass eine Kom­ponente durch eine große Menge von Anfragen belastet ist). Diese Möglichkeit ist jedoch bei den monolithischen Systemen nicht gegeben.

Im Gegensatz dazu wird beim Microservices-Architekturmuster das System auf meh­rere Services (nach Fachlichkeit) verteilt, die miteinander kommunizieren können, wobei jeder Service bestimmte Funktionalitäten aufweist, entsprechend dem Prinzip von der objektorientierten Entwicklung „Single Responsibility“.

Es ist möglich die Services in verschiedenen Programmiersprachen zu entwickeln, die dann miteinander asynchron (AMQP: Advanded Messaging Queuing Protocol) oder syn­chron (HTTP/REST) durch eine API kommunizieren können. Die Services können auf mehreren Rechenzentren deployt werden und auch einzeln skaliert werden. Durch das Ein­setzen von einem API-Gateway erhält der Client ein „Single point of entry“ (der Client spricht nur das Gateway an) und das Gateway übernimmt die Weiterleitung der Anfragen zu den jeweiligen Microservices (Load Balancing).

Kapitel 1

Einleitung

Das wichtigste Konzept in der Softwareentwicklung bildet die System-Architektur. Die Auswahl der entsprechenden Architektur für eine Software ist daher von immenser Wich­tigkeit und soll hinsichtlich des Architekturmusters nach bestimmten Kriterien entschie­den werden. Sofern nicht das passende Architekturmuster für ein Problem ausgewählt wurde, kann dies später enorme Kosten verursachen, insbesondere wenn sich das System in einer fortgeschrittenen Entwicklungsphase befindet.

Die hiesige Ausarbeitung befasst sich mit einem neuen Architekturmuster und zwar 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.

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 her müssen. Diese Ausarbeitung befasst sich mit den Nachtei­len 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.

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 ver­gleichen. Kapitel drei wird das Prinzip von Domain Driven Design definieren und sei­ne wichtigsten Aspekten erklären. Im vierten Kapitel wird die Kommunikation bei ei­ner Microservices-Architektur mit ihren beiden Arten: synchron und asynchron vorge­stellt. 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.

Kapitel 2

Definition des Microservices-Architekturmusters

2.1 Einleitung

Der Begriff „Microservices-Architektur“ beschreibt ein Architekturmuster, das darauf aufbaut ein System in voneinander unabhängige Services aufzuteilen. Dabei läuft jeder Service als eigenständiger Prozess. Die Trennung der Services erfolgt nach Fachlichkeit.

Dabei sollen die verschiedenen Services nicht zu groß sein und sie kommunizieren mit­einander meistens über HTTP (APIs). Die Services werden einzeln und völlig unabhängig voneinander deployt, daher haben sie keinen Einfluss aufeinander mit der Folge, dass wenn ein Service modifiziert wird, die anderen Services von den neuen Änderungen nicht berührt werden. Des Weiteren können die Microservices in verschiedenen Programmiersprachen entwickelt werden.

Zur Verdeutlichung der Eigenschaften der Microservices-Architektur wird hier das Microservices-Architekturmuster mit dem monolithischen Architekturmuster verglichen. Enterprise-Applications werden überwiegend nach dem MVC-Designpattern gebaut.

Die Systeme bestehen daher aus drei Teilen: ein Client, der die View darstellt (HTML und JavaScript bei Webanwendungen), eine Datenbank (eine zentrale Datenbank mit einem einzigen Datenbank-Schema) sowie eine serverseitige Anwendung.

Der Client-UI schickt die Anfragen, die von der Anwendung verwaltet werden. Basie-rend auf diesen Anfragen werden CRUD-Funktionen auf der Datenbank oder Rechnungen ausgeführt oder ein HTML-View zum Browser geschickt.

Die Anwendung ist monolithisch und wird als eine einzige zentrale Komponente ge­baut, gebildet und deployt. Wird auch nur eine kleine Komponente von diesem System geändert, muss das gesamte System neudeployt werden und diese Instanz ist während­dessen nicht erreichbar. Dieser Ansatz ist der auf dem Markt am bekanntesten und am meisten verbreitete: View, Model und Controller als ein einziger Prozess. Bei einer mo­nolithischen Architektur erfolgt die Kommunikation durch Funktionsaufrufe, wobei das System nach jeder Änderung getestet werden muss, um sicherzustellen, dass keine Kom­ponente beschädigt wurde. [1, 2].

Wird eine Komponente des monolithischen Systems häufig angefragt bzw. belastet, muss das gesamte System skaliert werden, damit es nicht zum kompletten Ausfall kommt (nur die belastete Komponente zu skalieren ist nicht möglich). Von dem monolithischen System können mehrere Instanzen auf verschiedenen HOSTs gestartet werden, die hinter einem Load-Balancer laufen. Die Anfragen werden dementsprechend zu der am wenigsten belasteten Instanz weitergeleitet. Da das System immer als eine einzige Komponente ska-liert wird, hat ein kleiner syntaktischer Fehler oder ein ähnlicher Fehler auf dem Server zur Folge, dass die ganze Applikation ausfällt und das System nicht mehr zu erreichen ist.

Das monolithische Modell ist auf dem aktuellen Markt sehr verbreitet, hat aber viele Nachteile. Aufgrund dieser Nachteile, sind viele Firmen auf der Suche nach Alternativen zur monolithischen Architektur.

Eine Alternative bietet die Microservices-Architektur. Durch ihren modularen Aufbau ist sie in der Lage, die genannten Nachteile der monolithischen Architektur zu vermeiden bzw. zu lösen. Da es in einer Microservices-Architektur möglich ist nur die Komponenten zu skalieren, die besonders belastet sind. Der Load-Balancer übernimmt die Aufgabe, die Anfragen gleichmässig zu verteilen.

2.2 Vorteile und Nachteile

„ Begin with a monolith Alle Systeme beginnen monolithisch und sobald die monolithische Architektur nicht mehr passt, sollte man zur Microservices-Architektur switchen. Die Microservices-Architektur ist jedoch auch nicht frei von Nachteilen bzw. bringt ebenfalls Probleme mit sich 1.

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: Mon­goDB, 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ängig­keit 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.

Skalierbarkeit

Wenn eine Komponente von einem monolithischen System hoch belastet ist, muss der Systemadministrator das ganze System skalieren, weil es nicht möglich ist, nur die belastete Komponente zu skalieren. Je größer die Anwendung ist, desto länger dauert das Deployment und das Builden des Systems. Dieses Problem wurde durch die Microservices­Architektur gelöst, so dass man nur die belastete Komponente skaliert. Da die Services nicht zu groß sein sollen, ist das Skalieren einfach und schnell. Die Services können jedoch auf verschiedenen Maschinen deployt werden.

Technologische Vielfalt

Bei jedem Mikroservice handelt es sich um eine unabhängig einsetzbare Einheit, daher besteht innerhalb dieser Einheit eine große Auswahl hinsichtlich der Technologie bzw. Frameworks. Microservices können in verschiedenen Sprachen geschrieben werden z.B. in Java, C-Sharp sowie Javascript. Sie verwenden verschiedene Bibliotheken und verschiedene Datenspeicher. Daher ist es den Teams möglich, ein geeignetes Werkzeug für den Job auszuwählen, da einige Sprachen und Bibliotheken für bestimmte Arten von Problemen besser geeignet sind, wodurch das Team effizienter arbeiten kann.3

2.2.2 Nachteile

Die Komplexität

Den größten Nachteil einer Microservices-Architektur bildet deren erhöhte Komplexi­tät im Vergleich zu einer monolithischen Anwendung, welche in direktem Zusammenhang mit der Anzahl der beteiligten Dienste steht. Diese Art von Architektur verfügt über viel mehr bewegliche Teile als gewöhnliche Anwendungen, was einen enormen Aufwand, sorg­fältige Planung und vor allem Automatisierung zur Folge hat, damit die Kommunikation zwischen den Diensten, Überwachung, Test und Bereitstellung bewältigt werden können. Gründe für die erhöhte Komplexität sind folgende:

- vorhandene Tools sind nicht für die Arbeit mit Serviceabhängigkeiten ausgelegt;
- die Zunahme von Sprache und Frameworks kann dazu führen, dass die Anwendung schwer zu pflegen ist;
- da jeder Service seine eigene Datenbank hat, können Transaktionsmanagement und Datenkonsistenz zu einem enormen Aufwand werden;
- jeder Service muss getestet und überwacht werden, der Bedarf an Automatisierung steigt;
- das anfängliche Refactoring einer monolithischen Anwendung kann für große Unter­nehmensanwendungen äußerst komplex sein;
- die Anzahl der Prozesse kann exponentiell wachsen, wenn man die Lastverteilung und die Messaging-Middleware berücksichtigt;
- erhöhte Dokumentationskosten, da das Unternehmen Schemata und Schnittstellen­dokumente auf dem neuesten Stand halten muss;
- es gibt zahlreiche Microservice-Muster, die bestimmen müssen, welches die beste Lösung für Ihre Anwendung ist. 4

Die Kommunikation

Zweiten großen Nachteil bildet die Kommunikation, weil diese durch HTTP geschieht kann der Austauch der Daten zwischen den Microservices je nachdem, ob die Datenmenge zu groß oder der angesprochene Service hoch belastet ist, entsprechend verlangsamt sein. Des Weiteren kann es auch gelegentlich dazu kommen, dass der angesprochene Service down ist, weswegen es auch notwendig ist monitoring tools einzusetzen, um die Verfüg­barkeit und die Erreichbarkeit der Services zu prüfen, damit man die Ausfälle verwalten kann.4

Mikroservices erfordern kulturelle Veränderungen

Eine Mikrodienstleistungsinitiative erfordert ein Umdenken in den Unternehmen, die sie einsetzen wollen. Erforderlich ist eine ausgereifte, agile und DevOps-Kultur. Mit einer mikroservice-basierten Anwendung müssen Teams fähig sein, den gesamten Lebenszy­klus eines Dienstes zu verwalten. Dies erfordert oft die Migration von Kompetenzen und Entscheidungen von Managern und Architekten in einzelne Teams. Diese Änderung der Hierarchie kann für einige Personen innerhalb des Unternehmens problematisch werden. Ein wichtiger erster Schritt ist es daher sicherzustellen, dass sich erfahrene Mitglieder und das obere Management rechtzeitig in die Initiative eingebracht haben. Schließlich kann die Kommunikation zwischen Einzelpersonen und Teams erschwert werden, da Teams nicht immer den Überblick über das Gesamtbild haben und wissen, wie einzelne Services miteinander arbeiten müssen, um eine benutzerfreundliche Anwendung zu erstellen.4

Ein Unternehmen muss auch überprüfen, ob seine Mitarbeiter über die nötigen Fä­higkeiten und Erfahrungen verfügen, die erforderlich sind, um eine mikroservice-basierte Anwendung zu übernehmen. Da ein Team für einen einzelnen Dienst verantwortlich sein kann, müssen Entwickler über Kenntnisse in der Entwicklung, Bereitstellung, dem Testen und der Überwachung einer Anwendung verfügen. Es wird auch eine Anforderung sein sicherzustellen, dass sie DevOps und Release-Fähigkeiten als Komponente für jedes Team haben.4

Kosten

Zu den weiteren Nachteilen der Microservices-Architektur gehören die damit verbun­denen steigenden Kosten. Da die Dienste miteinander kommunizieren müssen, führt dies zu vielen Remote-Aufrufen, was wiederum zu höheren Kosten für Netzwerklatenz und -verarbeitung als bei herkömmlichen Architekturen führt. Die Entwickler werden ihr Bes­tes tun wollen, um die Anzahl der Aufrufe zu reduzieren. Einen weiteren Kostentreiber stellt der höhere Ressourcenbedarf dar, da jeder Dienst seine eigene Laufzeitumgebung und CPU benötigt. Diese Anforderung ist notwendig, um jede Instanz isoliert zu halten. Da jeder Dienst seinen eigenen Sprach- und Technologiestapel verwendet, können diese Ungleichheiten im Anwendungsdesign und in der Architektur die Gesamtressourcen, die das Unternehmen für Management und Wartung aufwendet erhöhen.4

Sicherheit

Im Vergleich zu einer monolithischen Anwendung stellen Mikroservices aufgrund der zunehmenden Inter-Service-Kommunikation über das Netzwerk enorme Sicherheitsheraus­forderungen dar. Durch diese Interaktionen erhöht sich das Risiko eines Zugriffs externer Einheiten zum System. 4

2.3 Die wichtigsten Eigenschaften

Damit man von den oben genannten Vorteilen profitieren kann, müssen die Services bestimmte Eigenschaften haben. Hier werden die wichtigsten Eigenschaften erwähnt [2, 5].

2.3.1 Lose Kopplung

Dieser Aspekt wurde in dieser Arbeit mehrmals erwähnt. Eine Änderung an einem Microservice soll keine Änderung an einem der anderen Services nach sich ziehen. Der Sinn dabei ist, Änderungen an einem Microservice zu erlauben und ihn wieder deployen zu können, ohne dass andere Teile des Systems geändert werden müssen. Und wenn die Änderungen zum Ausfall des geänderten Services führen, hat das keine Auswirkungen auf die anderen Services und das System läuft weiter ohne Probleme.

[...]

¹ https://www.youtube.com/watch?v=CriDUYtfrjs&feature=youtu.be&t=528