Dieser Artikel ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden. Bitte hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst.
Der Gedanke hinter Microservices entspricht weitgehend dem der Unix-Philosophie („Do One Thing and Do It Well“, frei übersetzt: „Erledige nur eine Aufgabe und erledige sie gut“). Die Dienste sollten üblicherweise die folgenden Eigenschaften haben:
Die Services können einfach ersetzt werden.
Der Umfang eines Microservices sollte für jedes Teammitglied überschaubar sein.
Ein Microservice sollte vom zuständigen Team (üblicherweise 5 bis 7 Entwickler) mit vertretbarem Zeitaufwand (z.B. innerhalb eines Monats) neu erstellt und ersetzt werden können.
Die Dienste haben eine einzige Geschäftsfunktion. Sie können beispielsweise einen Bestellvorgang, die Registrierung oder die Rechnungserstellung umfassen, jedoch nicht mehrere dieser Dinge.
Der Nutzen für den Benutzer steht im Mittelpunkt.
Die Kernfunktionalität sollte frühzeitig ausgeliefert werden, um einen möglichst frühen Nutzen bereitzustellen.
Schnittstellen sollten, z.B. über Humane Registries, selbstdokumentierend sein. Beispielsweise Swagger für JSON-basierte REST-Services.
Nach der Bereitstellung einer neuen Version des Services muss die alte Version des Endpunktes für eine bestimmte Zeit weiter bereitgestellt werden.
Ein Microservice wird nur von einem Team entwickelt. Die Architektur liegt über den Microservices und ist auf Grund des Gesetzes von Conway durch die Teamaufteilung sichtbar. Alternativ dazu kann ein Team für mehrere fachlich zusammenhängende Microservices verantwortlich sein.
Kommunikationsoverhead und Interessenskonflikte zwischen Teams werden auf der Ebene der Architektur behandelt.
Die Schnittstellen verstecken Implementierungsdetails.
Es werden dabei bevorzugt Standardverfahren mit geringem Overhead, wie REST, eingesetzt.
Es sollte nicht ersichtlich sein, mit welcher Architektur ein Microservice selbst implementiert wurde.
Datenbanken werden nicht von mehreren Services verwendet, sondern immer nur von einem einzigen Service. Dies betrifft auch Zugriffe über Views und Stored Procedures.
Microservices werden gegenüber anderen Services isoliert.
Microservices sollten Abhängigkeiten untereinander vermeiden und wenn dann nur asynchrone Abhängigkeiten haben.
Jeder Microservice sollte unabhängig von anderen Microservices in Produktion gebracht werden können.
Objekte, welche in mehreren Bounded Contexts vorkommen, werden in jedem Service getrennt implementiert. Beispielsweise wird derselbe Kunde in einem Authentifizierungssystem, einem Bestellsystem, einem Logistiksystem und einem Rechnungssystem jeweils durch unterschiedliche Objekte repräsentiert, da an die Objekte unterschiedliche Anforderungen gestellt werden.
Microservices werden in getrennten OS-Containern, virtuellen Maschinen oder Servern ausgeliefert. Dies sichert den Service gegenüber einer Überlastung des Host-Systems durch einen anderen Service.
Wie alle Services müssen auch Microservices sicher sein:
Microservices sollten dezentralisiert und horizontal skalierbar sein. Funktionale Architekturen mit Zustandsfreiheit werden bevorzugt. Dies betrifft etwa Caches (z.B. zum Speichern von Benutzer-Sessions), welche als eigener Service, etwa in Form einer In-MemoryKey-Value-Datenbank, ausgeführt werden müssen.
Microservices isolieren Fehlerereignisse und -zustände von anderen Services.
Die Größe eines Microservices wird hierbei dadurch nach unten begrenzt, dass die Netzwerkkommunikation zwischen Microservices ressourcenintensiv ausfallen kann und für jeden Microservice ein eigenes Deployment vorgesehen werden muss.
Typische Bestandteile einer Microservice-Architektur
Microservices benötigen sehr viel Infrastruktur, welche durch jeweils eigenständige Services implementiert wird.
Für die Lastverteilung externer HTTP-Anfragen von Clienten kommen Load-Balancer zum Einsatz. Statische Inhalte werden mittels eines Content Delivery Network ausgeliefert.
SOA nutzt Dienste, um verschiedene Anwendungen zu integrieren. Die Kombination der Dienste erfolgt durch Orchestrierung oder Choreografie, und Portale können eine gemeinsame Benutzerschnittstelle (UI) für alle Dienste bieten.
Microservices strukturieren eine Anwendung durch Dienste. Jeder Microservice kann eine Benutzerschnittstelle enthalten und Geschäftsprozesse implementieren, wie sie bei SOA in der Orchestrierung zu finden sind.
Vorteile
Weil Microservices unabhängig voneinander verteilt und entwickelt werden können, können Teams unabhängiger voneinander arbeiten. Das ermöglicht die Skalierung agiler Entwicklungs-Prozesse, ohne viel Kommunikations- und Koordinationsaufwand zu erzeugen.
Microservices sind idealerweise klein. Dadurch bleiben sie übersichtlich und leicht weiterentwickelbar. Bei Bedarf können sie durch eine Neuimplementierung ersetzt werden.
Oft schleichen sich bei Systemen ungewollte Abhängigkeiten ein. Die Abhängigkeiten zwischen Microservices müssen über die API eingeführt werden. Das ist aufwändig und passiert nicht aus Versehen.
Microservices können unabhängig voneinander skaliert werden.
Microservice-Systeme können gegen den Ausfall anderer Services abgesichert werden, so dass das Gesamtsystem robust ist.
Wenn Schlüsseldienste identifiziert wurden, können im Falle einer Überlastung unkritische Services reduziert oder abgeschaltet werden, um Ressourcen für kritische Services frei zu machen.
Nachteile
Microservices werden wegen einiger Merkmale kritisiert:
Die Abhängigkeiten zwischen den Microservices sind bei einer Microservicearchitektur nicht offensichtlich. Es ist oftmals unklar, welche Microservices welche anderen Microservices in welcher Version benötigen.
Da es mehr Systeme gibt die ausfallen können als bei monolithischen Services, steigt auch die Wahrscheinlichkeit, dass mindestens eine Komponente ausfällt. Wenn die Microservices wie üblich untereinander synchrone Abhängigkeiten haben, wirkt sich der Ausfall eines Microservices unmittelbar auf das Gesamtsystem aus.
Der Aufwand für die Migration bestehender Systeme ist beträchtlich und bedeutet in der Regel auch eine Anpassung der Kommunikationskultur in den beteiligten Organisationen.
Das Logging und Monitoring wird komplexer, da mehrere Systeme involviert sind, welche ggf. unterschiedliche Logging- und Monitoringtechnologien einsetzen. Es sollten daher, zusätzlich zu dezentralen Logging- und Monitoringlösungen, zentrale Logging-, Monitoring- und OpsDB-Dienste eingesetzt werden.
Da es sich um ein potenziell weltweit verteiltes System handelt, müssen nicht nur unterschiedliche Zeitzonen der Client-Anwendungen, sondern auch unterschiedliche Zeitzonen der Hosts berücksichtigt werden. Eine Zeitsynchronisierung zwischen den Hosts (z.B. mittels NTP oder noch besser PTP) und die Verwendung passender Zeit-Bibliotheken (z.B. Joda Time oder Noda Time) wird damit zwingend notwendig.
Da es sich bei Microservices um eine verteilte Architektur handelt, muss aufgrund des CAP-Theorems zwischen Verfügbarkeit der Anwendung und der Datenkonsistenz gewählt werden. Monolithische Systeme können hingegen sowohl maximal verfügbar als auch maximal konsistent sein.
Da die Microservices in unterschiedlichen Programmiersprachen und Software-Stacks implementiert werden können, werden sie das oft auch, was zu den Nachteilen des polyglotten Programmierens führt: Das Know-how kann nicht mehr geteilt werden, es erhöhen sich die Anforderungen an die Entwicklungswerkzeuge und das Plattform-Management. Zudem muss die Funktionalität von Bibliotheken teilweise dupliziert werden.
Beispiele
Von folgenden Internetdiensten ist bekannt, dass sie Microservices benutzen:
Eberhard Wolff:Microservices: Grundlagen flexibler Softwarearchitekturen. dpunkt, 2018, ISBN 978-3-86490-555-1.
Sam Newman:Microservices: Konzeption und Design. mitp, 2015, ISBN 978-3-95845-081-3 (englisch: Building Microservices: Designing Fine-Grained Systems. 2015. Übersetzt von Knut Lorenzen).
Christian Horsdal Gammelgaard:Microservices in .NET. Manning Publications, 2016, ISBN 978-1-61729-337-5.
Chris Richardson:Microservices Patterns. Manning, 2019, ISBN 978-1-61729-454-9 (englisch, 491S.).
Weblinks
James Lewis, Martin Fowler:Microservices.25.März 2014,abgerufen am 9.November 2015(englisch).
