d12g

Blog von Daniel Grewing

Replikation von Microservices

21. Juni 2015 Softwareentwicklung

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

Diskussion um MonolithFirst

13. Juni 2015 Softwareentwicklung

Für eine nähere Beschäftigung mit dem Thema Microservices ist es sehr interessant, den Meinungsaustausch zwischen Martin Fowler und Stefan Tilkov bezüglich einer “MonolithFirst”-Strategie zu verfolgen. Martin Fowler versucht in seinem Beitrag MonolithFirst darzustellen, dass es nicht immer sinnvoll sei, ein neues Projekt mit einer Microservice Architektur zu beginnen. Stefan Tilkov widerspricht diesem Ansatz und meint, wenn das Ziel eines neuen Projekts eine Microservice Architektur sei, sollte man nicht mit einem Monolithen starten.

Eine Zusammenfassung beider Meinungen kann man auch auf jaxcenter.de zu nachlesen:
Sind Monolithe besser als ihr Ruf? Wider die Microservices: Monolithe als Fundament

Stefan Tilkov antwortet auf Martin Fowler: Brauchst du Microservices, bau dir Microservices!

Pattern für Microservice-Architekturen

7. Juni 2015 Softwareentwicklung

Arun Gupta beschreibt in seinem Beitrag Microservice Design Patterns sechs verschiedene Pattern zum Aufbau einer Microservice Architektur. Verschiedene Ansätze zu kennen und vergleichen zu können ist sehr hilfreich, wenn man überlegt diesen Architekturstil anzuwenden. Er unterscheidet dabei auch, ob ein Projekt auf “der grünen Wiese” geplant werden kann oder ob eine bestehende monolithische Anwendung in Microservices zerlegt werden soll.

Aggregator Microservice Design Pattern
Dieser Ansatz wird als der gängigste beschrieben. In einen einfachem Beispiel greift eine Webseite (Aggregator) auf REST-Services zu, sammelt die erforderlichen Daten mit Hilfe der Komponenten zusammen und stellt diese anschließend dar. Eine erweiterte Form wäre, wenn selbst der Aggregator keine Benutzerschnittstelle implementiert hätte, sondern die Daten über REST-Services einliest, sie mit einer Businesslogik verarbeitet und dann selbst als REST-Service zur Verfügung stellt.

Proxy Microservice Design Pattern
Der Proxy ist eine Variation des Aggregator Pattern. Anstatt die Daten selber zu sammeln, werden die Anfragen an verschiedene Microservices weitergeleitet und dort verarbeitet. Gupta unterscheidet nach dem dumb proxy, der nur weiterleitet, und dem smart proxy, der ebenfalls einfache Business Logik verarbeitet.

Chained Microservice Design Pattern
Eine weitere Variante ist die Verknüpfung von Microservices in einer Kette, welche die requests vom Client von Service zu Service weiterleitet und die responses wieder in dieser Kette zurückgeleitet werden. Der Client ist solange geblockt bis die Kette komplett durchgearbeitet wurde. Welche Blockmechanismen die Services untereinander einsetzen spielt keine Rolle.

Branch Microservice Design Pattern
Dieses Pattern erweitert den Aggregator Ansatz um das Chained Microservice Design Pattern. Dabei kann der Aggregator verschiedene chains-Services synchron aufrufen.

Shared Data Microservices Design Pattern
Ein Prinzip beim Einsatz von Microservices ist, dass alle Schichten einer Anwendung von einer Komponente implementiert werden. Dieses Pattern ist eine Lösung dafür, dass eine monolithische Anwendung, die auf eine SQL-Datenbank zugreift, nicht einfach in unterschiedliche Komponenten zerlegt werden kann und alle ihre eigene Persistenzschicht mitführen. Der Ansatz beschreibt, wie Microservices auf eine Datenquelle zugreifen und diese als Datenschnittstelle fungiert. Dabei erhöht man zwar die Kopplung der Komponenten, man hat aber einen Schritt weg von der monolithischen Architektur erreicht.

Asynchronouse Messaging Microservice Design Pattern
Dieses Pattern beschreibt wie Microservices nicht über REST-Services kommunizieren, sondern über eine Message Queue, die asynchron Daten verteilt. Gupta verweißt bei diesem Pattern noch auf den Artikel Coupling Versus Autonomy Microservices.