Design Patterns vom AzureCAT Patterns & Practices Team

9 Design Patterns für Microservices in der Cloud
Kommentare

Das AzureCAT Patterns & Practices Team hat neun Design Patterns für die Verwendung von Microservices in der Cloud vorgestellt. Diese lösen einige der Probleme, die bei der Arbeit mit einer solchen Architektur auftreten können. Auch hier kommt es aber auf die Wahl des richtigen Werkzeugs zum rechten Zweck an.

Die Microservice-Architektur setzt sich im Web immer stärker durch. Zahlreiche Projekte werden heute mit Microservices realisiert, vor allem für Cloud-Lösungen ist diese Anwendungsarchitektur beliebt. Das AzureCAT Patterns & Practices Team, das sich mit dem Nutzerfeedback zu den Azure-Cloud-Lösungen befasst, hat nun gleich neun neue Design Patterns vorgestellt, die dabei helfen sollen, Microservice-Architekturen in der Cloud zu verbessern. Dabei befassen sie sich beispielsweise mit dem Problem der Migration von monolithischen Anwendungen zu Microservices und mit der Absicherung von Legacy-Code, der nicht gut zu bearbeiten ist.

9 Design Patterns für Microservices

Mike Wasson hat die neuen Design Patterns im Azure Developer Blog vorgestellt. Die folgende Abbildung zeigt, wo die jeweiligen Design Patterns in der Anwendungsarchitektur eingesetzt werden. Nachfolgend geben wir einen Überblick über die verschiedenen Strategien, die in der Dokumentation genauer beschrieben sind.

Design Patterns und Microservice-Architektur. Quelle: https://azure.microsoft.com/de-de/blog/design-patterns-for-microservices/

Ambassador Pattern & Anti-Corruption Layer

Das Ambassador-Pattern wird für Connecitivity-Tasks wie Logging, Monitoring oder Security eingesetzt; dort dient es dazu, diese Aufgaben aus Microservices auszulagern und in eigenen Services zu realisieren. Sinnvoll ist das für Legacy-Code, der nicht mehr gut zu ändern ist, sowie in Fällen, in denen mehrere Services, die in verschiedenen Sprachen geschrieben wurden, eine gemeinsame Lösung für eine solche Aufgabe erhalten sollen.

Mit einem Anti-Corruption Layer kann die Verbindung zu Legacy-Systemen moduliert werden. Dies ist laut der Dokumentation des Patterns vor allem im Rahmen von inkrementellen Migrationen sinnvoll, um Abhängigkeiten zu verringern und somit Probleme zwischen alten und neuen Systemen zu vermeiden. Es handelt sich dabei jedoch um zusätzliche Serivces, die somit zu Latenzzeiten führen können.

Backends for Frontends & Bulkhead-Pattern

Beim Backends for Frontends-Pattern besteht darin, für jedes Frontend einen eigenen Services zu entwickeln, um abweichenden Anforderungen, die beispielsweise durch verschiedene Devices entstehen, zu erfüllen. Dies ist dann sinnvoll, wenn nur eine begrenzte Zahl an Frontends bedient werden soll, weil ansonsten die Zahl der Services zu groß wird.

Durch die Umsetzung des Bulkhead-Patterns wird die Resilienz des Systems erhöht, so sagt Wasson. Dazu werden die verfügbaren Ressourcen des Systems partitioniert und Services isoliert: Einzelne Services können somit nicht mehr zum Versagen des gesamten Systems führen, wenn sie zu viele Ressourcen verbrauchen oder abstürzen. Das kann jedoch zu einer ineffizienten Ressourcenverwendung führen, weil nicht genutztes Potential nicht automatisch umverteilt wird.

Gateway-Patterns

Das Gateway Aggregation Pattern reduziert die Anzahl an Requests, die durch den Client an die verschiedenen Microservices gesendet werden. Stattdessen werden diese Requests im Frontend vereint und an einen Gateway gesendet, der die Anfragen im Backend an die einzelnen Microservices verteilt. Das kann dabei helfen, Latenzen zu reduzieren, beispielsweise bei der Verwendung mobiler Netze.

Wenn bestimmte Features von Anwendungen wie die Authentifizierung, die Autorisierung, das Logging oder das Monitoring oder die Handhabung von Sicherheitszertifikaten über verschiedene individuell deployte Microservices hinweg gemeinsam gehandhabt werden sollen, kann das Gateway Offloading Pattern genutzt werden. Dabei werden diese Funktionen in einen API-Gateway ausgelagert, der diese gemeinsamen Aufgaben handhabt. Allerdings muss dabei sichergestellt werden, dass dieser Gateway nicht zum Bottleneck wird.

Das Gateway Routing Pattern ist dem Gateway Aggregation Pattern ähnlich. Auch hier werden Requests vom Frontend aus nicht unmittelbar an verschiedene Services, sondern an einen Gateway auf Application Layer 7 gesendet. So können Requests über einen extern aufrufbaren Gateway auch an nur intern erreichbare Services weitergeleitet werden.

API Summit 2017

JavaScript Testing in der Praxis

mit Dominik Ehrenberg (crosscan) & Sebastian Springer (MaibornWolff)

Node.js Quickstart

mit Sebastian Springer (MaibornWolff)

Sidecars und Strangler-Pattern

Das Sidecar Pattern wurde laut Dokumentation so genannt, weil es an den Beiwagen eines Motorrads erinnert – unterstützende Prozesse werden in eigene Services oder Container ausgelagert und an einen Eltern-Prozess gebunden. Das kann beispielsweise für das Logging oder für Konfigurationen genutzt werden; der Lifecycle des Sidecar-Prozesses entspricht dem der Eltern-Anwendung. Durch die Auslagerung steht der Prozess Microservices zur Verfügung, die in verschiedenen Sprachen realisiert wurden. Die Verwendung von Sidecares erzeugt jedoch einen Overhead und verhindert eine unabhängige Skalierung der Prozesse in dieser Implementierung.

Das Strangler Pattern hilft dabei, Systeme inkrementell zu migrieren. Dabei werden alte Legacy-Services in kleinen Schritten durch neue Microservices ersetzt; noch nicht ausgetauschte Features werden weiterhin vom alten System getragen. Das lohnt sich natürlich vor allem für große, komplexe Systeme. Auch müssen Backend-Calls dafür durch eine Fassade unterbrochen werden können, damit dort eine Umleitung der bereits ersetzten Prozesse erfolgen kann.

Das sind die neun Design Patterns, die vom AzureCAT Patterns & Practices Team für die Arbeit mit Microservices in der Azure Cloud vorgeschlagen wurden. In der Dokumentation finden sich jeweils weitere Details zu den Vor- und Nachteilen der Design Patterns.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -