Eberhard Wolff Freelancer

Das Speichern von Daten ist kein Thema, das nur Microservices betrifft.

Microservices werfen wichtige Fragen für die Softwarearchitektur auf. Besonders wichtig ist es, wie die Microservices mit Daten umgehen. Die dort angewandten Konzepte lassen sich aber für viel mehr als nur für Microservices nutzen. Sie werfen grundlegende Fragen zur Modularisierung auf.

Zunächst einige Worte über Microservices: Dieser Artikel versteht unter Microservices unabhängig deploybare Module. Das können Docker-Container sein. Eine neue Version eines Microservice bedeutet dann, dass ein Docker-Container gestoppt, durch eine neue Version ersetzt und wieder gestartet wird. Das beeinflusst andere Docker-Container und damit andere Microservices nicht. Microservices sollten von einem Team weiterentwickelt werden. Ein Team kann durchaus an mehreren Microservices arbeiten. Aber ein Microservice, an dem mehrere Teams arbeiten, ist kaum sinnvoll. Schließlich ist das System ja in Module aufgeteilt, damit eine unabhängige Arbeit an einzelnen Modulen möglich ist. Wenn Teams immer an getrennten Microservices arbeiten, müssen sie sich viel weniger abstimmen.

Microservices haben viele Vorteile. Entwickler können ein Feature implementieren und es in Produktion bringen – ohne dass dazu eine Koordination mit anderen Microservices zwingend notwendig wäre. Schließlich lassen sich Microservices ja unabhängig in Produktion bringen. Außerdem kann jeder Microservice unabhängig skaliert werden und einen anderen Technologiestack nutzen. Außerdem sind Microservices isoliert: Der Absturz eines Microservice bleibt auf den Microservice begrenzt. Ebenso können Microservices bezüglich Sicherheit beispielsweise durch Firewalls isoliert werden.

Am Ende ermöglichen Microservices ähnlich wie andere Arten von Modulen auch Entkopplung. Aber nicht nur auf Ebene der Architektur, sondern auch bei der Technologie, beim Deployment, bei der Sicherheit oder bei der Robustheit. Dieser hohe Grad an Entkopplung rechtfertigt auch die hohe technologische Komplexität, die Microservices mit sich bringen.

Zentrale Datenbank ist keine Lösung

Das Speichern von Daten ist kein Thema, das nur Microservices betrifft. Viele komplexe Softwaresysteme nutzen zentrale Datenbanken. Es ist nicht ungewöhnlich, dass sich mehrere Module oder gar Systeme eine Kunden- oder Produktdatenbank teilen. Die Vorteile liegen auf der Hand: Nicht nur die Daten sind konsistent, sondern auch das Datenformat. Änderungen an Daten und Datenformaten stehen sofort allen Systemen zur Verfügung. Die Systeme können auch Datenformate wiederverwenden. Das vereinfacht die Entwicklung und Wartung.

Microservices sollen keine zentrale Datenbank nutzen. Denn eine gemeinsame Datenbank widerspricht der Entkopplung. Es ist kaum sinnvoll, den hohen technischen Aufwand für Microservices zu betreiben, um dann durch eine gemeinsame Datenbank doch wieder eine enge Kopplung zu bekommen. Bei einer gemeinsamen Datenbank sind Änderungen an den Schemata kaum möglich, weil sie jedes System betreffen, das die Datenbank verwendet. Also müssen solche Änderungen zwischen allen Microservices abgestimmt und nachgezogen werden. Nicht nur aus diesem Grund ist es auch problematisch, ein kanonisches Datenmodell zu definieren, das systemübergreifend gelten soll. Ebenso leidet die Robustheit: Der Ausfall der Datenbank führt dazu, dass alle Microservices ebenfalls ausfallen.

Eine Lösung: der Daten-Microservice

Eine Lösung ist, den Zugriff auf die Datenbank in einem eigenen Microservice zu kapseln (Abb. 1). Also würde es einen Bestellung-Daten-Microservice statt einer Bestellung-Datenbank geben. Der Regel „Jeder Microservice hat seine eigene Datenbank“ ist damit genüge getan. Wenn die Microservices den Ausfall anderer Microservices beispielsweise mit einem Cache kompensieren können, ist die Lösung auch robust. Aber dieser Ansatz hat auch Nachteile. Jeder Zugriff auf die Daten ist nun eine Kommunikation zwischen Microservices und geht damit über das Netzwerk. Das beeinflusst die Performance. Außerdem wird ein Ausfall wahrscheinlicher, da nun der Zugriff über das Netzwerk und auf einem anderen Server stattfindet. Und damit ist viel mehr Infrastruktur im Spiel, die ausfallen kann. Ebenso sind Transaktionen über verschiedene Daten nun nicht mehr möglich, da die Zugriffe über das Netz keine Transaktionen unterstützen. Und wenn eine Änderung einen Prozess, wie eine Rechnungserstellung, und auch Daten beispielsweise einer Bestellung umfasst, sind nun mehrere Microservices zu ändern und neu zu deployen. So wird ein wesentlicher Vorteil der Microservices zunichtegemacht: das unabhängige Deployment. Denn nun müssen mehrere Microservices angepasst und auch neu deployt werden.

Also schränken Daten-Microservices die Entkopplung aus unterschiedlichen Gründen ein. Die Entkopplung ist aber eine wesentliche Eigenschaft von Microservices. Dem steht gegenüber, dass der Daten-Microservice die einzige Quelle für die Daten ist und so Konsistenz sicherstellen kann. Es ist klar, welchen Stand jeder Datensatz gerade hat. Das kann beispielsweise relevant sein, um zuverlässig über einen Lagerbestand Auskunft zu geben.

Abb. 1: Bestellungsprozess- und Auslieferungs-Microservice nutzen einen Daten-Microservice für Bestellung

Abb. 1: Bestellungsprozess- und Auslieferungs-Microservice nutzen einen Daten-Microservice für Bestellung

Kapselung ade?

Von der Architekturperspektive hat dieser Ansatz aber noch ein ganz anderes Problem: Er entspricht nicht mehr den Ideen der Einkapselung und des Information Hidings. Ein Microservice ist ein Modul und sollte daher seine internen Datenstrukturen nicht nach außen exponieren, sondern verstecken. Eine Klasse in einem objektorientierten System erlaubt deswegen keinen Zugriff auf ihre Instanzvariablen. Für ein grobgranulares Modul wie einen Microservice sind die internen Datenstrukturen in der Datenbank. Wenn also die Daten aus der Datenbank einfach nach außen sichtbar gemacht werden und andere Microservices auf die Daten zugreifen, widerspricht das der Kapselung.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 4.17 - "APIs"

Alle Infos zum Heft
579777421Der richtige Umgang mit Daten
X
- Gib Deinen Standort ein -
- or -