d12g

Blog von Daniel Grewing

Replikation von Microservices

| Keine Kommentare

Der Artikel Microservices – die am häufigsten gestellten Fragen auf jaxenter beschreibt viele Herausforderungen, die man sich stellen muss, aber auch, welche Vorteile man durch eine Microservice-Architektur erreicht.

Mir stellt sich zum Thema „Service Replication“ eine Frage, die ich mir noch nicht beantworten kann. Microservices zeichnen sich dadurch aus, dass sie alle Softwareschichten abdecken, von der GUI, der Business-Logik und der Persistenzschicht. Entwicklerteams sollen frei in der Wahl der eingesetzten Technologien sein. Eine mögliche Wahl wäre die Entwicklung einer Webanwendung, die auf einem Tomcat läuft und Zugriff auf eine relationale Datenbank hat, wie MySQL oder PostgreSQL.
ms4

Nicht alle Unternehmen stellen ihre Dienste bei Anbietern wie Amazons AWS bereit, sondern betreiben eigene Server und virtualisieren diese. Den hier beschriebenen Service auf einer virtuellen Maschine bereitzustellen ist für den Betrieb sicher keine hohe Herausforderung. Wenn die Anforderungen an den Microservice steigen, muss dieser skaliert werden können. Der Artikel beschreibt dazu die mögliche Skalierung auf der X-Achse. Bei meinem Beispiel würde das bedeuten, der VM weitere Ressourcen wie CPU oder RAM bereitzustellen.
Steigen nun aber die Anforderungen bezüglich der Verfügbarkeit ist eine Option den Microservice zu replizieren.
Im Artikel wird gesagt, dass eine Service Replikation leicht und basierend auf Metadaten erfolgen können sollte. Der Tomcat ist in einem Clusterverbund hinter einem Apache oder nginx leicht zu replizieren. Aber für mich besteht nun eine große Herausforderung darin, die relationale Datenbank in einem Clusterverbund zu betreiben. Den MySql- oder PostgreSql-Server als einen Master-Slave Verbund zu konfigurieren ist noch eine gängige Lösung. Wenn man also den Schritt von einer Instanz auf zwei Instanzen bewältigt hat, sind weitere Slave-Server einfach hinzufügt. Was ist aber, wenn man den Microservice in einer hochverfügbaren Umgebung betreiben möchte. Diese Datenbanksysteme in einem Clusterverbund zu betreiben, bei dem die Daten auch nach dem Ausfall einer oder mehrerer Nodes noch zur Verfügung stehen, ist schon eine sehr große Herausforderung, oder?
ms2

Zur Zeit würde ich wohl noch folgende Architektur dazu aufbauen. Man “zerpflückt” den Microservice noch weiter und betrachtet ihn nur auf der Ebene des Tomcats. Dieser wird dann in ein bestehendes Netzwerk hinzugefügt. Dort befindet sich bereits ein Apache-Cluster, der sich mittels mod_jk um die Lastverteilung auf die Tomcats kümmert. Zusätzlich steht ein Datenbankcluster zur Verfügung, auf dem auch andere, bestehende Microservices ihre Daten speichern. Dieser Aufbau lehnt sich also an das Shared Data Microservice Design Pattern.
ms5

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.