d12g

Blog von Daniel Grewing

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.

Microservices

10. Mai 2015 Softwareentwicklung

Ein TOP-Thema in der Webentwicklung in den letzten Monaten ist der Architekturansatz der Microservices. Dieser Ansatz ist vergleichbar mit Ideen der Service-orientierten Architektur und des Domain-Driven Designs. In der konkreten Umsetzung werden oft Technologien wie Docker, node.js oder Spring Boot genannt. Einen vielbeachteten Artikel zu diesem Thema haben Martin Fowler und James Lewis geschrieben. Sie beschreiben sehr umfassend die Merkmale und Vorteile dieser Architektur.

Ich möchte dieses Thema in meinem Blog aufgreifen und anhand eines Beispiels näher erklären.
In der Webentwicklung kann man Microservices als einen Ansatz verstehen, wie man komplexe Webanwendungen als eigene Komponenten betrachtet. In der Business Technology nennt Eberhard Wolff das Gegenstück der Microservice Architektur: Den Deployment-Monolithen. Das sind Anwendungen, die viele verschiedenen Services und Funktionalitäten implementiert haben und bei Änderungen als Ganzes ausgeliefert werden. Microservices dagegen sind Komponenten, die Funktionalitäten eines Gesamtsystems abbilden, getrennt voneinander entwickelt und ausgeliefert werden. Jeder Microservice bildet dazu alle Schichten ab, von der Geschäftslogik, der Datenhaltung bis zur Benutzerschnittstelle. Miteinander kommunizieren die Microservices über Schnittstellen wie z.B. WebServices.
Dieser Ansatz bietet verschiedene Vorteile: Teams, die Microservices umsetzen, sind frei in der Wahl ihrer Technologie und können selbstständig Anforderungen umsetzen. Bei der Auslieferung werden neue Funktionalitäten schneller bereitgestellt, weil nicht ein komplexes Gesamtsystem deployed werden muss, sondern nur einzelne Komponenten. Netflix gilt in diesem Bereich als Vorreiter. Der Streaming Anbieter betreibt seine Microservices in der Amazon Cloud. In ihrem Tech-Blog schreiben sie über die Herausforderungen, Ansätze bei der Entwicklung und des Monitoring der über 100 Komponenten. Viele ihrer Lösungen geben sie als OpenSource Software an die Community weiter.

Da ich bisher eher theoretische Ansätze gelesen habe, habe ich mich diesem Thema anhand eines Beispiel genähert. Dazu habe ich als Idee eine Webanwendung, die man als Mischung aus Evernote, Google Keep und den Zettelkasten betrachten kann. Ich nenne sie Zetteln und sie ist eine einfache Notizverwaltung, die Notizen aus der Sicht eines “Zettels” betrachtet und diese miteinander in Beziehung setzt.

Die Wireframes skizzieren die Idee: Eine Landingpage enthält ein Login- und Registrierungsformular, sowie einige statische Seiten wie z.B. das Impressum. Nach dem Login erhält man Zugang zur Anwendung, die eine Übersicht über die gespeicherten Zettel zeigt. Über die Toolbar kann die Ansicht geändert und weitere Zettel hinzufügt werden.
Startseite
App
Edit

Da es sich es um eine kleine Anwendung handelt spricht wenig dagegen, sie z.B. als eine Grails-Anwendung umzusetzen. Deployment-Monolith ist für diese Anwendung sicher noch nicht der passende Ausdruck. Betrachtet man das aber mal aus dieser Perspektive ergeben sich bei der Auslieferung einer Grails Anwendung bereits einige Nachteile. Wenn ich nur auf der Startseite Textergänzungen oder Suchmaschinenoptimierungen vornehmen möchte, muss ich das in meiner Grails-Anwendung ändern und dieses als war-File neu auf dem Tomcat deployen. Ähnlich verhält es sich, wenn ich größere Änderungen in der Anwendung vornehme. Während dieser Zeit könnte auch die Startseite offline sein.

Um nun den Ansatz der Microservice-Architektur umzusetzen, kann man die Anwendung ist drei Komponenten aufteilen:
– Eine statische Webseite als Landing Page mit weiteren Unterseiten: Zetteln-Static
– Eine Spring Boot Anwendung, die als WebService die Registrierung und das Login übernimmt: Login
– eine Grails Anwendung, die die Zettelverwaltung umsetzt: Zetteln-App
MS-Architektur

In einem nächsten Blogbeitrag zeige ich beispielhaft, wie man diese Architektur mittels jQuery, Spring Boot und Grails umsetzen kann.