© Excellent backgrounds/Shutterstock.com
Mit Polling schnell zum Ziel

Resilient Microservices


Es ist mittlerweile schon viel gesagt worden zu den Themen Microservices und Resilient Softwaredesign. Was liegt also näher, als beides einmal zu kombinieren und das Ganze mit einem wiederverwendbaren Architekturmuster in die Praxis umzusetzen.

Bevor wir starten, widmen wir uns noch schnell ein paar Begriffsbestimmungen. Unter Microservice verstehe ich ein selbstständig laufendes Softwaremodul, das Teile oder die Gesamtheit einer fachlichen Anforderung umsetzt. Es ist also möglich, Microservices zu definieren, welche nur eine einzige Anforderung umsetzen, z. B. „Brief drucken“, oder aber komplexere Anforderungen wie z. B. das gesamte Billing. Resilient hingegen ist ein aktuelles Designparadigma, das davon ausgeht, dass Kommunikationspartner nicht zur Verfügung stehen könnten und man sich bereits im Design Gedanken darüber machen muss, wie man mit derlei Eventualitäten umgehen möchte.

Basierend auf einem Multi-Tier-Ansatz je Microservice können diese in unterschiedlichen Ausprägungen vorkommen. Hier ein paar mögliche Flavours:

  • GUI – Logik – Persistenz (vollständige Anwendung)

  • Logik – Persistenz (Service)

  • Batch

Eine mögliche reale Ausprägung ist z. B. der Microservice zur Selbstregistrierung eines neuen Anwenders (Abb. 1).

wronka_resilientmicroservices_1.tif_fmt1.jpgAbb. 1: 3-Tier-Aufbau des Microservice „Registration“

Ein weiteres Beispiel ist der Microservice zum Login. Dieser nutzt in dieser Ausprägung den Microservice „Registration“, um die Accountinformationen des Nutzers während des Logins abzufragen (Abb. 2).

wronka_resilientmicroservices_2.tif_fmt1.jpgAbb. 2: Microservice „Login“ mit Onlineschnittstelle zum Microservice „Registration“

Dieses Beispiel zeigt nun, wie Microservices geschnitten werdenund ggf. miteinander kommunizieren können, doch genau dieses Beispiel zeigt auch, dass der Microservice „Login“ gegenüber dem eventuellen Ausfall des Microservice „Registration“ nicht fehlertolerant ist.

Redundancy

An dieser Stelle kommt nun eine Designentscheidung zum Tragen. Ich entscheide mich nun bewusst für Datenredundanz, damit diese Abhängigkeit aufgelöst wird. Die grundlegende Idee besteht also darin, Daten nur an einer Stelle leben zu lassen (also lesend und schreibend zugänglich zu machen), aus Performance- und Stabilitätsgründen aber gezielt (unter Berücksichtigung des Need-to-know-Prinzips) an die Mircoservices zu verteilen. Wichtig ist hierbei, dass auf diese verteilten Daten je Microservice nur lesend zugegriffen werden kann. Entscheidend ist jedoch, dass der lesende Microservice auch bei Ausfall des Microservice, welcher der...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang